Hello,

http://wiki.povray.org/content/HowTo:Make_A_Bug_Report instructed me to come
here first before submitting a bug report. Please let me know if I should submit
this to the bug tracker.

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)

If, instead, I change the +D to -D:
povray +W2596 +H1003 +Ispiral.pov +Ospiral.png -D
the render always completes successfully.

It seems that the problem is not in the povray file. I reduced my original
povray file to the following, and the problem still occurs as described above.
Then I tried a different povray file that I had written over three years ago,
and the problem happened in exactly the same way.
---------------spiral.pov-----------------
#version 3.7;
global_settings {
    assumed_gamma 1.0
}

camera {
    location <0, 0, -30>
    right <2, 0, 0>
    angle 25
    look_at <0, 0, 0>
}

light_source { <20, 30, -50>, color rgb 1 }

box {
    <-5, -2, -1>, <5, 2, 1>
    pigment {
        color rgb 1
    }
}
------------------------------------------

The problem is related to the exact dimensions of the output file--the +W and +H
options. For example, if I change the +H1003 to +H1004, the render completes
successfully with +D.

I am currently running povray 3.7.0 cloned from
https://github.com/POV-Ray/povray.git (latest commit is d60416f4cb). I compiled
it myself on a machine running 64-bit Debian 7.2. But I don't think the exact
version of Povray matters in this case, because I first noted this problem with
3.7.0.RC7.

Please let me know if any other information would be helpful, or if there's
anything else I can do to help track this down.

Thank you.

James Dietrich


