I wrote that I was trying the origin/master branch.  It ran my credits 
scene just fine, but it tips over often in unix, rendering my first 
scene.  It usually parses the whole scene before crashing.

Here's a stack trace:

[Switching to Thread 0x7ffff7ff7700 (LWP 4719)]
0x000000000047bbab in shared_ptr<pov::BackendSceneData> (r=..., 
this=0x7ffff7fe7440) at /usr/include/boost/smart_ptr/shared_ptr.hpp:432
432         BOOST_NOEXCEPT : px( r.px ), pn( r.pn )
(gdb) back
#0  0x000000000047bbab in shared_ptr<pov::BackendSceneData> (r=..., 
this=0x7ffff7fe7440) at /usr/include/boost/smart_ptr/shared_ptr.hpp:432
#1  pov::View::CheckCameraHollowObject (this=this@entry=0x7fffe40035c0, 
point=..., node=0x7fffd8097c40) at backend/scene/view.cpp:619
#2  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=..., node=0x7fffd86b4430) at 
backend/scene/view.cpp:613
#3  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=..., node=0x7fffd8025b50) at 
backend/scene/view.cpp:613
#4  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=..., node=0x7fffd8004aa0) at 
backend/scene/view.cpp:613
#5  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=..., node=0x7fffd80085f0) at 
backend/scene/view.cpp:613
#6  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=..., node=0x7fffd80095f0) at 
backend/scene/view.cpp:613
#7  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=..., node=0x7fffd8009aa0) at 
backend/scene/view.cpp:613
#8  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=..., node=0x7fffd8009c50) at 
backend/scene/view.cpp:613
#9  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=0x7fffe40035c0, point=..., node=0x7fffd8009d00) at 
backend/scene/view.cpp:613
#10 0x000000000047bdb5 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=...) at backend/scene/view.cpp:658
#11 0x000000000047ca1e in pov::View::StartRender (this=0x7fffe40035c0, 
renderOptions=...) at backend/scene/view.cpp:939
#12 0x0000000000470512 in pov::RenderBackend::StartRender 
(this=0x7ffff7ff6d80, msg=...) at backend/control/renderbackend.cpp:611
#13 0x00000000004de0e6 in POVMS_MessageReceiver::ReceiveHandler 
(msg=0x7ffff7ff6ca0, result=0x7ffff7ff6cc0, mode=1, 
privatedataptr=<optimized out>) at povms/povmscpp.cpp:1715
#14 0x00000000004d8cd7 in POVMS_Receive 
(contextref=contextref@entry=0x7fffe40008c0, 
msg=msg@entry=0x7ffff7ff6ca0, result=result@entry=0x7ffff7ff6cc0, 
mode=1) at povms/povms.c:880
#15 0x00000000004dc8d0 in POVMS_ProcessMessages 
(contextref=0x7fffe40008c0, blocking=blocking@entry=true, 
yielding=yielding@entry=true) at povms/povms.c:610
#16 0x000000000046dede in (anonymous namespace)::MainThreadFunction 
(threadExit=...) at backend/povray.cpp:551
#17 0x00007ffff671ba4a in boost::(anonymous namespace)::thread_proxy 
(param=<optimized out>) at libs/thread/src/pthread/thread.cpp:164
#18 0x00007ffff5ad6184 in start_thread (arg=0x7ffff7ff7700) at 
pthread_create.c:312
#19 0x00007ffff580337d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

-- 
dik

Post a reply to this message

Am 12.02.2017 um 10:43 schrieb dick balaska:
> I wrote that I was trying the origin/master branch.  It ran my credits
> scene just fine, but it tips over often in unix, rendering my first
> scene.  It usually parses the whole scene before crashing.
> 
> Here's a stack trace:

Hmmm... doesn't tell me much.
You might want to try the master branch up /now/. It reduces the
probability of /some/ type of crash.

Post a reply to this message

Am 2017-02-12 05:53, also sprach clipka:
> Am 12.02.2017 um 10:43 schrieb dick balaska:

>> Here's a stack trace:
>
> Hmmm... doesn't tell me much.

Bummer, I was hoping there would be a recursive CheckCameraHollowObject 
lightbulb.

> You might want to try the master branch up /now/. It reduces the
> probability of /some/ type of crash.
>

Not so good.

