TrilbyWhite / Slider

PDF presentation tool
GNU General Public License v3.0
54 stars 12 forks source link

SEGFAULT when notes are to be used #11

Closed makkes closed 10 years ago

makkes commented 11 years ago

When I call Slider like this:

slider slides-83-rtcweb-3.pdf output.pdf

then it SEGFAULTs. With certain other files Slider starts but the screen just turns black and I have to KILL the process. Depending on the file sometimes it works.

https://fileboy.makk.es/uploads/a2ce3fd0d9e145cf99664ea650fd2602/slides-83-rtcweb-3.pdf https://fileboy.makk.es/uploads/ab24065302cc4b048909f5becb74ec7c/output.pdf

TrilbyWhite commented 11 years ago

I'll look into this tomorrow when I'm at my multi-monitor setup.

TrilbyWhite commented 11 years ago

I can't replicate this - could this have anything to do with the different glib version?

can you provide strace output? strace slider present.pdf notes.pdf

Also your video configuration may help: xrandr -q

TrilbyWhite commented 11 years ago

Any follow-up on this?

makkes commented 11 years ago
$ xrandr -q
Screen 0: minimum 320 x 200, current 3520 x 1080, maximum 8192 x 8192
LVDS1 connected 1600x900+1920+29 (normal left inverted right x axis y axis) 310mm x 174mm
   1600x900       60.0*+
   1440x900       59.9  
   1360x768       59.8     60.0  
   1152x864       60.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 299mm
   1920x1080      59.9*+   60.0  
   1680x1050      60.0  
   1280x1024      75.0     60.0  
   1280x960       60.0  
   1152x864       75.0  
   1024x768       75.1     60.0  
   832x624        74.6  
   800x600        75.0     60.3     56.2  
   640x480        75.0     60.0  
   720x400        70.1  

And this is the strace output: https://fileboy.makk.es/uploads/113093c9cbd74aa0a4b7e936da198584/slider.out

One more thing: This behaviour is not reproducible 100% of the times. Sometimes the program just ABRTs and sometimes I actually can see the presentation (with the same files provided above).

These are the library versions I got:

$ pkg-config --modversion glib-2.0
2.32.3
$ pkg-config --modversion cairo
1.10.2
$ pkg-config --modversion poppler-glib
0.18.4
TrilbyWhite commented 11 years ago

Thanks, I think I've pinpointed where the problem is - but I'm clueless how it could be a problem. To check that I'm focusing on the right code, though, can you pull the latest revision and build with make debug, then run (until you get the segfault) and post any stderr output that slider provides.

Also, what distro is this?

makkes commented 11 years ago
$ ./slider /tmp/slides-83-rtcweb-3.pdf /tmp/output.pdf 
[slider] render: show=30423808 show->notes=30424176
[slider] render_threaded: arg=[30423808]
[slider] render_threaded: arg=[30424176]
Segmentation fault

I'm on Ubuntu 12.04 LTS

makkes commented 11 years ago

Perhaps this core dump helps, too (EDIT: with debugging symbols now):

