views:

15

answers:

1

I am developing a unix console application on OS X. I just updated three statically linked libraries (hdf5 and its dependents szip and z). After a rebuild all, the application exits code 1 immediately after launch. I'm unaware of how to explore the problem further in gdb because nothing is on the stack by the time the app exits. I did confirm using otool -hv that all libraries are built for X86_64 architecture.

I can, and have, gotten my app working again by reverting to the previous library binaries, but I'd like to know more about what is going on during the earliest stage of the application run that is causing it to exit.

GDB results below:

gdb ./build-deb/xapp/xapp 
GNU gdb 6.3.50-20050815 (Apple version gdb-1472) (Wed Jul 21 10:53:12 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ..... done

(gdb) run
Starting program: /researchSoftware/app_git/src/build-deb/xapp/xapp 
Reading symbols for shared libraries .++++............................................................. done

Program exited with code 01.
(gdb) backtrace
No stack.
A: 

It looks like some code called exit(1) or return 1 so I would start by putting a breakpoint at the start of main and stepping until the exit handler gets called, or break in the exit handler.

abdollar
I don't understand why backtrace reported No stack. But in fact, this was not a library issue. It was a user error. My code was getting to an early place where it should legitimately call exit(1) base on my input arguments.
NoahR