Page MenuHome

Remesh crash - consistent, repeatable
Closed, ResolvedPublic


OS X 10.5.8 / Powerbook G4 2GB 1.67GHz / Mobility Radeon 9700

With my own compiles since Remesh was added, application of the Remesh modifier to any mesh has consistently and repeatably crashed in all cases on the above platform, I also see this behaviour with the official 262rc1 from

On an Intel MacBook Pro Remesh works as expected.

Process to repeat:

(1) Open new scene
(2) Apply Remesh modifier to default cube

On the Powerbook, the add modifier pop up menu is not dismissed after remesh is selected, and the application displays the spinning beachball for a minute or so, then exits with Crash Reporter displaying the attached information.

Event Timeline

Could you generate a backtrace using gdb? Without access to a Powerbook I am unable to reproduce this issue.

No problems, I'll post one shortly.

Given that this happens on powerpc, it's almost certainly an endianness issue. In octree.h there seem to be quite a few suspicious casts from UCHAR* to USHORT* and int*.

I seem to be having an issue compiling with BF_DEBUG = True at the moment for some reason; I'll go to IRC for some advice, so I can get a useful backtrace posted for you shortly.

Compiling ==> 'itasc_plugin.cpp'
{standard input}:unknown:Undefined local symbol LC50
{standard input}:unknown:Undefined local symbol LC51
{standard input}:unknown:Undefined local symbol LC52
scons: *** [/Users/user/compile/build/darwin/source/blender/ikplugin/intern/itasc_plugin.o] Error 1
scons: building terminated because of errors.
users-powerbook-g4-17:blender user$

Thanks Campbell for your advice on IRC.

Using cmake, make debug lite and with WITH_MOD_REMESH set to ON, I'm still having a few issues getting this debug build for the backtrace.

[ 14%] Building C object source/blender/editors/space_file/CMakeFiles/bf_editor_space_file.dir/fsmenu.c.o
In file included from /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:38,
from /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:20,
from /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20,
from /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21,
from /Users/user/compile/blender/source/blender/editors/space_file/fsmenu.c:58:
/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:29:2: error: #error Both __BIG_ENDIAN__ and __LITTLE_ENDIAN__ cannot be true
make[3]: *** [source/blender/editors/space_file/CMakeFiles/bf_editor_space_file.dir/fsmenu.c.o] Error 1
make[2]: *** [source/blender/editors/space_file/CMakeFiles/bf_editor_space_file.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [all] Error 2
users-powerbook-g4-17:blender user$

I'll get it working in the end; might take a day or two to work through the issues though.

The only other information I have for the moment is that when running the non-debug binary through gdb, the crash is reported immediately upon selecting Remesh.

The pause-before-exit and spinning beachball in the first post I believe comes from Apple's Crash Reporter sorting itself out. This seems to be borne out as using "top": Blender is shown as taking zero cpu time in the period between selecting Remesh and the time it eventually quits - during this period Crash Reporter is clearly quite busy.

gdb backtrace attached, after some fumbling around in the dark!

Thanks for the backtraces.

Brecht, as you note there's a lot of suspicious stuff going on internally, I'll see about rewriting this with a bit more safety and stronger types.

I've committed a first pass at making the remesh octree use better typing. I'm not sure if this will help with the crash or not, as there's still a fair amount of low-level bitwise operations going on. Alan, could you test a build from revision 44223 or later and see if there's any change?

Thank you very much; that worked perfectly with 44224.

I've tested it using a range of meshes from small and trivial through to complex and disconnected, and all seems to be nice and stable now.

Nicholas Bishop (nicholasbishop) changed the task status from Unknown Status to Resolved.Feb 18 2012, 4:07 PM