New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Solaris/Oracle Studio: Fatal Python error: PyThreadState_Get when built --with-pymalloc #65611
Comments
I am porting Python 3.4.0 to Solaris 12. The Makefile I inherited from my predecessor had --without-pymalloc as an option to be passed to configure. Curious why, I removed this line, only to find that after python was built, it core dumped: LD_LIBRARY_PATH=/builds/jbeck/ul-python-3/components/python/python34/build/sparcv9 ./python -E -S -m sysconfig --generate-posix-vars But if I add the --without-pymalloc line back to my Makefile, everything works fine. Note that although this example was on sparc, the exact same thing occurred on x86. I searched for a similar bug but did not find out; please feel free to close this as a duplicate if there is one that I missed. I also suspect I have not provided enough information, out of a desire not to trigger information overload. But I would be happy to provide whatever specifics might be requested. |
On SPARC/suncc the flags in http://bugs.python.org/issue15963#msg170661 Also, we have several Solaris build slaves that don't core dump. http://buildbot.python.org/all/waterfall?category=3.x.stable&category=3.x.unstable |
What compiler are you using?. I compile fine on Solaris with GCC. |
Using Oracle Studio 12.3, same as mentioned in http://bugs.python.org/issue15963#msg170661 (as Stefan pointed out). I am using some of those flags but not all of them. I will try the others when I have a chance, then report back. |
"LD_LIBRARY_PATH=/builds/jbeck/ul-python-3/components/python/python34/build/sparcv9 ./python -E -S -m sysconfig --generate-posix-vars Could you please run this command in gdb and copy/paste the C traceback (gdb command "where") where the fatal error occurs? |
Victor: sure; see attached. |
Ok, so the error occurs when Python tries to import the _heapq dynamic module: PyModule_Create2() calls PyThreadState_Get() to retrieve to current thread, but it fails. There is a current thread because PyModule_Create2() is called indirectly by PyEval_EvalFrameExReal() (and I don't see where the GIL would be released in the call stack). It looks like a bug in PyThreadState_Get(). This function relies on _Py_atomic_load_relaxed() which is defined in Include/pyatomic.h. This file has an implementation of atomic functions for Intel processors and contains an interesting comment: ... It looks like John tries Python on SPARC which may explain the issue. This is just a theory. It also looks like we had SPARC buildbots running on Solaris with system C compiler ("/opt/solarisstudio12.3/bin/cc") and it was able to run tests. I don't understand the link with pymalloc. @john: Did you try to build Python 3.3? Did it work? |
Victor:
|
"This is not a SPARC-specific issue; the exact same failure occurs on x86." Ah ok, good to know. To me, it looks like a compiler issue. Did you try Stefan's advices in issue bpo-15963? You may try to disable compiler optimizations to see if you get the same behaviour. |
This appears to be another variation on the problem recently identified in bpo-21166, namely that the pybuildir.txt Makefile rule can incorrectly import a shared library module from a previously installed Python instance and, if the ABIs of the installed and being-built Pythons differ, the newly-built interpreter can fail in various ways. From your supplied trace, one can see that _heapq.so has incorrectly been inported from the installed system Python 3.4 which was probably built with --without-pymalloc: #7 0x00007ff2f9ee2a6d in PyInit__heapq () The fixes for bpo-21166, when applied, should prevent this problem. |
Ned: yes, I can confirm that the patch from http://bugs.python.org/issue21166 does indeed fix the problem. Thank you very much! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: