[Bf-committers] Pretty clueless Linux threads crashing...

[Ton Roosendaal]

Hi,

I suspected scanline updating from crashing... it was reported to crash  
less frequent then, but that's not the solution. Apparently I've put a  
little bit too much efforts to limit code for update scanlines! So yes,  
it skips the 2nd thread tile drawing. Will be brought back.

We did tests a couple of days on irc with this .blend:
http://www.blender.org/bf/untitled-1.blend

Not sure if it still crashes, it seems to only happen every 10 frames  
or so. So just press ANIM on it.

-Ton-


On 23 Feb, 2006, at 19:58, Chris Want wrote:

>
> Hi Ton,
>
> I haven't been able to replicate your crashes here -- do
> you have a blend file that is known to be volatile?
>
> One thing I have noticed is that the render window only
> seems to update the scanlines of one tile now (it used
> to update two tiles) -- is that a bug, or a feature?
>
> Regards,
> Chris
>
> Ton Roosendaal wrote:
>> Hi all,
>> I need help locating what goes wrong in using thread render on Linux.  
>>  I'm using SDL for threads, and it appears that in Linux threads  
>> refuse  to close (well, gdb reports lotsof zombies to end), and after  
>> a while  (unpredictable, but on some scenes every render) it ends  
>> with this:
>> #0  0xb781bcda in sem_post at GLIBC_2.0 () from   
>> /lib/tls/i686/cmov/libpthread.so.0
>> (gdb) bt
>> #0  0xb781bcda in sem_post at GLIBC_2.0 () from   
>> /lib/tls/i686/cmov/libpthread.so.0
>> #1  0xb7ba2748 in SDL_SemPost () from /usr/lib/libSDL-1.2.so.0
>> #2  0xb7ba1efb in SDL_RunThread () from /usr/lib/libSDL-1.2.so.0
>> #3  0xb7ba21d1 in SDL_KillThread () from /usr/lib/libSDL-1.2.so.0
>> #4  0xb7817361 in start_thread () from   
>> /lib/tls/i686/cmov/libpthread.so.0
>> #5  0xb7912bde in clone () from /lib/tls/i686/cmov/libc.so.6
>> Note; I am using SDL_KillThread() now instead of the official   
>> SDL_WaitThread(), because that seems to be more *stable*... using   
>> SDL_WaitThread() gives same crashes.
>> I also have no idea what this bt means... why would the KillThread  
>> call  a RunThread and then hang in sem_post()???
>> Some clues;
>> - it seems to happen more often when OpenGL is busy too. Like with  
>> huge  windows it crashes more often. I do know that within a thread  
>> you  should not use X11 or opengl, using windows/events/opengl calls  
>> in  threads won't work on OSX either. Nevertheless, we did try  
>> Brecht's  hint, to add XInitThreads() in GHOST_SystemX11.cpp, before  
>> line 107.  Didn't really give improvements.
>> - when rendering without threads button pressed, rendering goes OK.  
>> The  render code then still uses a single SDL thread for the tile  
>> render  though.
>> - On different Linux installs we get different reports. Some report   
>> crashes all the time, some claim its running fine.
>> - In OSX threads never crash this way, nor do we get zombie threads.   
>> OSX does have a quite rare opengl crash though, which also only seems  
>>  to happen while using huge windows.
>> - I've very carefully checked all code to see if there's any   
>> opengl/event call during a thread, but couldn't find one. Still might  
>>  be there though... maybe I'm just missing some.
>> - I'm not using semaphores code, but do have Mutex to protect the   
>> MEM_malloc calls.
>> The way I am using SDL threads for rendering:
>> - the main loop (not a thread) is in render module, pipeline.c,   
>> threaded_tile_processor()
>> - this loop goes to sleep when all 'thread slots' are filled.
>> - 20 times per second it wakes up, and either draws a scanline part   
>> update, or the entire tile
>> - if a thread is finished, it sets a flag in the RenderPart struct to  
>>  indicate that, then the mainloop makes sure a SDL_WaitThread is  
>> called  (SDL_KillThread now)
>> I moved all threading code to blenlib/intern/threads.c. In the c file  
>>  you can see docs for usage of the functions. Here also the mutexes  
>> are  set and used for mallocs.
>> Hopefully someone reads this with SDL coding experience! :)
>> -Ton-
>> ---------------------------------------------------------------------- 
>> -- --
>> Ton Roosendaal  Blender Foundation ton at blender.org   
>> http://www.blender.org
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at projects.blender.org
>> http://projects.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org