Moved from Blender 2.6 Bug Tracker to Game Engine

Brecht I suspect this may not be a BGE only bug. Moving back to Blender because the first error I get is while opening the file.
If the bge bug itself persist we then move it to the GE tracker.

* * *

I tried here (OSX) and in an old build I reproduced the error.
In a more recent build (with debug on) everything was fine.
And with the latest latest trunk, a new error came up while opening the file:

blender(25019,0x7fff738d0180) malloc: *** error for object 0x7ffd80aa55e0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

I don't have time to debug this now, but it should be easy to find the error(s) with git bissect.

Moved from Game Engine to Blender 2.6 Bug Tracker

strange, the crash when opening the file only happens in Release mode.
@axredneck can you try a build from builder.blender.org to see if the bge part of the problem is still there?

fixed r57815.

i'm sorry i uploaded a blend which triggers 2 various bugs... Trying Blender from BuildBot...

Jens just confirmed that this file crashes his computer too (when opening it, not even need to play the file for the segfault) - he tested only with a Release build

Blender r57816, no segfault ! Thanks all !

reopening, the OSX bug was introduced in: 55847 + 55848 (freestyle merge)
assigning to Jens

(we could open a new bug entry for that as well, but well ...)

Hi
I'am down to th finding the bug is an doublefree, but could not pin down the line yet.

From the attached blend while trying to load:

blender(18985,0x11a5cf000) malloc: *** error for object 0x11ad002f0: double free
...
* thread #30: tid = 0x4d03, 0x00007fff96b9d212 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
frame #0: 0x00007fff96b9d212 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007fff8f8fab54 libsystem_c.dylib`pthread_kill + 90
frame #2: 0x00007fff8f93edce libsystem_c.dylib`abort + 143
frame #3: 0x00007fff8f91a905 libsystem_c.dylib`szone_error + 580
frame #4: 0x00007fff8f9128f8 libsystem_c.dylib`free + 199
frame #5: 0x000000010268476b blender`ft_free + 25
frame #6: 0x0000000102691924 blender`ft_mem_free + 41
frame #7: 0x0000000102686a2a blender`ft_glyphslot_free_bitmap + 91
frame #8: 0x0000000102686b4a blender`ft_glyphslot_clear + 21
frame #9: 0x00000001026872c7 blender`FT_Load_Glyph + 97
frame #10: 0x0000000101991c71 blender`blf_glyph_add(font=0x000000010c695bb8, index=0, c=0) + 225 at blf_glyph.c:233
....

More investigation needed... Jens

Preview render and the UI are accessing font stuff from different threads here, which likely causes the problem? I'm not sure why that should suddenly be a problem now.

> Blender r57816, no segfault ! Thanks all !
In addition: bug related to uniforms and shaders seems fixed, segfaults when OPENING the blend are not related to uniforms, so the bug must be renamed. How can it be done?

Renamed the report now.

This does not seem to be related to the freestyle commits, it happens before them too. The problem is that the "color grid" image with text used in a preview render, and the UI code are trying to initialize font drawing data structures at the same time.

Could there be more info on how to redo this crash? - open the file and nothing happens here. how is the error caused?

@Campbell: on OSX by simply opening the file you get a bus lock (hanging forever) or a segfault.

@ax: how did you create this file? Anything in particular? anything imported?

Found a solution for opening attached file if this brings us something:

Before loading the file, goto prefs and disable "load gui", then you can bring the blend up.
Having preview colsed or open makes no difference !

Jens

@Dalai
I created blends which render fractals in realtime using BGE. I used the texture (with "A1" caption) as render target and also to generate texcoords. Now i replaced it with grid and (seems) it doesn't crash Blender under Xubuntu linux.

This is an odd issue.
I took the attached blend and just regenerated the colorgrid and now the crash on loading is gone !!!!
Wtf ... could this be due blender versioning clutter ?

@ ax 34noff, can you pls check my new attached blend is exactly same as yours before ( in result ) ?

Jens

If you enable textured draw mode in the viewport it will crash again with setuniform_regenerated_tex.blend.

This is a thread conflict and so subtle timing difference can avoid the crash. I can get it to crash on Windows too with the patch attached, which increases the probability that there will be some thread conflict, probably it will crash on Linux too.

We may need to add some mutex locks to blenfont, Freetype is reentrant but not thread safe and probably multiple threads are modifying the same data.

Fix in svn now, using a spin lock in the glyph add function.