App runs in Xcode but always crashes on launch when run as standalone

Application runs in the IDE (Xcode) but when I double click the standalone it ALWAYS crashes on launch. This is part of my crash log. I assume this has something to do with additional debug code I have added.

Process: ofAppDebug [4284]
Path: /Users/USER/Documents/*/ofAppDebug.app/Contents/MacOS/ofAppDebug
Identifier: cc.openFrameworks.ofapp
Version: 1.0
Code Type: X86 (Native)
Parent Process: ??? [1]
Responsible: ofAppDebug [4284]
User ID: 502

Date/Time: 2015-11-11 10:49:55.857 -0500
OS Version: Mac OS X 10.11.1 (15B42)
Report Version: 11
Anonymous UUID:

Time Awake Since Boot: 5400 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000fffffff4
Exception Note: EXC_CORPSE_NOTIFY

if you have an app responding differently depending on debug / release, etc, I usually look for uninitialized variables / memory issues, which can be different when you run the app in different contexts.

Thanks zach. No debug vs release versions is not the issue. Both crash when launched standalone but work (compile and run) when in the IDE.
Trying to figure out what is different when you run in the IDE vs launching standalone.

hmmm… you can always use lldb at the command line to debug the crash – I usually do:

lldb pathToExe ( it’s usually appName.app/Contents/MacOS/appName)

then

process launch

to run the app…

(also running the app from the command line via the full path to the exe can help (./appName.app/Contents/MacOS/appName)

On windows (not so much on mac) I’ve seen situations where running the app in the IDE can give different “current working directories” of where the app is thought to be located.

(also running the app from the command line via the full path to the exe can help (./appName.app/Contents/MacOS/appName)

what I mean is, you can see the console output and from that, sometimes see if you are hitting setup, udpate, draw, etc…

Thanks. Backtracking to an earlier saved version was able to at least find the source of the crash. Had to do with the way I am using ofLogToFile in conjunction with ofxWatchdog.

I was running a 2nd ofLogToFile method inside of ofxWatchdog::initialize.

Apparently not a good idea but when I run ofLogToFile to create an external log ONLY in ofApp::setup I am not seeing my ofLog calls from within ofxWatchdog.

Any chance you have experience running ofxWatchdog with external logs?