OS X : Stack Overflow on Startup

Development Platform & Builds
, , ,
1

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 package loads start rolling in application crashes what seems to be due to 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 max stack size with setrlimit in FMacPlatformMisc::PlatformPreInit as a workaround but that had no effect.

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

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 package loading in UE wouldn’t recursively load dependent packages (if that’s whats happening), piling on to 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,
.

2

Hey ,

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

3

Thanks !

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

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

4

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

5

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