OS X : Stack Overflow on Startup

I have a large project (500+ Blueprints) and a pretty bad case of coupling (we were in circular dependency hell prior to 4.7). Given this situation I attempted to run to project on my MacBook (doing some vacation programming :slight_smile: But during initial map load (FEditorFileUtils::LoadDefaultMapAtStartup()) when all the package loads start rolling in the application crashes what seems to be due to the stack limit of 16M begin exceeded:

Exception Type:        EXC_BAD_ACCESS (SIGBUS)
Exception Codes:       KERN_PROTECTION_FAILURE at 0x0000000140bb5838
 
VM Regions Near 0x140bb5838:
    VM_ALLOCATE            000000013faf4000-0000000140af0000 [ 16.0M] rw-/rw- SM=SHM  
--> mapped file            0000000140af0000-0000000140bbc000 [  816K] r--/rwx SM=COW  /System/Library/Keyboard Layouts/AppleKeyboardLayouts.bundle/Contents/Resources/AppleKeyboardLayouts-L.dat

(I’m not hiding any uassets in my KeyboardLayout, promise! :] )


I tried to remedy this by upping the max stack size with setrlimit in FMacPlatformMisc::PlatformPreInit as a workaround but that had no effect.

Here is the entire OS X crash detail report (GitHub Gist)


The way I see it:

  1. I should fix our projects code/BP design so it’s not such a monster.
  2. It would be dandy if the package loading in UE wouldn’t recursively load dependent packages (if that’s whats happening), piling on to the stack. I don’t know how (if at all) feasible this is.

Thought you might want to know, let me know if I left anything out.

Cheers,
Tobias.

Hey Tobias,

Thanks for the report! I’ve assigned someone to look into this for you, and they’ll post here if they need any additional information.

Thanks Ben!

I made it into the editor by setting LoadLevelAtStartup=None in my config, thus avoiding loading anything. I still couldn’t open any of the high-coupling-assets to fix them until I tweaked the stack size in CocoaThread.cpp:458.

Here are some numbers: when loading the ABP for our main character I have a high-water mark of 24MB on the stack. I put some logging in LoadPackageInternal, it turns out 6 143 unique assets are loaded a total of 19 602 times. The skeleton is loaded 900 times, and foley footsteps also a couple of 100 times each. I’m guessing this is cached further down the line. I’m sure this is due to the circ deps dance, but it still seems an awful lot. So yeah, I guess I have to take the crowbar and get to work on these assets. :]

In addition to breaking the circular dependencies, you should look at using TAssetPtr<> properties that lazy load content. That will help your editor startup times.

Oh nice, I’ve only used them once when needed a cross-sublevel reference. Great, thanks. :slight_smile: