Bug 507035

Created attachment 349430 [details]
Input test file causing crash

Hmm, this is definitely a pstoedit crash. Unfortunately it's not an easy one. I'm attaching a test input file, and the following command causes the crash:

pstoedit -f plot-svg -dt -ssp eq.ps eq.svg

pstoedit crashes on exit (which is why the output is generated correctly), and no backtrace is available. Stepping through the debugger, it looks as though an infinite loop occurs in the exit code (exit.c), when running the exit handlers that call static C++ objects destructors...

Jakub, if you have a few minutes to spare, do you think this could be a gcc-c++ bug ?

Valgrind trace, comforting the gcc bug theory... (from /libgomp.so)

=28460== Invalid write of size 1
==28460==    at 0x74497D: _dl_signal_error (in /lib/ld-2.10.1.so)
==28460==    by 0x744B52: _dl_signal_cerror (in /lib/ld-2.10.1.so)
==28460==    by 0x74029A: _dl_lookup_symbol_x (in /lib/ld-2.10.1.so)
==28460==    by 0x744645: _dl_fixup (in /lib/ld-2.10.1.so)
==28460==    by 0x74A8AF: _dl_runtime_resolve (in /lib/ld-2.10.1.so)
==28460==    by 0x4160A97: (within /usr/lib/libgomp.so.1.0.0)
==28460==    by 0x41689FF: (within /usr/lib/libgomp.so.1.0.0)
==28460==    by 0x745255: _dl_fini (in /lib/ld-2.10.1.so)
==28460==    by 0x787E0E: exit (in /lib/libc-2.10.1.so)
==28460==    by 0x76FA6D: (below main) (in /lib/libc-2.10.1.so)
==28460==  Address 0xbe875b2c is not stack'd, malloc'd or (recently) free'd
==28460== 
==28460== Invalid read of size 4
==28460==    at 0x74D6C6: __longjmp (in /lib/ld-2.10.1.so)
==28460==    by 0x7449A2: _dl_signal_error (in /lib/ld-2.10.1.so)
==28460==  Address 0xbe875b40 is not stack'd, malloc'd or (recently) free'd
==28460== Warning: client switching stacks?  SP change: 0xbe878ddc --> 0x20
==28460==          to suppress, use: --max-stackframe=1098412612 or greater
==28460== 
==28460== Jump to the invalid address stated on the next line
==28460==    at 0xBE875C0C: ???
==28460==  Address 0xbe875c0c is on thread 1's stack
vex x86->IR: unhandled instruction bytes: 0xFF 0xFF 0x0 0x0
==28460== 
==28460== Invalid read of size 4
==28460==    at 0xBE875C0C: ???
==28460==  Address 0xffff043e is not stack'd, malloc'd or (recently) free'd
==28460== 
==28460== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==28460==  Access not within mapped region at address 0xFFFF043E
==28460==    at 0xBE875C0C: ???
==28460==  If you believe this happened as a result of a stack overflow in your
==28460==  program's main thread (unlikely but possible), you can try to increase
==28460==  the size of the main thread stack using the --main-stacksize= flag.
==28460==  The main thread stack size used in this run was 10485760.
==28460== 
==28460== Process terminating with default action of signal 11 (SIGSEGV)
==28460==  Access not within mapped region at address 0x1C
==28460==    at 0x400140C: _vgnU_freeres (vg_preloaded.c:56)
==28460==  If you believe this happened as a result of a stack overflow in your
==28460==  program's main thread (unlikely but possible), you can try to increase
==28460==  the size of the main thread stack using the --main-stacksize= flag.
==28460==  The main thread stack size used in this run was 10485760.
==28460==

I can't reproduce it, neither with 32-bit nor 64-bit pstoedit.

I am able to reproduce with the F-11 Live i686 image. Just install pstoedit, download the example below and run command from #2. My system is a T61 (Intel Core Duo).

For me, pstoedit-3.45-7.fc11.x86_64 on stock updated F11 crashes no matter how I run it.   For instance pstoedit -help leads to the help being printed and then it crashes with the same trace:

==15564== Memcheck, a memory error detector.
==15564== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==15564== Using LibVEX rev 1884, a library for dynamic binary translation.
==15564== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==15564== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==15564== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==15564== For more details, rerun with: -v
==15564== 
==15564== My PID = 15564, parent PID = 7153.  Prog and args are:
==15564==    pstoedit
==15564==    -help
==15564== 
==15564== Invalid write of size 1
==15564==    at 0x36BC40E85A: _dl_signal_error (in /lib64/ld-2.10.1.so)
==15564==    by 0x36BC40E9DA: _dl_signal_cerror (in /lib64/ld-2.10.1.so)
==15564==    by 0x36BC40AA5E: _dl_lookup_symbol_x (in /lib64/ld-2.10.1.so)
==15564==    by 0x36BC40E54B: _dl_fixup (in /lib64/ld-2.10.1.so)
==15564==    by 0x36BC414934: _dl_runtime_resolve (in /lib64/ld-2.10.1.so)
==15564==    by 0x36CEC034CE: (within /usr/lib64/libgomp.so.1.0.0)
==15564==    by 0x36CEC0A010: (within /usr/lib64/libgomp.so.1.0.0)
==15564==    by 0x36BC8367F1: exit (in /lib64/libc-2.10.1.so)
==15564==    by 0x36BC81EA33: (below main) (in /lib64/libc-2.10.1.so)
==15564==  Address 0x7feff8d20 is not stack'd, malloc'd or (recently) free'd
==15564== Warning: client switching stacks?  SP change: 0x7fefff448 --> 0x3e9b4241190840b
==15564==          to suppress, use: --max-stackframe=281954484350914499 or greater
==15564== 
==15564== Jump to the invalid address stated on the next line
==15564==    at 0x3E9B4241190840B: ???
==15564==  Address 0x3e9b4241190840b is not stack'd, malloc'd or (recently) free'd
==15564== 
==15564== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==15564==  Bad permissions for mapped region at address 0x3E9B4241190840B
==15564==    at 0x3E9B4241190840B: ???
==15564== 
==15564== Invalid write of size 8
==15564==    at 0x480256C: _vgnU_freeres (vg_preloaded.c:56)
==15564==  Address 0x3e9b42411908403 is not stack'd, malloc'd or (recently) free'd
==15564== 
==15564== Process terminating with default action of signal 11 (SIGSEGV)
==15564==  General Protection Fault
==15564==    at 0x480256C: _vgnU_freeres (vg_preloaded.c:56)
==15564== 
==15564== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 16 from 3)
==15564== malloc/free: in use at exit: 28,097 bytes in 104 blocks.
==15564== malloc/free: 558 allocs, 454 frees, 244,064 bytes allocated.
==15564== For counts of detected errors, rerun with: -v
==15564== searching for pointers to 104 not-freed blocks.
==15564== checked 1,569,336 bytes.
==15564== 
==15564== LEAK SUMMARY:
==15564==    definitely lost: 82 bytes in 1 blocks.
==15564==      possibly lost: 0 bytes in 0 blocks.
==15564==    still reachable: 28,015 bytes in 103 blocks.
==15564==         suppressed: 0 bytes in 0 blocks.
==15564== Rerun with --leak-check=full to see details of leaked memory.

pstoedit built without the ImageMagick driver (i.e. libp2edrvmagick++.la) does not crash.  This can be used as a temporary workaround for the original problem because the ImageMagick driver is not necessary for the Inkscape TeX extension.

Pushing a testing update for this, thanks.

pstoedit-3.45-8.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/pstoedit-3.45-8.fc11

I did not suggest publishing that because other pstoedit uses may need the ImageMagick driver.

The real fix is to fix pstoedit (which does not seem easy though, I don't know how to properly debug this kind of stuff).  OTOH pstoedit without a driver is probably better than pstoedit not working at all...

> I did not suggest publishing that because other pstoedit 
> uses may need the ImageMagick driver.

I know, but a systematic core crash is a serious problem, so this workaround is urgent.

The order of events is:

- main() ends

- static PluginVector LoadedPlugins;
  in libpstoedit gets destructed

- individual DynLoader objects representing plug-ins get destructed

- the destructors call dlclose()

- all plug-ins are unloaded

- something else in a library required by the ImageMagick plug-in gets destructed

-> crash

So, a cheap method to work around the crash is to patch DynLoader::~DynLoader() in dynload.cpp to avoid dlclose()ing the plug-ins.  They will be closed anyway because the program terminates and there seems to be no interface for plug-in unloading.

I still don't know how the OpenMP stuff gets there so late.

pstoedit-3.45-8.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update pstoedit'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7671

PING?

The workaround in Comment 12 is IMO much better because nothing needs to be disabled.

Have you tried it ? Does it work around the crash ?

(In reply to comment #15)
> Have you tried it ? Does it work around the crash ?  

Of course, I've been using that since I posted it on two machines (both AMD64).

I cannot guarantee it will fix pstoedit for everyone because, well, I don't know exactly why it crashes in the first place.  The explicit dlclose()ing of plug-ins in the destructors seems to disturb the natural order of destruction somehow, but how and why...  I have not been able to extract the crash to a simple code yet.

Created attachment 353999 [details]
Avoid dlclose() in plugin desctructors

pstoedit-3.45-8.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

This crash appears in openSUSE 11.3 as well.

I did a deeper debugging and I believe that the real problem happens outside pstoedit:

https://bugzilla.novell.com/show_bug.cgi?id=622977#c6