Core was generated by `./slider /tmp/slides-83-rtcweb-3.pdf /tmp/output.pdf'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007fdcb40bfca1 in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
(gdb) bt
#0  0x00007fdcb40bfca1 in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#1  0x00007fdcb40c06aa in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#2  0x00007fdcb40c0815 in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#3  0x00007fdcb40c0c66 in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#4  0x00007fdcb40c11af in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#5  0x00007fdcb4075b3d in FT_Outline_Decompose () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#6  0x00007fdcb40bfd55 in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#7  0x00007fdcb40c00f9 in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#8  0x00007fdcb40bf7f8 in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#9  0x00007fdcb40bf9af in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#10 0x00007fdcb4079f78 in FT_Render_Glyph_Internal () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#11 0x00007fdcb5b87034 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#12 0x00007fdcb5b4bdf0 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#13 0x00007fdcb5b6f3bb in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#14 0x00007fdcb5b52265 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#15 0x00007fdcb5b2c14b in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#16 0x00007fdcb5b22b00 in cairo_show_glyphs () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#17 0x00007fdcb603a541 in CairoOutputDev::endString (this=0x7fdca401b000, state=<optimised out>) at CairoOutputDev.cc:1186
#18 0x00007fdcb46c8fbf in Gfx::doShowText (this=<optimised out>, s=0x7fdca4068830) at Gfx.cc:3966
#19 0x00007fdcb46c921d in Gfx::opShowSpaceText (this=0x7fdca403b500, args=<optimised out>, numArgs=<optimised out>) at Gfx.cc:3787
#20 0x00007fdcb46c1461 in Gfx::go (this=0x7fdca403b500, topLevel=true) at Gfx.cc:712
#21 0x00007fdcb46c187e in Gfx::display (this=0x7fdca403b500, obj=<optimised out>, topLevel=true) at Gfx.cc:679
#22 0x00007fdcb46fdbcf in Page::displaySlice (this=0x7fdca40391b0, out=0x7fdca401b000, hDPI=<optimised out>, vDPI=<optimised out>, rotate=<optimised out>, useMediaBox=<optimised out>, crop=true, 
    sliceX=<optimised out>, sliceY=-1, sliceW=-1, sliceH=-1, printing=false, catalog=0x7fdca40194d0, abortCheckCbk=0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0, annotDisplayDecideCbkData=0x0)
    at Page.cc:483
#23 0x00007fdcb6031874 in _poppler_page_render (page=0x7fdcac037b00, cairo=0x7fdcb5dc3f70, printing=false, print_flags=<optimised out>) at poppler-page.cc:360
#24 0x0000000000405d6d in render_threaded ()
#25 0x00007fdcb55f7e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#26 0x00007fdcb5324ccd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#27 0x0000000000000000 in ?? ()
makkes commented 11 years ago

I just discovered that when I comment out the calls to pthread_create() and instead call render_threaded() from the main thread the SEGFAULT doesn't happen.

TrilbyWhite commented 11 years ago

Does this also happen with other files? I initially suspected a problem could come from having notes and slides with different numbers of pages. .... I'm now looking at the code - and there is definitely a mistake relevant to this, though I'd be surprised if it is the cause of this issue.

Slides and notes should have the same number of pages, but slider should definitely not segfault if they don't.

(edit: minor typo)

TrilbyWhite commented 11 years ago

I just corrected the typo in prerendering, where there is a check to ensure the number of pages that should be prerendered is not greater than the number of pages in the pdf - but for the notes, this compared the number to prerender against the number of pages in the main pdf, not the notes.

This certainly could lead to a segfault, but I'm not sure if it would have in this case.

makkes commented 11 years ago

I just pulled your patch and confirmed that it doesn't fix the segfault.

TrilbyWhite commented 11 years ago

What version of the freetype library do you have?

makkes commented 11 years ago
$ freetype-config --ftversion
2.4.8
makkes commented 11 years ago

Have you been able to reproduce this? Anything I could do to help?

TrilbyWhite commented 11 years ago

I'm stumped. I've tried to replicate this on several different computers, but I have yet to see anything like this.

The fact that you only see it some of the time suggests it depends on what else is happening. If you can find any pattern with that, it may help. For example, if you can try other window managers, or try running slider right after a fresh start up, or after loading many resource-hungry programs.

I really don't know where to go next, but any new data points may help narrow it down.

makkes commented 10 years ago

I don't have new data points but your recent changes seem to have removed the SEGFAULTs.

TrilbyWhite commented 10 years ago

Well I'm glad something worked, even if it was by accident.

Slider really has been plagued with hacks and workarounds for memory management. I have plans for a full rewrite with a much cleaner design which should be much less buggy. But that will not be on the way until late winter / early spring.

TrilbyWhite commented 10 years ago

I've just pushed a complete rewrite of slider which avoids the above-mentioned hacks and workarounds. This was by making rendering more efficient so multithreading shouldn't be needed (and thus wasn't used). This makes memory management much easier. So hopefully this issue can be completely put to rest.

Feel free to repoen this or a new issue if problems remain in the new version.