This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Thrameos
Recipients Thrameos, WildCard65, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
Date 2020-12-20.04:54:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1608440074.98.0.406838264241.issue42529@roundup.psfhosted.org>
In-reply-to
Content
Gave another series of shots at the problem.  So the reason that attaching the debugger fixes the issue is that it calls LoadLibraryExW for a bunch libraries when it attaches.  

I was also able to unconditionally trigger the bug even when loading without the pyc.   It appears that calling "import _ssh"  will cause whatever conflict is happening to trigger immediately.

Other than than progress was minimal.  Attaching the debugger causes so many changes to the control flow that I can't get the bad path to trigger and I can't get the debugger to attach once you start down the path.   I tried creating a segfault but again I can't get the debugger to attach because Detours is interfering with the attachment process.

I also tried disabling some of the flags that JPype was adding to the python build process to see if any are related.   "/DEBUG" on the linker does not do anything to the problem.  The other options were '/Zi', '/EHsc', '/std:c++14'.   Nothing here is out of the ordinary.  

I do not see anything in the link line that shows evidence of static linkage or likely to cause a conflict.  The exact same line is being used with Python 3.8.

link.exe /nologo /INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPATH:C:\Users\nelson85\AppData\Local\Programs\Python\Python39\libs /LIBPATH:C:\Users\nelson85\AppData\Local\Programs\Python\Python39\PCbuild\amd64 /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\ATLMFC\lib\x64 /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\lib\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\lib\um\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\ucrt\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x64 /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\ATLMFC\lib\x64 /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\lib\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\lib\um\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\ucrt\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x64 /EXPORT:PyInit__jpype 
$(OBJECTS) /OUT:build\lib.win-amd64-3.9\_jpype.cp39-win_amd64.pyd /IMPLIB:build\temp.win-amd64-3.9\Release\native\common\_jpype.cp39-win_amd64.lib

So I remain at a loss how to proceed forward.  Nothing has changed in JPype or its symbols since Python 3.8 so this is clearly taking place in Python or at the OS level.  Is it possible that Python shipped with bad dlls for the 3.9.0 build?  If so then looking at the source code may be the wrong approach.   After all depending on the order of libraries I trigger or don't trigger the bug.

I should note that the difference between loading successfully py and pyc seems to have been triggered in PC/getpathc.c .... could it be the change to remove loading api-ms-win-core-path?


```
 static void
 join(wchar_t *buffer, const wchar_t *stuff)
 {
-    if (_PathCchCombineEx_Initialized == 0) {
-        HMODULE pathapi = LoadLibraryExW(L"api-ms-win-core-path-l1-1-0.dll", NULL,
-                                         LOAD_LIBRARY_SEARCH_SYSTEM32);
-        if (pathapi) {
-            _PathCchCombineEx = (PPathCchCombineEx)GetProcAddress(pathapi, "PathCchCombineEx");
-        }
-        else {
-            _PathCchCombineEx = NULL;
-        }
-        _PathCchCombineEx_Initialized = 1;
-    }
-
-    if (_PathCchCombineEx) {
-        if (FAILED(_PathCchCombineEx(buffer, MAXPATHLEN+1, buffer, stuff, 0))) {
-            Py_FatalError("buffer overflow in getpathp.c's join()");
-        }
-    } else {
-        if (!PathCombineW(buffer, buffer, stuff)) {
-            Py_FatalError("buffer overflow in getpathp.c's join()");
-        }
+    if (FAILED(PathCchCombineEx(buffer, MAXPATHLEN+1, buffer, stuff, 0))) {
+        Py_FatalError("buffer overflow in getpathp.c's join()");
     }
 }
```

Also given JPype is really a generic C++ CPython module (with no special options other than /Zi /EHsc why hasn't anyone else triggered this?
History
Date User Action Args
2020-12-20 04:54:35Thrameossetrecipients: + Thrameos, paul.moore, tim.golden, zach.ware, eryksun, steve.dower, WildCard65
2020-12-20 04:54:34Thrameossetmessageid: <1608440074.98.0.406838264241.issue42529@roundup.psfhosted.org>
2020-12-20 04:54:34Thrameoslinkissue42529 messages
2020-12-20 04:54:34Thrameoscreate