Here's an example of an xcb abort:
==== [Rendering...] ========================================================
[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been
called
[xcb] Aborting, sorry about that.
povray: ../../src/xcb_io.c:179: dequeue_pending_request: Assertion
`!xcb_xlib_unknown_req_in_deq' failed.
Aborted


Here's an example of a glibc abort:
==== [Rendering...] ========================================================
*** glibc detected *** povray: corrupted double-linked list: 0x0000000001ccf290
***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x76d76)[0x7fe85838fd76]
/lib/x86_64-linux-gnu/libc.so.6(+0x78777)[0x7fe858391777]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7fe858394aac]
povray[0x4b9e57]
povray[0x422c34]
/usr/lib/libboost_thread.so.1.49.0(+0x10629)[0x7fe85a944629]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50)[0x7fe8586a9b50]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fe8583f3a7d]
======= Memory map: ========
00400000-006a0000 r-xp 00000000 08:02 2249279
/usr/local/bin/povray
008a0000-008a6000 rw-p 002a0000 08:02 2249279
/usr/local/bin/povray
008a6000-008c8000 rw-p 00000000 00:00 0
00c95000-01f09000 rw-p 00000000 00:00 0                                  [heap]
7fe840000000-7fe840fe6000 rw-p 00000000 00:00 0
7fe840fe6000-7fe844000000 ---p 00000000 00:00 0
7fe84701f000-7fe84757e000 rw-p 00000000 00:00 0
7fe847add000-7fe84803c000 rw-s 00000000 00:04 47710231
/SYSV00000000 (deleted)
7fe84803c000-7fe848041000 r-xp 00000000 08:02 2109057
/usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0
7fe848041000-7fe848240000 ---p 00005000 08:02 2109057
/usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0
7fe848240000-7fe848241000 r--p 00004000 08:02 2109057
/usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0
7fe848241000-7fe848242000 rw-p 00005000 08:02 2109057
/usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0
7fe848242000-7fe84824b000 r-xp 00000000 08:02 2112518
/usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7fe84824b000-7fe84844a000 ---p 00009000 08:02 2112518
/usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7fe84844a000-7fe84844b000 rw-p 00008000 08:02 2112518
/usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7fe84844b000-7fe848455000 r-xp 00000000 08:02 2112520
/usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2
7fe848455000-7fe848654000 ---p 0000a000 08:02 2112520
/usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2
7fe848654000-7fe848655000 rw-p 00009000 08:02 2112520
/usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2
7fe848655000-7fe848656000 ---p 00000000 00:00 0
7fe848656000-7fe84c000000 rw-p 00000000 00:00 0
7fe84c000000-7fe84c7c6000 rw-p 00000000 00:00 0
7fe84c7c6000-7fe850000000 ---p 00000000 00:00 0
7fe85018f000-7fe850203000 rw-p 00000000 00:00 0
7fe8502e4000-7fe85045b000 r--p 00000000 08:02 2106752
/usr/lib/locale/locale-archive
7fe85045b000-7fe85045c000 ---p 00000000 00:00 0
7fe85045c000-7fe850c5c000 rw-p 00000000 00:00 0
7fe850e23000-7fe850e24000 ---p 00000000 00:00 0
7fe850e24000-7fe851624000 rw-p 00000000 00:00 0
[stack:5680]
7fe851624000-7fe851625000 ---p 00000000 00:00 0
7fe851625000-7fe851e25000 rw-p 00000000 00:00 0
[stack:5677]
7fe851e25000-7fe851e26000 ---p 00000000 00:00 0
7fe851e26000-7fe852626000 rw-p 00000000 00:00 0
[stack:5676]
7fe852626000-7fe852627000 ---p 00000000 00:00 0
7fe852627000-7fe852e27000 rw-p 00000000 00:00 0
[stack:5675]
7fe852e27000-7fe852e28000 ---p 00000000 00:00 0
7fe852e28000-7fe853628000 rw-p 00000000 00:00 0
[stack:5674]
7fe853628000-7fe85363b000 r-xp 00000000 08:02 1050645
/lib/x86_64-linux-gnu/libresolv-2.13.so
7fe85363b000-7fe85383a000 ---p 00013000 08:02 1050645
/lib/x86_64-linux-gnu/libresolv-2.13.so
7fe85383a000-7fe85383b000 r--p 00012000 08:02 1050645
/lib/x86_64-linux-gnu/libresolv-2.13.so
7fe85383b000-7fe85383c000 rw-p 00013000 08:02 1050645
/lib/x86_64-linux-gnu/libresolv-2.13.so
7fe85383c000-7fe85383e000 rw-p 00000000 00:00 0
7fe85383e000-7fe853844000 r-xp 00000000 08:02 2112657
/usr/lib/x86_64-linux-gnu/libogg.so.0.8.0
7fe853844000-7fe853a43000 ---p 00006000 08:02 2112657
/usr/lib/x86_64-linux-gnu/libogg.so.0.8.0
7fe853a43000-7fe853a44000 rw-p 00005000 08:02 2112657
/usr/lib/x86_64-linux-gnu/libogg.so.0.8.0
7fe853a44000-7fe853a70000 r-xp 00000000 08:02 2112661
/usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5
7fe853a70000-7fe853c6f000 ---p 0002c000 08:02 2112661
/usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5
7fe853c6f000-7fe853c70000 r--p 0002b000 08:02 2112661
/usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5
7fe853c70000-7fe853c71000 rw-p 0002c000 08:02 2112661
/usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5
7fe853c71000-7fe853f24000 r-xp 00000000 08:02 2113734
/usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8
7fe853f24000-7fe854123000 ---p 002b3000 08:02 2113734
/usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8
7fe854123000-7fe85413f000 r--p 002b2000 08:02 2113734
/usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8
7fe85413f000-7fe854140000 rw-p 002ce000 08:02 2113734
/usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8
7fe854140000-7fe85418b000 r-xp 00000000 08:02 2121497
/usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0
7fe85418b000-7fe85438a000 ---p 0004b000 08:02 2121497
/usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0
7fe85438a000-7fe85438b000 r--p 0004a000 08:02 2121497
/usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0
7fe85438b000-7fe85438c000 rw-p 0004b000 08:02 2121497
/usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0
7fe85438c000-7fe8543a1000 r-xp 00000000 08:02 1050647
/lib/x86_64-linux-gnu/libnsl-2.13.so
7fe8543a1000-7fe8545a0000 ---p 00015000 08:02 1050647
/lib/x86_64-linux-gnu/libnsl-2.13.so
7fe8545a0000-7fe8545a1000 r--p 00014000 08:02 1050647
/lib/x86_64-linux-gnu/libnsl-2.13.so
7fe8545a1000-7fe8545a2000 rw-p 00015000 08:02 1050647
/lib/x86_64-linux-gnu/libnsl-2.13.so
7fe8545a2000-7fe8545a4000 rw-p 00000000 00:00 0
7fe8545a4000-7fe8545b2000 r-xp 00000000 08:02 2112823
/usr/lib/x86_64-linux-gnu/libXi.so.6.1.0
7fe8545b2000-7fe8547b2000 ---p 0000e000 08:02 2112823
/usr/lib/x86_64-linux-gnu/libXi.so.6.1.0
7fe8547b2000-7fe8547b3000 rw-p 0000e000 08:02 2112823
/usr/lib/x86_64-linux-gnu/libXi.so.6.1.0
7fe8547b3000-7fe8547b7000 r-xp 00000000 08:02 1050671
/lib/x86_64-linux-gnu/libattr.so.1.1.0
7fe8547b7000-7fe8549b6000 ---p 00004000 08:02 1050671
/lib/x86_64-linux-gnu/libattr.so.1.1.0
7fe8549b6000-7fe8549b7000 r--p 00003000 08:02 1050671
/lib/x86_64-linux-gnu/libattr.so.1.1.0
7fe8549b7000-7fe8549b8000 rw-p 00004000 08:02 1050671
/lib/x86_64-linux-gnu/libattr.so.1.1.0
7fe8549b8000-7fe8549bd000 r-xp 00000000 08:02 2121449
/usr/lib/x86_64-linux-gnu/libasyncns.so.0.3.1Aborted

Post a reply to this message

On 12/12/2013 12:25 PM, James Dietrich wrote:
> Hello,
>
> http://wiki.povray.org/content/HowTo:Make_A_Bug_Report instructed me to come
> here first before submitting a bug report. Please let me know if I should submit
> this to the bug tracker.
>
> 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)
>
> If, instead, I change the +D to -D:
> povray +W2596 +H1003 +Ispiral.pov +Ospiral.png -D
> the render always completes successfully.

curious ... does your monitor support that resolution? I've seen 
weirdness when it attempts to scale the preview window to fit your 
monitor, but never an outright abort.

Post a reply to this message

James Holsenback <nom### [at] nonecom> wrote:
> On 12/12/2013 12:25 PM, James Dietrich wrote:
> > Hello,
> >
> > http://wiki.povray.org/content/HowTo:Make_A_Bug_Report instructed me to come
> > here first before submitting a bug report. Please let me know if I should submit
> > this to the bug tracker.
> >
> > 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)
> >
> > If, instead, I change the +D to -D:
> > povray +W2596 +H1003 +Ispiral.pov +Ospiral.png -D
> > the render always completes successfully.
>
> curious ... does your monitor support that resolution? I've seen
> weirdness when it attempts to scale the preview window to fit your
> monitor, but never an outright abort.

The native resolution of my monitor is 1920x1200, and it also supports other
lower-resolution modes. So it is having to scale the preview window. But I've
never had it fail like this before.

Post a reply to this message

On 12/12/2013 12:25 PM, James Dietrich wrote:
> Hello,
>
> http://wiki.povray.org/content/HowTo:Make_A_Bug_Report instructed me to come
> here first before submitting a bug report. Please let me know if I should submit
> this to the bug tracker.
>
> 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)
I have confirmed this coredump with RC7 (been busy so haven't been able 
to grab newer code) but I don't have a version compiled with debug 
symbols so not much more help than what James has already posted.

I'm running Ubuntu 12.01 on a monitor with the same native resolution of 
1980 by 1200.

Segmentation fault (core dumped)ls (92%) <-- % finished varies with 
small example James posted.

I captured a core file an tried to look at it with gdb.

(gdb) bt
#0  0x0000000000417745 in ?? ()
#1  0x00000000005ac499 in ?? ()
#2  0x00000000004559d4 in ?? ()
#3  0x0000000000598973 in ?? ()
#4  0x00000000005ebabe in ?? ()
#5  0x00000000005b5c63 in ?? ()
#6  0x00000000005b891e in ?? ()
#7  0x0000000000421c7f in ?? ()
#8  0x00007fcfffb04ce9 in thread_proxy ()
    from /usr/lib/libboost_thread.so.1.46.1
#9  0x00007fcfff0d0e9a in start_thread ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
#10 0x00007fcffedfd3fd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#11 0x0000000000000000 in ?? ()

I tried this with one thread and oddly that works fine.

If I run an isosurface taking a lot longer to render I see a dump more 
like the first James posted starting with:

==== [Rendering...] ========================================================
*** glibc detected *** povray: munmap_chunk(): invalid pointer: 
0x00007fd40c1c37f0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fd41dc47b96]
povray[0x5ac3c2]
povray[0x4559d4]
povray[0x598973]
povray[0x5ebabe]
povray[0x5b5c63]
povray[0x5b891e]
povray[0x421c7f]
/usr/lib/libboost_thread.so.1.46.1(thread_proxy+0x69)[0x7fd41e9c4ce9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7fd41df90e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fd41dcbd3fd]
======= Memory map: ========
....

I am very curious James, what led you to the odd render resolution?

Aside: Newer versions of the boost thread library are available and 
yours at 1.49.0 is newer than mine. I've had no reason to date to try 
them. There are also some boost and pthread options during configuration 
many use to get clean builds, but again I've not had reason myself to 
try them.

Sorry not more help. If I get time this weekend, I'll try recompiling 
for debugging so the backtrace is perhaps more meaningful.
Bill P.

Post a reply to this message

I thought I would try compiling a version with debug symbols in the hopes of
getting a meaningful backtrace, but was unable to do so.

I ran ./configure this way:
../configure --enable-debug --disable-optimiz COMPILED_BY="James Dietrich
<my_email@address>"
and the compilation process eventually failed with this:

Making all in unix
make[2]: Entering directory `/usr/local/povray/povray/unix'
g++ -DHAVE_CONFIG_H -I. -I..  -I.. -I../source -I../source -I../source/backend
-I../source/base -I../source/frontend -I../vfe -I../vfe/unix -I/usr/include/SDL
-D_GNU_SOURCE=1 -D_REENTRANT  -pthread -I/usr/include  -I/usr/include  -pipe
-Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -g -pthread -MT
disp_sdl.o -MD -MP -MF .deps/disp_sdl.Tpo -c -o disp_sdl.o disp_sdl.cpp
mv -f .deps/disp_sdl.Tpo .deps/disp_sdl.Po
g++ -DHAVE_CONFIG_H -I. -I..  -I.. -I../source -I../source -I../source/backend
-I../source/base -I../source/frontend -I../vfe -I../vfe/unix -I/usr/include/SDL
-D_GNU_SOURCE=1 -D_REENTRANT  -pthread -I/usr/include  -I/usr/include  -pipe
-Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -g -pthread -MT
disp_text.o -MD -MP -MF .deps/disp_text.Tpo -c -o disp_text.o disp_text.cpp
mv -f .deps/disp_text.Tpo .deps/disp_text.Po
g++  -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -g -pthread
-L/usr/lib  -L/usr/lib -o povray disp_sdl.o disp_text.o ../vfe/libvfe.a
.../source/libpovray.a -lSDL -L/usr/lib/x86_64-linux-gnu -lSDL -lXpm  -lSM -lICE
-lX11  -ltiff -ljpeg -lpng -lz -lrt -lm -lboost_thread-mt  -pthread
-lboost_system
.../source/libpovray.a(png.o): In function
`boost::date_time::month_formatter<boost::gregorian::greg_month,
boost::date_time::iso_extended_format<char>,
char>::format_month(boost::gregorian::greg_month const&, std::ostream&)':
/usr/include/boost/date_time/date_formatting.hpp:44: undefined reference to
`boost::gregorian::greg_month::as_short_string() const'
/usr/include/boost/date_time/date_formatting.hpp:49: undefined reference to
`boost::gregorian::greg_month::as_long_string() const'
collect2: error: ld returned 1 exit status
make[2]: *** [povray] Error 1
make[2]: Leaving directory `/usr/local/povray/povray/unix'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/povray/povray'
make: *** [all] Error 2

If someone can help me with this, I'll be glad to try again to create a better
backtrace, if that would be helpful.

Thanks you,
James

P.S. Bill, since you're curious about the odd render resolution, here's how it
happened. Our organization sells a variety of spiralbound products. The spirals
are many different colors, and a couple different sizes, too. Photographing
these items (for our catalog & website) did not lead to the best results, so I
finally decided to render the product images in povray. I created a povray file
that will produce a spiralbound cover image or a spiralbound open spread. The
size and color of the spiral, the height and width of the product, the position
of the spiral (top or left), whether to make a closed book or an open spread,
the thickness of the product, as well as the image(s) to use can all be
specified. I am quite pleased with the results.

This problem arose when I came to producing an open spread of our 5.5x4.25 inch
booklets. I wanted the resulting image to be approximately 900 pixels high so it
could be printed up to three inches high and still have at least 300 dpi. Some
empty/transparent area would of course be trimmed off all the sides, so I
decided to make povray render it about 1000 pixels high. So I found the lowest
integer that, when multiplied by 4.25, would give an integer result equal to or
greater than 1000. That integer was 236. 4.25*236=1003; 5.5*236=1298, and that
gets multiplied by two for the open spread to give 2596.

Post a reply to this message

On 12/13/2013 11:37 AM, James Dietrich wrote:
> I thought I would try compiling a version with debug symbols in the hopes of
> getting a meaningful backtrace, but was unable to do so.
>
> I ran ./configure this way:
> ../configure --enable-debug --disable-optimiz COMPILED_BY="James Dietrich
> <my_email@address>"
> and the compilation process eventually failed with this:

<snip>

> If someone can help me with this, I'll be glad to try again to create a better
> backtrace, if that would be helpful.

try adding LIBS="-lboost_system -lboost_thread" at configure time

Post a reply to this message

Le 13/12/2013 18:34, James Holsenback nous fit lire :
> On 12/13/2013 11:37 AM, James Dietrich wrote:
>> I thought I would try compiling a version with debug symbols in the
>> hopes of
>> getting a meaningful backtrace, but was unable to do so.
>>
>> I ran ./configure this way:
>> ../configure --enable-debug --disable-optimiz COMPILED_BY="James Dietrich
>> <my_email@address>"
>> and the compilation process eventually failed with this:
> 
> <snip>
> 
>> If someone can help me with this, I'll be glad to try again to create
>> a better
>> backtrace, if that would be helpful.
> 
> try adding LIBS="-lboost_system -lboost_thread" at configure time
> 
Wrong suggestion... IMVHO.

The issue is tied to boost not liking the -O0 when handling the
Gregorian calendar (and the use of some version of g++)... Boost used to
have the opposite issue: not allowing Gregorian date with gcc 4.3 and
optimization above -O0. (corrected in 1.38 of boost).

Unless the suggestion by James worked, I would suggest doing (for the
purpose of getting a binary with previous option) to edit metadata.h
(source/base/image) to hard code the date and related function.
(and removing the "boost::gregorian::date              date;" member)

Post a reply to this message

On 12/13/2013 02:24 PM, Le_Forgeron wrote:
> Le 13/12/2013 18:34, James Holsenback nous fit lire :
>> On 12/13/2013 11:37 AM, James Dietrich wrote:
>>> I thought I would try compiling a version with debug symbols in the
>>> hopes of
>>> getting a meaningful backtrace, but was unable to do so.
>>>
>>> I ran ./configure this way:
>>> ../configure --enable-debug --disable-optimiz COMPILED_BY="James Dietrich
>>> <my_email@address>"
>>> and the compilation process eventually failed with this:
>>
>> <snip>
>>
>>> If someone can help me with this, I'll be glad to try again to create
>>> a better
>>> backtrace, if that would be helpful.
>>
>> try adding LIBS="-lboost_system -lboost_thread" at configure time
>>
> Wrong suggestion... IMVHO.

Yep ... concur

>
> The issue is tied to boost not liking the -O0 when handling the
> Gregorian calendar (and the use of some version of g++)... Boost used to
> have the opposite issue: not allowing Gregorian date with gcc 4.3 and
> optimization above -O0. (corrected in 1.38 of boost).
>
> Unless the suggestion by James worked, I would suggest doing (for the
> purpose of getting a binary with previous option) to edit metadata.h
> (source/base/image) to hard code the date and related function.
> (and removing the "boost::gregorian::date              date;" member)

Now that you mention it this has been brought up before. Sheesh ... I'm 
gettin' old

Post a reply to this message

On 12/13/2013 06:56 AM, William F Pokorny wrote:
> Sorry not more help. If I get time this weekend, I'll try recompiling
> for debugging so the backtrace is perhaps more meaningful.
> Bill P.

OK. Not an expert, but it looks like the segfault happened in this run 
in thread 7 (SetPixelScaled in disp_sdl.cpp:353) :

Thread 7 (Thread 0x7f859ecb3700 (LWP 11005)):
#0  0x00007f85a3587a43 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f85a1684862 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007f85a1685d7f in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007f85a1685f9b in xcb_wait_for_reply ()
    from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#4  0x00007f85a286af5d in _XReply () from 
/usr/lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007f85a286699d in XSync () from 
/usr/lib/x86_64-linux-gnu/libX11.so.6
#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
#14 pov_frontend::UnixSDLDisplay::DrawPixelBlock (this=0x7f859000c890,
     x1=<optimized out>, y1=<optimized out>, x2=<optimized out>,
     y2=<optimized out>, colour=0x7f85901cd760) at disp_sdl.cpp:551
