![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Hello
I've written a program called ArtRays that generates povray source files using
randomness. ArtRays generates the source file and then it execs povray (version
3.7.0) to render the image to a file and then ArtRays displays the file using
SDL.
I'm doing this on a Raspberry Pi2 with four cores and it is amazing fast.
Unfortunately ArtRays runs for a while and then povray crashes with the
following error:
povray: /usr/include/boost/thread/pthread/recursive_mutex.hpp:101: void
boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.
Anyone seen this before and maybe know of a fix?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 18.03.2015 um 02:48 schrieb Craig Lindley:
> I'm doing this on a Raspberry Pi2 with four cores and it is amazing fast.
> Unfortunately ArtRays runs for a while and then povray crashes with the
> following error:
>
> povray: /usr/include/boost/thread/pthread/recursive_mutex.hpp:101: void
> boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.
>
> Anyone seen this before and maybe know of a fix?
That does /not/ sound good at all.
It indicates that for some reason the boost threads library doesn't work
properly.
There is no way this can be fixed in POV-Ray itself (short of using a
different multithreading library, which would be a major undertaking),
and the only thing you as a user can do about it (short of reporting the
problem to the boost developers and waiting for a fix) is minimizing the
probability that thread synchronization issues arise.
The most thread synchronization heavy component of POV-Ray is the
radiosity sample cache. If you're using radiosity and don't want to do
without, you might want to try UberPOV and its no_cache feature.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka <ano### [at] anonymous org> wrote:
> Am 18.03.2015 um 02:48 schrieb Craig Lindley:
>
> > I'm doing this on a Raspberry Pi2 with four cores and it is amazing fast.
> > Unfortunately ArtRays runs for a while and then povray crashes with the
> > following error:
> >
> > povray: /usr/include/boost/thread/pthread/recursive_mutex.hpp:101: void
> > boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.
> >
> > Anyone seen this before and maybe know of a fix?
>
> That does /not/ sound good at all.
>
> It indicates that for some reason the boost threads library doesn't work
> properly.
>
> There is no way this can be fixed in POV-Ray itself (short of using a
> different multithreading library, which would be a major undertaking),
> and the only thing you as a user can do about it (short of reporting the
> problem to the boost developers and waiting for a fix) is minimizing the
> probability that thread synchronization issues arise.
>
> The most thread synchronization heavy component of POV-Ray is the
> radiosity sample cache. If you're using radiosity and don't want to do
> without, you might want to try UberPOV and its no_cache feature.
I am not using radiosity at all in ArtRays.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Craig Lindley" <cal### [at] gmail com> wrote:
> clipka <ano### [at] anonymous org> wrote:
> > Am 18.03.2015 um 02:48 schrieb Craig Lindley:
> >
> > > I'm doing this on a Raspberry Pi2 with four cores and it is amazing fast.
> > > Unfortunately ArtRays runs for a while and then povray crashes with the
> > > following error:
> > >
> > > povray: /usr/include/boost/thread/pthread/recursive_mutex.hpp:101: void
> > > boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.
> > >
> > > Anyone seen this before and maybe know of a fix?
> >
> > That does /not/ sound good at all.
> >
> > It indicates that for some reason the boost threads library doesn't work
> > properly.
> >
> > There is no way this can be fixed in POV-Ray itself (short of using a
> > different multithreading library, which would be a major undertaking),
> > and the only thing you as a user can do about it (short of reporting the
> > problem to the boost developers and waiting for a fix) is minimizing the
> > probability that thread synchronization issues arise.
> >
> > The most thread synchronization heavy component of POV-Ray is the
> > radiosity sample cache. If you're using radiosity and don't want to do
> > without, you might want to try UberPOV and its no_cache feature.
>
> I am not using radiosity at all in ArtRays.
I've updated the boost library to 1.50 and I'll see if that fixes things.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Craig Lindley" <cal### [at] gmail com> wrote:
> "Craig Lindley" <cal### [at] gmail com> wrote:
> > clipka <ano### [at] anonymous org> wrote:
> > > Am 18.03.2015 um 02:48 schrieb Craig Lindley:
> > >
> > > > I'm doing this on a Raspberry Pi2 with four cores and it is amazing fast.
> > > > Unfortunately ArtRays runs for a while and then povray crashes with the
> > > > following error:
> > > >
> > > > povray: /usr/include/boost/thread/pthread/recursive_mutex.hpp:101: void
> > > > boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.
> > > >
> > > > Anyone seen this before and maybe know of a fix?
> > >
> > > That does /not/ sound good at all.
> > >
> > > It indicates that for some reason the boost threads library doesn't work
> > > properly.
> > >
> > > There is no way this can be fixed in POV-Ray itself (short of using a
> > > different multithreading library, which would be a major undertaking),
> > > and the only thing you as a user can do about it (short of reporting the
> > > problem to the boost developers and waiting for a fix) is minimizing the
> > > probability that thread synchronization issues arise.
> > >
> > > The most thread synchronization heavy component of POV-Ray is the
> > > radiosity sample cache. If you're using radiosity and don't want to do
> > > without, you might want to try UberPOV and its no_cache feature.
> >
> > I am not using radiosity at all in ArtRays.
>
> I've updated the boost library to 1.50 and I'll see if that fixes things.
POVRay has now run for over two hours and has yet to crash. Version 1.46 of the
boost library might have been the issue.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 20.03.2015 um 03:45 schrieb Craig Lindley:
>> I've updated the boost library to 1.50 and I'll see if that fixes things.
>
> POVRay has now run for over two hours and has yet to crash. Version 1.46 of the
> boost library might have been the issue.
Probably so. Thanks a lot for trying this out and sharing!
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |