Bug 507035 - pstoedit segfaults when run by inkscape's "Render LaTeX formula"
Summary: pstoedit segfaults when run by inkscape's "Render LaTeX formula"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: pstoedit
Version: 11
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Denis Leroy
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-19 22:38 UTC by Davide Cescato
Modified: 2010-08-16 13:28 UTC (History)
5 users (show)

Fixed In Version: 3.45-8.fc11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-08-15 08:23:05 UTC
Type: ---


Attachments (Terms of Use)
Input test file causing crash (29.64 KB, application/postscript)
2009-06-25 17:28 UTC, Denis Leroy
no flags Details
Avoid dlclose() in plugin desctructors (261 bytes, patch)
2009-07-16 15:59 UTC, David Nečas
no flags Details | Diff

Description Davide Cescato 2009-06-19 22:38:18 UTC
Description of problem:
When trying to render a LaTeX formula into inkscape, I get a segmentation fault error on the pstoedit process. The formula is rendered correctly, but a popup window reporting the error appears.

I am not sure about which component the bug belongs to. pstoedit, inkscape, and texlive come into my mind.


Version-Release number of selected component (if applicable):
pstoedit-3.45-7.fc11.x86_64


Other possibly relevant components:
inkscape-0.47-0.8.20090508svn.fc11.x86_64
texlive-2007-42.fc11.x86_64
python-lxml-2.2-1.fc11.x86_64


How reproducible:
always


Steps to Reproduce:
1. install the packages above
2. launch inkscape
3. within inkscape, select Extensions -> Render -> LaTeX formula
4. click on the "Apply" button with the default formula untouched


Actual results:
The formula is rendered within inkscape and a popup window appears with the following message:
Inkscape has received additional data from the script executed.  The script did not return an error, but this may indicate the results will not be as expected.
sh: line 1:  3188 Segmentation fault      pstoedit -f plot-svg -dt -ssp "/tmp/inkscape-NH4Er2/eq.ps" "/tmp/inkscape-NH4Er2/eq.svg" > "/tmp/inkscape-NH4Er2/eq.out" 2> "/tmp/inkscape-NH4Er2/eq.err"


Expected results:
The formula is rendered within inkscape, without any error message


Additional info:
Already at the moment where the popup window appears, /tmp does not contain any inkscape-NH4ER2 subdirectory, so there is no obvious way to access the four files whose names appear in the pstoedit command line.

Comment 1 Denis Leroy 2009-06-25 17:28:09 UTC
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...

Comment 2 Denis Leroy 2009-06-25 17:29:31 UTC
Jakub, if you have a few minutes to spare, do you think this could be a gcc-c++ bug ?

Comment 3 Denis Leroy 2009-06-26 06:00:47 UTC
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==

Comment 4 Jakub Jelinek 2009-06-26 07:16:09 UTC
I can't reproduce it, neither with 32-bit nor 64-bit pstoedit.

Comment 5 Denis Leroy 2009-06-29 10:24:49 UTC
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).

Comment 6 David Nečas 2009-07-08 14:20:28 UTC
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.

Comment 7 David Nečas 2009-07-09 08:21:55 UTC
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.

Comment 8 Denis Leroy 2009-07-09 08:33:02 UTC
Pushing a testing update for this, thanks.

Comment 9 Fedora Update System 2009-07-09 08:40:52 UTC
pstoedit-3.45-8.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/pstoedit-3.45-8.fc11

Comment 10 David Nečas 2009-07-09 08:46:34 UTC
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...

Comment 11 Denis Leroy 2009-07-09 08:56:47 UTC
> 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.

Comment 12 David Nečas 2009-07-10 09:01:03 UTC
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.

Comment 13 Fedora Update System 2009-07-16 07:28:53 UTC
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

Comment 14 David Nečas 2009-07-16 14:24:09 UTC
PING?

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

Comment 15 Denis Leroy 2009-07-16 15:06:00 UTC
Have you tried it ? Does it work around the crash ?

Comment 16 David Nečas 2009-07-16 15:56:58 UTC
(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.

Comment 17 David Nečas 2009-07-16 15:59:17 UTC
Created attachment 353999 [details]
Avoid dlclose() in plugin desctructors

Comment 18 Fedora Update System 2009-08-15 08:22:54 UTC
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.

Comment 19 Stanislav Brabec 2010-08-16 13:28:27 UTC
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


Note You need to log in before you can comment on or make changes to this bug.