#15 0x00000000005acb59 in 
pov_frontend::ImageMessageHandler::DrawPixelBlockSet
     (this=<optimized out>, sd=..., vd=..., msg=...)
     at imagemessagehandler.cpp:267
#16 0x0000000000456094 in 
pov_frontend::RenderFrontend<vfe::vfeParserMessageHandler, 
pov_frontend::FileMessageHandler, vfe::vfeRenderMessageHandler, 
pov_frontend::ImageMessageHandler>::HandleImageMessage 
(this=0x7f859000ace8, vid=...,
     ident=1350058579, msg=...) at ../source/frontend/renderfrontend.h:881
#17 0x0000000000599033 in pov_frontend::RenderFrontendBase::HandleMessage (
     this=0x7f859000ace8, msg=..., result=...) at renderfrontend.cpp:642
#18 0x00000000005ec17e in POVMS_MessageReceiver::ReceiveHandler (
     msg=0x7f859ecb2c30, result=0x7f859ecb2c40, mode=1,
     privatedataptr=<optimized out>) at povmscpp.cpp:1773
#19 0x00000000005b6323 in POVMS_Receive (contextref=0x7f85900008e0,
     msg=0x7f859ecb2c30, result=0x7f859ecb2c40, mode=1) at povms.cpp:961
#20 0x00000000005b8fde in POVMS_ProcessMessages (contextref=0x7f85900008e0,
     blocking=<optimized out>, yielding=<optimized out>) at povms.cpp:691
#21 0x0000000000421ccf in vfe::vfeSession::WorkerThread (this=0x196d870)
     at vfesession.cpp:666
#22 0x00007f85a429ace9 in thread_proxy ()
    from /usr/lib/libboost_thread.so.1.46.1
#23 0x00007f85a3866e9a in start_thread ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
#24 0x00007f85a35933fd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#25 0x0000000000000000 in ?? ()


Line 353 in ./unix/disp_sdl.cpp is :

SDL_GetRGBA(old, m_display->format, &r, &g, &b, &a);

Attaching the full thread backtrace but it looked to me like other 
threads were in the middle of normal-ish things or waiting to run.

Bill P.

Post a reply to this message

Attachments:
Download 'utf-8' (45 KB)

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.

Post a reply to this message