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

Le 12/12/2013 18:25, James Dietrich nous fit lire :
> When I perform a render with this command line:
> povray +W2596 +H1003 +Ispiral.pov +Ospiral.png +D
> it fails every time in one of several ways:
>  -> a segmentation fault
>  -> aborted by xcb (example given below)
>  -> aborted by glibc (example given below)
>  -> apparent deadlock (render does not complete and povray process has to be
> killed with kill -9)

Trying on my dual screen system,
 * with icpc 13.0.1 as compiler: no problem
 * with gcc 4.8 as compiler: no problem, but last line of rendering
state is 99% only
 * with clang++ 4.2.1 as compiler: no problem, same 99%

Now, my display is 1920x2 (3840) by 1200.

povray +W4596 +H1003 +Ispiral.pov +Ospiral.png +D
* with clang, segfault
* with gcc, segfault
* with icpc, segfault

adding +WT1 and changing +W12596, I got:
*** Error in `povray': malloc(): smallbin double linked list corrupted:
0x00007f9fe000ca50 ***
(and then a freeze of the povray process)

adding +WT1 +RP5 and still a big enough width, it happens far sooner.
Clang gave me once:
*** Error in `cpovray': free(): invalid next size (fast):
0x00007f3930377d80 ***

If height is reduced to 1000, all is fine with +W4596 and +W12596.
But +H1002 +W12596 dumps a core, whereas +H1002 +W4596 is fine.

Using valgrind, there is a few invalid read and write, and the segfault
seems due to a faulty address 0x0 when we malloc (but it might be a
consequence of some overran block, corrupting the malloc chain)

(attached the valgrind report with memcheck)
valgrind --log-file=memcheck.txt --leak-check=no --malloc-fill=AA
--free-fill=DD dpovray +W4596 +H1003 +Ispiral.pov +Ospiral.png +D +WT1 +RP5

Post a reply to this message

Attachments:
Download 'memcheck.txt' (18 KB)

I got it (but no correction yet)

The issue is in disp_sdl.cpp, UnixSDLDisplay::SetPixelScaled

		unsigned int ix = x * m_display_scale;
		unsigned int iy = y * m_display_scale;
is returning values which combined with

		Uint8 *p = (Uint8 *) m_display->pixels + iy * m_display->pitch + ix *
m_display->format->BytesPerPixel;

get p out of the m_display->pixels array. (and ofs out of PxCount array too)
(BytesPerPixel in my case is 4)

m_display_scale is a float, but m_display->pitch is an integer.

I guess that the current m_display_scale is a round-up representation of
the number m_display_scale = float(width) / GetWidth();
(line 245)

Round-up, because the representation of the exact value is not possible.
And btw, the code does not seems to handle a huge height when width is
small enough)

So, a small exaggeration on the ratio generates a memory corruption when
the display is on and scaled.

Post a reply to this message

I seems to have a fix for it (I tried it locally), but would be glad to
have a confirmation from the original poster if possible:

In unix/disp_sdl.cpp, change the computation of m_display_scale (circa
line 245) with:

m_display_scale = min(float(width) / GetWidth(), float(height)/GetHeight());

Post a reply to this message

On 12/14/2013 03:40 PM, Le_Forgeron wrote:
>
> I seems to have a fix for it (I tried it locally), but would be glad to
> have a confirmation from the original poster if possible:
>
> In unix/disp_sdl.cpp, change the computation of m_display_scale (circa
> line 245) with:
>
> m_display_scale = min(float(width) / GetWidth(), float(height)/GetHeight());
>
>
I am of course not the original poster, but this fix is working in my 
testing.

My apologies, James Dietrich, for calling you David in an earlier post. 
I've not a clue where I got that name. I'm getting old and all too often 
my brain glitches...

Bill P.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> I seems to have a fix for it (I tried it locally), but would be glad to
> have a confirmation from the original poster if possible:
>
> In unix/disp_sdl.cpp, change the computation of m_display_scale (circa
> line 245) with:
>
> m_display_scale = min(float(width) / GetWidth(), float(height)/GetHeight());

I will try the above fix tomorrow, and will report back with my results.

Thanks to all of you who have been working on this.

James Dietrich

Post a reply to this message

"James Dietrich" <jdi### [at] fastmailfm> wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> > I seems to have a fix for it (I tried it locally), but would be glad to
> > have a confirmation from the original poster if possible:
> >
> > In unix/disp_sdl.cpp, change the computation of m_display_scale (circa
> > line 245) with:
> >
> > m_display_scale = min(float(width) / GetWidth(), float(height)/GetHeight());
>
> I will try the above fix tomorrow, and will report back with my results.

OK, I can now confirm that this does fix the issue for me.

Thanks again to each of you who helped with this.

James Dietrich

Post a reply to this message