| msg157928 - (view) |
Author: Paul A. (pda) |
Date: 2012-04-10 02:11 |
| The following stack trace happened towards the end of a Python-2.7.3rc2 build, but I also get much the same results with 2.7.2; one difference I noticed was I didn't think I needed to add -DHAVE_USR_INCLUDE_MALLOC_H there. running build_scripts creating build/scripts-2.7 copying and adjusting /usr/local/src/Python-2.7.3rc2/Tools/scripts/pydoc -> build/scripts-2.7 copying and adjusting /usr/local/src/Python-2.7.3rc2/Tools/scripts/idle -> build/scripts-2.7 copying and adjusting /usr/local/src/Python-2.7.3rc2/Tools/scripts/2to3 -> build/scripts-2.7 copying and adjusting /usr/local/src/Python-2.7.3rc2/Lib/smtpd.py -> build/scripts-2.7 changing mode of build/scripts-2.7/pydoc from 644 to 755 changing mode of build/scripts-2.7/idle from 644 to 755 changing mode of build/scripts-2.7/2to3 from 644 to 755 changing mode of build/scripts-2.7/smtpd.py from 644 to 755 sh[3]: 1340 Abort(coredump) (gdb) bt #0 0xc0000000004395d0:0 in kill+0x30 () from /usr/lib/hpux64/libc.so.1 #1 0xc0000000002e8180:0 in raise+0x120 () from /usr/lib/hpux64/libc.so.1 #2 0xc0000000003f8c50:0 in abort+0x170 () from /usr/lib/hpux64/libc.so.1 #3 0xc000000010f0c7f0:0 in free (mem=0x60000000000053d0) at /usr/local/src/Python-2.7.3rc2/Modules/_ctypes/libffi/src/dlmalloc.c:4288 #4 0xc000000000bfcde0:0 in _UNW_free_mpool()+0xc0 () from /usr/lib/hpux64/libunwind.so.1 #5 0xc00000000004cb50:0 in EM_mark_BOS+0x50 () from /usr/lib/hpux64/dld.so |
|
|
| msg157982 - (view) |
Author: Charles-François Natali (neologix) *  |
Date: 2012-04-10 20:50 |
| This stack trace is strange. Is it really the python binary? Anyway, if it's segfaulting inside dlmalloc, there's probably not much we can do. Actually, I wonder why we still ship it... |
|
|
| msg157986 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-04-10 20:59 |
| > Anyway, if it's segfaulting inside dlmalloc, there's probably not much we can do. > Actually, I wonder why we still ship it... I think it's bundled with our copy of libffi. I agree the stacktrace is strange. At the very least it looks truncated. Also it looks like our dlmalloc has shadowed the built-in malloc, which would be quite disturbing. |
|
|
| msg158003 - (view) |
Author: Paul A. (pda) |
Date: 2012-04-11 01:57 |
| I'd be more than happy to use my own installation of libffi instead, but it seems the --with-system-ffi configure flag doesn't work. I've also opened a different bug for that. |
|
|
| msg158077 - (view) |
Author: Charles-François Natali (neologix) * |
Date: 2012-04-11 21:25 |
| > I think it's bundled with our copy of libffi. i'm not familiar - at all - with libffi. But does it really need a bundled malloc() implementation? > I'd be more than happy to use my own installation of libffi instead, but it seems the --with-system-ffi configure flag doesn't work. I've also opened a different bug for that. So, is the stack trace complete? Is it really generated by the python executable? |
|
|
| msg158078 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-04-11 21:32 |
| > > I think it's bundled with our copy of libffi. > > i'm not familiar - at all - with libffi. > But does it really need a bundled malloc() implementation? Well, the upstream libffi includes dlmalloc.c, so I guess it somehow needs it (perhaps only on certain platforms). Don't ask me why :-) |
|
|
| msg158093 - (view) |
Author: Paul A. (pda) |
Date: 2012-04-12 01:03 |
| Yes indeed, sorry for not answering that question the first time. The trace is complete, and is from python... although most of it is really in the shared lib rather than the executable. |
|
|
| msg220634 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2014-06-15 13:22 |
| Is this still a problem given that we're two years on and up to Python 2.7.7? |
|
|
| msg221319 - (view) |
Author: Paul A. (pda) |
Date: 2014-06-22 22:21 |
| I believe this problem has been gone since around 2.7.5, so can I close this myself? |
|
|