Getting load address for atos desymbolification from backtrace

Hi everyone,

Currently I am using getStackBacktrace to generate crash logs and upload them to an FTP. I have built a script using python that pulls these logs, parses them, and preps the hex addresses in a list (in order that SystemStats::getStackBacktrace produces them mind you) to be run against atos ( to get back a stack of symbols. I've managed to get symbols coming back, so I know I'm using the command correctly.


atos -o -arch x86_64 -l 0x00000001003484c0 0x000000010039834d 0x0000000100348634 0x00007fff932a6f1a

Comes from the first few lines of the crash log:

0   <APPNAME>                 0x000000010d99a4c0 _ZN4juce11SystemStats17getStackBacktraceEv + 64
1   <APPNAME>                  0x000000010d9ea34d _ZL22myCrashHandlerFunctionv + 2584
2   <APPNAME>                  0x000000010d99a634 _ZN4juceL11handleCrashEi + 10
3   libsystem_platform.dylib            0x00007fff932a6f1a _sigtramp + 26
4   ???                                 0x00007fff523c2578 0x0 + 140734573061496

I know the first hex address is supposed to be coming back something like:

juce::SystemStats::getStackBacktrace() (in APPNAME) (juce_SystemStats.cpp:139) 

The problem is, I'm getting symbols off the bat, and the symbols coming back aren't where the crash was triggered in my tests, and so to me the most likely culprit is that the first address provided from getStackBacktrace isn't the proper address offset (load address, as atos puts it). 

So my question is, considering this is a crash dump that is intentedly coming from computers I won't be able to access, how can I get the load address to provide proper offset? Is this something I can get juce to provide in the crash dump (i.e. SystemStats values) or perhaps extract somewhere in the backtrace itself?

Or am I completely off?

If this isn't enough information or description I'd be happy to provide more.