On Wed, Feb 17, 2010 at 11:15:59PM +0100, Jan Hnatek wrote: > status: process terminated by SIGSEGV (Segmentation Fault), addr=1 > > $C > 08047838 libc_hwcap1.so.1`realfree+0xcb(815c960, 0, 0, fee8bc43) > 08047878 libc_hwcap1.so.1`_malloc_unlocked+0x1e4(418, 8155b40, 118, fee8be76) > 080478c8 libc_hwcap1.so.1`realloc+0x188(84a2d78, 418, 8047918, fecff5ba) > 08047908 libpython2.6.so.1.0`PyObject_Realloc+0x83(84a2d78, 418, 8047948, > fed0d56e) > 08047948 libpython2.6.so.1.0`_PyString_Resize+0x8b(80479b0, 400, 8047b10, > fed62746) > 08047988 libpython2.6.so.1.0`assemble_emit+0x90(80479b0, 810ca30, 80479b0, > fed62e7e) > 080479e8 libpython2.6.so.1.0`assemble+0x171(8047b10) > 08047a38 libpython2.6.so.1.0`compiler_function+0x19a(8047b10, 84aefd8, 4, > fed5ef2e) > 08047a78 libpython2.6.so.1.0`compiler_visit_stmt+0x49f(8047b10, 84aefd8, > 8047ab8, fed5c672) > 08047ab8 libpython2.6.so.1.0`compiler_body+0xa5(8047b10, 814c340, 853d5e0, 0) > 08047ae8 libpython2.6.so.1.0`compiler_mod+0x72(8047b10, 853d5e0, 8080488, > fed5afe2) > 08047b58 libpython2.6.so.1.0`PyAST_Compile+0xd2(853d5e0, 8047eb3, 8047cdc, > 80a39c8) > 08047b78 libpython2.6.so.1.0`run_mod+0x22(853d5e0, 8047eb3, 80941c4, 80941c4, > 8047cdc) > 08047bb8 libpython2.6.so.1.0`PyRun_FileExFlags+0x6b(fef867e8, 8047eb3, 101, > 80941c4, 80941c4, 1) > 08047c08 libpython2.6.so.1.0`PyRun_SimpleFileExFlags+0x189(fef867e8, 8047eb3, > 1, 8047cdc) > 08047c38 libpython2.6.so.1.0`PyRun_AnyFileExFlags+0x6e(fef867e8, 8047eb3, 1, > 8047cdc) > 08047d88 libpython2.6.so.1.0`Py_Main+0xa94(5, 8047de4, feef6f85, 8050b88, > 10000, 0) > 08047db8 main+0x63(5, 8047de4, 8047dfc, 8050a8f) > 08047dd8 _start+0x7d(5, 8047ea0, 8047eb3, 8047ec0, 8047ec5, 8047ec8)
Since I haven't seen the coredump yet, I went back and took a look at the relevant portions of Python's code. In the case where PyObject_Realloc() is calling libc's realloc, Python believes that it isn't managing the object directly. The fact that realfree() is the source of the SIGSEGV seems to indicate that something in the heap's internal data structures have become corrupted. Does this machine use ECC memory? You might want to run with libumem and enable debugging. If the application is the one corrupting the heap, it will catch the problem sooner. If not, you still may get more helpful messaging about just what has become corrupted. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
