 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 2017-02-12 19:14, also sprach clipka:
> Why do you ask? ;)
Mostly I'm irked at myself. This is the third reference to unix/readme
in a week. You'd think I'd figure out what that meant by now...
---
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/13/2017 06:35 AM, William F Pokorny wrote:
>
> 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.
>
OK. The trigger for this segmentation fault seems to be commit: c52c176
"Implemented basic Wavefront OBJ import. (#90)" where we also made
changes to:
source/core/bounding/boundingbox.cpp
and
source/core/bounding/boundingbox.h
The specific trigger is a change in a find_axis() for loop where the
problem additions have been commented so things work:
for(i = first; i < last; i++)
{
bbox = &(Finite[i]->BBox);
if(bbox->lowerLeft[X] < mins[X])
mins[X] = bbox->lowerLeft[X];
if(bbox->lowerLeft[X] + bbox->size[X] > maxs[X])
maxs[X] = bbox->lowerLeft[X]; // + bbox->size[X]; // <--
if(bbox->lowerLeft[Y] < mins[Y])
mins[Y] = bbox->lowerLeft[Y];
if(bbox->lowerLeft[Y] + bbox->size[Y] > maxs[Y])
maxs[Y] = bbox->lowerLeft[Y]; // + bbox->size[Y]; // <--
if(bbox->lowerLeft[Z] < mins[Z])
mins[Z] = bbox->lowerLeft[Z];
if(bbox->lowerLeft[Z] + bbox->size[Z] > maxs[Z])
maxs[Z] = bbox->lowerLeft[Z]; // + bbox->size[Z]; // <--
}
I see no difference in results, but I do not know the bounding code well
enough to know if just backing the above additions from c52c176 is safe.
The secondary bit of this tangle is needing -O2 or -O3 compiles with
both the gnu compiler and clang to get the crash.
I found compiling everything normally with -03 then selectively
re-compiling the files in just the source/backend/scene with -O makes
the seg fault go away, but I am at a loss as to why.
The only code therein looking to be tangled with the bounding structure is:
view.cpp:bool View::CheckCameraHollowObject(const Vector3d& point, const
BBOX_TREE *node)
which is in fact the code Dick saw in his fails.
Lastly, I've not been able to get a debug compile of any form to fail
for me.
Where do we go from here with this one?
Regards, Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 2017-02-13 11:15, also sprach William F Pokorny:
>
> Lastly, I've not been able to get a debug compile of any form to fail
> for me.
Just --enable-debug does it for me. Without trying to disable -O3
--
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.02.2017 um 17:15 schrieb William F Pokorny:
> OK. The trigger for this segmentation fault seems to be commit: c52c176
> "Implemented basic Wavefront OBJ import. (#90)" where we also made
> changes to:
>
> source/core/bounding/boundingbox.cpp
>
> and
>
> source/core/bounding/boundingbox.h
>
> The specific trigger is a change in a find_axis() for loop where the
> problem additions have been commented so things work:
>
> for(i = first; i < last; i++)
> {
> bbox = &(Finite[i]->BBox);
>
> if(bbox->lowerLeft[X] < mins[X])
> mins[X] = bbox->lowerLeft[X];
>
> if(bbox->lowerLeft[X] + bbox->size[X] > maxs[X])
> maxs[X] = bbox->lowerLeft[X]; // + bbox->size[X]; // <--
>
> if(bbox->lowerLeft[Y] < mins[Y])
> mins[Y] = bbox->lowerLeft[Y];
>
> if(bbox->lowerLeft[Y] + bbox->size[Y] > maxs[Y])
> maxs[Y] = bbox->lowerLeft[Y]; // + bbox->size[Y]; // <--
>
> if(bbox->lowerLeft[Z] < mins[Z])
> mins[Z] = bbox->lowerLeft[Z];
>
> if(bbox->lowerLeft[Z] + bbox->size[Z] > maxs[Z])
> maxs[Z] = bbox->lowerLeft[Z]; // + bbox->size[Z]; // <--
> }
What exactly makes you think these changes have anything to do with the
segfault?
I very much suspect that instead of the changes causing the segfault,
the version prior to the commit just masked it somehow. One such
mechanism could be via simply shifting around code so that it reacts
differently to a highly unstable situation. Another mechanism (and the
one I'd currently put my money on) would be via creating a different
bounding box hierarchy.
If you have a closer look at the original `find_axis()` code, you'll
notice that it is very difficult to make heads or tails of the function
if you presume the implementation to be correct -- especially the lines
in question seem rather puzzling. If on the other hand you discard the
idea that the function is bug-free, and presume that the loop's original
intention was simply to set `mins` and `maxs` to the "bottom-left" and
"top-right" corner, respectively, of a box encompassing all the bounding
boxes iterated over, then things suddenly fall into place perfectly: The
function as a whole is then intended to compute the axis along which
that all-encompassing box extends the most. This also fits nicely with
the calling code.
If you go along with that interpretation, then the changes done in
c52c176 are a no-brainer bugfix; and in examining the calling code, it
must be concluded that although the original code would not have created
any truly broken bounding box hierarchies (in the sense that other code
would have gagged on them), it would in semi-rare cases have created
/different/ bounding box hierarchies than intended (and created by the
new version).
> I see no difference in results, but I do not know the bounding code well
> enough to know if just backing the above additions from c52c176 is safe.
The broken code has been undetected ever since its first implementation
in POV-Ray 2.0, so it sure doesn't cause artifacts. It might have an
impact on performance though.
> The only code therein looking to be tangled with the bounding structure is:
>
> view.cpp:bool View::CheckCameraHollowObject(const Vector3d& point, const
> BBOX_TREE *node)
>
> which is in fact the code Dick saw in his fails.
Indeed.
One interpretation would be that there is some other bug in the bounding
mechanism that only surfaces in rare circumstances, which happen to be
met in Dick's scene, but which used to be masked by the old bug in
`find_axis()`.
However, one thing that's seriously odd about this issue is that the
reported crash does /not/ happen during an attempt to access the
bounding hierarchy, but in an attempt to access
`viedData.GetSceneData()` -- which should work (or fail to do so)
totally independent of the bounding hierarchy. This is more indicative
of a totally wild pointer happening to trash `viewData`, or more
specifically the `sceneData` shared pointer therein. In that case, wish
us good luck trying to nail down the culprit, 'cause we'll need lots of it.
> Lastly, I've not been able to get a debug compile of any form to fail
> for me.
>
> Where do we go from here with this one?
Good question. I haven't been able to trigger an error on Windows
either; neither with frame 4 (as suggested by the ini file provided by
Dick) nor with any frame from 1 to 153. And I don't think it makes much
sense to try the remaining 3000 frames of the animation.
One thing we might do is to go further back in the Git history, but use
the newer `find_axis()` code, in the hope that we might find the commit
that /really/ broke things.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 2017-02-13 14:03, also sprach clipka:
> Good question. I haven't been able to trigger an error on Windows
> either; neither with frame 4 (as suggested by the ini file provided by
> Dick) nor with any frame from 1 to 153. And I don't think it makes much
> sense to try the remaining 3000 frames of the animation.
frame 4 was just the first frame that included those objects. I may have
even ripped that logic out. You won't get much else out of that code.
I trimmed 175 source files down to 27 for this exercise.
I did strip the haus down to just the second floor (first floor!) and
foundation; it might be funny to see what that actually looks like. ;)
I see no value in other frames. The tree is likely to parse out the same
way for each frame.
I, too, have not been able to trigger an error on Windows.
--
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/13/2017 02:03 PM, clipka wrote:
>>
>> The specific trigger is a change in a find_axis() for loop where the
>> problem additions have been commented so things work:
>>
>> for(i = first; i < last; i++)
>> {
>> bbox = &(Finite[i]->BBox);
>>
>> if(bbox->lowerLeft[X] < mins[X])
>> mins[X] = bbox->lowerLeft[X];
>>
>> if(bbox->lowerLeft[X] + bbox->size[X] > maxs[X])
>> maxs[X] = bbox->lowerLeft[X]; // + bbox->size[X]; // <--
>>
>> if(bbox->lowerLeft[Y] < mins[Y])
>> mins[Y] = bbox->lowerLeft[Y];
>>
>> if(bbox->lowerLeft[Y] + bbox->size[Y] > maxs[Y])
>> maxs[Y] = bbox->lowerLeft[Y]; // + bbox->size[Y]; // <--
>>
>> if(bbox->lowerLeft[Z] < mins[Z])
>> mins[Z] = bbox->lowerLeft[Z];
>>
>> if(bbox->lowerLeft[Z] + bbox->size[Z] > maxs[Z])
>> maxs[Z] = bbox->lowerLeft[Z]; // + bbox->size[Z]; // <--
>> }
>
> What exactly makes you think these changes have anything to do with the
> segfault?
>
:-) Nothing except running the code as above makes the seg fault go
away. It doesn't make sense to me either.
>
> Good question. I haven't been able to trigger an error on Windows
> either; neither with frame 4 (as suggested by the ini file provided by
> Dick) nor with any frame from 1 to 153. And I don't think it makes much
> sense to try the remaining 3000 frames of the animation.
>
> One thing we might do is to go further back in the Git history, but use
> the newer `find_axis()` code, in the hope that we might find the commit
> that /really/ broke things.
>
A good suggestion - thanks.
Let me try again to get some kind of debug version which seg faults -
otherwise...
(Saw your comment Dick & thought I tried -O3 with debug symbols, but was
running lots of various compiles this morning so maybe I slipped up.)
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/13/2017 04:40 PM, William F Pokorny wrote:
>
> A good suggestion - thanks.
>
> Let me try again to get some kind of debug version which seg faults -
> otherwise...
>
> (Saw your comment Dick & thought I tried -O3 with debug symbols, but was
> running lots of various compiles this morning so maybe I slipped up.)
>
> Bill P.
After chasing a good many ghosts, this turns out to be another thread
stack size issue. A stack overrun was causing the various strange results.
Posted a fix at: https://github.com/POV-Ray/povray/pull/235 against the
3.7.1 release branch.
Note the AppVeyor build checks for the pull req are failing due a VS2015
license expiring - ignore the red 'x'.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
