[Poppler-bugs] [Bug 50992] library should be thread-safe

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=50992

--- Comment #127 from Thomas Freitag <Thomas.Freitag at alfa.de> ---
(In reply to comment #126)
> bug-poppler10898.pdf is still crashing here
> 
> time while [ true ]; do
> /home/tsdgeos/devel/poppler/build-debug/utils/pdftoppm -r 72 -cropbox -png
> ../bug-poppler10898.pdf render/foo; if [ $? -ne 0 ]; then break; fi; done
> 
> Will eventually crash (usually in less than 10 seconds, never more than 30s)
> when pdftoppm is the pdftoppm patched to work on threads with the code from
> this bugreport. With poppler 0.22 it won't crash (had it running for 5
> minutes).
> 
> I know bug-poppler10898.pdf is broken, but the fact that pdftoppm is
> crashing randomly seems to imply there's something wrong, maybe something
> even thread-racy in the code.
> 
> Can you reproduce the issue? If not maybe i can give you access to my
> machine so you can give it a try?

It doesn't crashes on my laptop after 5 minutes, but what I can see on the
output and looking again at comment 124 is that page 30 has only 14 bytes, and
when I remember right from experiences in the past, there can be crashes in the
png library with incomplete images (what means there is no really a bitmap).
With pdftoppm without threads the output from page 30 is identical to page 29
(so it uses the former produced bitmap) and therefore will never crash there.
But to attest it, can You give me 
1. the backtrace of the crashing thread
2. the backtrace of all other threads
?
And perhaps You can also try Your loop with poppler 0.22 but only rendering
page 30 with -f 30 -l 30? If I'm right, this should crashes then, too!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler-bugs/attachments/20130107/277e9abe/attachment.html>