Interestingly, it doesn't build with --disable-optimiz
$ ./configure --enable-debug --disable-optimiz COMPILED_BY="me"
...
../source/libpovray.a(metadata.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

But it builds with default optimiz (-O3)

It's the same crash again.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7ff7700 (LWP 27541)]
0x000000000047bbab in shared_ptr<pov::BackendSceneData> (r=..., 
this=0x7ffff7fe7440) at /usr/include/boost/smart_ptr/shared_ptr.hpp:432
432         BOOST_NOEXCEPT : px( r.px ), pn( r.pn )
(gdb) back
#0  0x000000000047bbab in shared_ptr<pov::BackendSceneData> (r=..., 
this=0x7ffff7fe7440) at /usr/include/boost/smart_ptr/shared_ptr.hpp:432
#1  pov::View::CheckCameraHollowObject (this=this@entry=0x7fffe40035c0, 
point=..., node=0x7fffd8097e80) at backend/scene/view.cpp:619
#2  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=..., node=0x7fffd86b4620) at 
backend/scene/view.cpp:613
#3  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=..., node=0x7fffd8025d40) at 
backend/scene/view.cpp:613
#4  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=..., node=0x7fffd8004c90) at 
backend/scene/view.cpp:613
#5  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=..., node=0x7fffd80087e0) at 
backend/scene/view.cpp:613
#6  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=..., node=0x7fffd80097e0) at 
backend/scene/view.cpp:613
#7  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=..., node=0x7fffd8009c90) at 
backend/scene/view.cpp:613
#8  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=..., node=0x7fffd8009e40) at 
backend/scene/view.cpp:613
#9  0x000000000047bc52 in pov::View::CheckCameraHollowObject 
(this=0x7fffe40035c0, point=..., node=0x7fffd8009ef0) at 
backend/scene/view.cpp:613
#10 0x000000000047bdb5 in pov::View::CheckCameraHollowObject 
(this=this@entry=0x7fffe40035c0, point=...) at backend/scene/view.cpp:658
#11 0x000000000047ca1e in pov::View::StartRender (this=0x7fffe40035c0, 
renderOptions=...) at backend/scene/view.cpp:939
#12 0x0000000000470512 in pov::RenderBackend::StartRender 
(this=0x7ffff7ff6d80, msg=...) at backend/control/renderbackend.cpp:611
#13 0x00000000004de0e6 in POVMS_MessageReceiver::ReceiveHandler 
(msg=0x7ffff7ff6ca0, result=0x7ffff7ff6cc0, mode=1, 
privatedataptr=<optimized out>) at povms/povmscpp.cpp:1715
#14 0x00000000004d8cd7 in POVMS_Receive 
(contextref=contextref@entry=0x7fffe40008c0, 
msg=msg@entry=0x7ffff7ff6ca0, result=result@entry=0x7ffff7ff6cc0, 
mode=1) at povms/povms.c:880
#15 0x00000000004dc8d0 in POVMS_ProcessMessages 
(contextref=0x7fffe40008c0, blocking=blocking@entry=true, 
yielding=yielding@entry=true) at povms/povms.c:610
#16 0x000000000046dede in (anonymous namespace)::MainThreadFunction 
(threadExit=...) at backend/povray.cpp:551
#17 0x00007ffff671ba4a in boost::(anonymous namespace)::thread_proxy 
(param=<optimized out>) at libs/thread/src/pthread/thread.cpp:164
#18 0x00007ffff5ad6184 in start_thread (arg=0x7ffff7ff7700) at 
pthread_create.c:312
#19 0x00007ffff580337d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb)


I ran it several times and it always crashed with that trace.
The good news is, it is something specific in my code that I should be 
able to narrow down to at least give you an sdl sample. It ran my 
credits scene fine. So it dies once I populate that room with my 
objects. I'll play with what object does it. (The picture of my naked 
wife on the wall?)

-- 
dik

Post a reply to this message

On 02/12/2017 07:30 AM, dick balaska wrote:
>
> Bummer, I was hoping there would be a recursive CheckCameraHollowObject
> lightbulb.
>
>> You might want to try the master branch up /now/. It reduces the
>> probability of /some/ type of crash.
>>
>
> Not so good.
>
> Interestingly, it doesn't build with --disable-optimiz
> $ ./configure --enable-debug --disable-optimiz COMPILED_BY="me"
> ...
> ../source/libpovray.a(metadata.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
>
> But it builds with default optimiz (-O3)
>
In my experience, it has been necessary for a long while to run 
configure for debug compiles adding: LIBS="-lboost_date_time"

Does this addition to ./configure fix your debug configure/compile?

Bill P.

Post a reply to this message

Am 12.02.2017 um 13:30 schrieb dick balaska:
> Am 2017-02-12 05:53, also sprach clipka:
>> Am 12.02.2017 um 10:43 schrieb dick balaska:
> 
>>> Here's a stack trace:
>>
>> Hmmm... doesn't tell me much.
> 
> Bummer, I was hoping there would be a recursive CheckCameraHollowObject
> lightbulb.

Nope; that's just traversal of a bounding box tree. Nothing strange there.


>> You might want to try the master branch up /now/. It reduces the
>> probability of /some/ type of crash.
>>
> 
> Not so good.
> 
> Interestingly, it doesn't build with --disable-optimiz
> $ ./configure --enable-debug --disable-optimiz COMPILED_BY="me"

To quote from `unix/install.txt` (which `unix/prebuild.sh` will copy to
`./INSTALL`), section 2.3 "Compatibility issues":

------------------------------------------------------------------
When configured with "--disable-optimiz", linkage may fail in some
cases, reporting undefined references related to
"boost::gregorian::greg_month". To work around this issue, use the
configure option "LDFLAGS=-lboost_date_time".
------------------------------------------------------------------


> I ran it several times and it always crashed with that trace.
> The good news is, it is something specific in my code that I should be
> able to narrow down to at least give you an sdl sample. It ran my
> credits scene fine. So it dies once I populate that room with my
> objects. I'll play with what object does it. (The picture of my naked
> wife on the wall?)

