On 12/14/2013 07:17 AM, Le_Forgeron wrote:
> Le 14/12/2013 12:38, William F Pokorny nous fit lire :
>> OK. Not an expert, but it looks like the segfault happened in this run
>> in thread 7 (SetPixelScaled in disp_sdl.cpp:353) :
>
> What about thread 1 ? raise is not normal (neither is abort), for a
> std::string operation. Can it be some buffer-overflow (with a gigantic
> message to assign with operator=) ? Or a nullptr ?
>
>
> Thread 1 (Thread 0x7f85a5b4e740 (LWP 11003)):
> #0  0x00007f85a34d5425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x00007f85a34d8b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x00007f85a351339e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #3  0x00007f85a351db96 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #4  0x00007f85a402dff6 in std::string::assign(std::string const&) ()
>     from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #5  0x0000000000422f33 in operator= (__str=..., this=0x7fff16b88570)
>      at /usr/include/c++/4.6/bits/basic_string.h:542
> #6  vfe::vfeSession::GetNextCombinedMessage (this=0x196d870,
>      Type=@0x7fff16b88580: vfe::vfeSession::mGenericStatus, Message=...)
>      at vfesession.cpp:416
> #7  0x0000000000440b72 in PrintStatus (session=0x196d870)
>      at unix/unixconsole.cpp:226
> #8  0x0000000000412c87 in main (argc=7, argv=0x1970518)
>      at unix/unixconsole.cpp:566
>
> Thread 7 is performing a poll(), waiting for some I/O on some file
> descriptor (X11 (provider of SDL) use file descriptor to communicate
> with the X11 server, aka your display), nothing that would crash it.
>
> Nice job at getting such detailed information.
>
I make no claims as expert here. :-)

However, I took what was happened in Thread 1 (agree that looks bad too) 
as coming after what happened in thread 7. We sometimes get very long 
dumps to the xterm window from this crash; sometimes nothing but the 
segfault message; sometimes povray hangs and must be killed manually. 
See David's original post for an example of the longer output which I 
see once in a while too.

In this coredump, I did not get but a short segfault message. Maybe 
sometimes the return text gets extremely large and this is also crashing 
the message handling (string handling)?

An excerpt from the call to the signal handler in thread 7 from (13) is:
#6  0x00007f85a2847870 in XCloseDisplay ()
    from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007f85a57083d2 in ?? () from 
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#8  0x00007f85a56fa75e in SDL_VideoQuit ()
    from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#9  0x00007f85a56d1215 in SDL_QuitSubSystem ()
    from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#10 0x00007f85a56d12ce in SDL_Quit ()
    from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#11 0x00007f85a56d18cf in ?? () from 
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#12 <signal handler called>
#13 0x0000000000417795 in SetPixelScaled (colour=..., y=1002, x=444,
     this=0x7f859000c890) at disp_sdl.cpp:353

It seems odd to me SetPixelScaled is throwing a signal at all for one.

It does here and it looks to me to be closing down the scaled display 
window as a result at (6). The display window in fact always closes even 
on hangs. All this happens while working on a pixel at y=1002 x=444 
which is unlikely to be the last one traced. The better evidence povray 
is not done is that several of the other threads are still working on 
rays. In other words, the image is not complete when thread 7 issues a 
signal which closes the display.

That was my thinking in saying the root cause looks to be in thread 7 - 
though it is perfectly possible I have it all wrong.

Bill P.

Post a reply to this message