Providing me with a minimal test scene for further analysis is certainly
a good idea. (By all means try to replace that picture with something
less private though ;)

Post a reply to this message

Am 2017-02-12 10:09, also sprach clipka:

> To quote

What is with you people and the RTFM?

-- 
dik

Post a reply to this message

On 2/12/2017 9:42 PM, dick balaska wrote:
> Am 2017-02-12 10:09, also sprach clipka:
>
>> To quote
>
> What is with you people and the RTFM?
>

That's nothing. When I first wandered here about 15 years ago. It was 
RTFM here, RTFM there.

I think the above was helpfulness.


-- 

Regards
     Stephen

Post a reply to this message

Am 12.02.2017 um 22:42 schrieb dick balaska:
> Am 2017-02-12 10:09, also sprach clipka:
> 
>> To quote
> 
> What is with you people and the RTFM?

You mean the old-school "I know the answer but the only thing I'll tell
you is that it's documented /somewhere/" flavour of RTFM?

We don't do that anymore.
Why do you ask? ;)

Post a reply to this message

Am 2017-02-12 10:09, also sprach clipka:

> Providing me with a minimal test scene for further analysis is certainly
> a good idea. (By all means try to replace that picture with something
> less private though ;)
>

You get a povray'd arrow instead of a naked wife. (I was hoping that 
would tip something, actually) but that "fireplace" object has to stay 
for the crash. (I was able to eliminate 2 other image_maps, but this one 
stays.)

http://www.buckosoft.com/tteoac/video/ttcrash.bz2
(It's not a video, I just had to put it somewhere...)
I've reduced it to 47K and just a handful of files.
I hope this is somewhat useful. Any more reducing gets to be painful.

$ tar -xvjf ttcrash.bz2
$ cd ttcrash/tteo
$ povray tteo.ini
boom.

The main file is tteo.pov.
If you look at the bottom of that file, there are 5 included objects.
If you comment out any one of those, it doesn't crash.
It doesn't crash at all on Windows. It crashes 100% on my Ubuntu 14 and 
Ubuntu 16 boxes.

My art does nothing fancy. There is the image_map but other than that, 
it's all sliced and diced spheres, boxes, cones, cylinders, and torii; 
basically povray 3.1g compatible.

-- 
dik

Post a reply to this message

On 02/13/2017 05:35 AM, dick balaska wrote:
> Am 2017-02-12 10:09, also sprach clipka:
>
>> Providing me with a minimal test scene for further analysis is certainly
>> a good idea. (By all means try to replace that picture with something
>> less private though ;)
>>
>
> You get a povray'd arrow instead of a naked wife. (I was hoping that
> would tip something, actually) but that "fireplace" object has to stay
> for the crash. (I was able to eliminate 2 other image_maps, but this one
> stays.)
>
> http://www.buckosoft.com/tteoac/video/ttcrash.bz2
> (It's not a video, I just had to put it somewhere...)
> I've reduced it to 47K and just a handful of files.
> I hope this is somewhat useful. Any more reducing gets to be painful.
>
> $ tar -xvjf ttcrash.bz2
> $ cd ttcrash/tteo
> $ povray tteo.ini
> boom.
>
> The main file is tteo.pov.
> If you look at the bottom of that file, there are 5 included objects.
> If you comment out any one of those, it doesn't crash.
> It doesn't crash at all on Windows. It crashes 100% on my Ubuntu 14 and
> Ubuntu 16 boxes.
>
> My art does nothing fancy. There is the image_map but other than that,
> it's all sliced and diced spheres, boxes, cones, cylinders, and torii;
> basically povray 3.1g compatible.
>

FYI.

Took an initial look and at, at least for the Ubuntu gnu debug compiles 
I have handy and current, I do not get the seg fault where the 
equivalent normal compile fails... Maybe an optimization tangled issue?

I had a few existing normally compiled binaries handy from previous 
specific commits. The last that worked for me was commit 7d06e7f, Fri 
Sep 9 09:50:47 2016 +0200. The first that failed was commit c6a6e98, Dec 
20 13:55:46 2016 +0100.

I'll have to step out for a while, but I'll plan to pick this up later 
this morning after checking in here.

Bill P.

Post a reply to this message