Re: problems debugging
Re: problems debugging
- Subject: Re: problems debugging
- From: Jim Ingham <email@hidden>
- Date: Tue, 6 Dec 2005 12:54:20 -0800
There should be a CrashReporter Log with the gdb crash trace in it.
Look in
~/Library/Logs/CrashReporter/gdb-powerpc-apple-darwin.crash.log
Note that all the crashes get logged in here, so there may be more
than one. If there is one with the right dates for this crash please
file a bug and include that crash log.
Also if you are running from Xcode it would help if you could include
an Xcode-GDB session transcript for the session that's crashing. To
do that, do:
1) Quit Xcode.
2) In Terminal, say:
$ defaults write com.apple.Xcode PBXGDBDebuggerLogToFile YES
$ defaults write com.apple.Xcode PBXGDBDebuggerLogFileName /tmp/
IncludeInBug.log
3) Restart Xcode, and do whatever you need to to make it fail.
4) Attach /tmp/IncludeInBug.log to the Radar.
Include that in the bug as well.
OTOH, if you are running from the Terminal, please include a complete
gdb session leading up to the crash. Don't try to cut it down to the
"relevant portion" or we might miss some clue that you wouldn't think
was important...
Thanks,
Jim
On Dec 5, 2005, at 11:47 PM, Mike Halpin wrote:
I have a working executable which is a command line tool to test and
debug the libraries which implement the core functionality of several
of our products. It runs most of our test suite, and now I'm into
fixing bugs in our code, as the port from Code Warrior seems to be
substantially viable.
The first time I tried to debug I was able to set and fire off break
points, but I found that stepping in or out of some functions caused
the entire program to exit.
However, I could set break points, and 'continue' to them. About the
umpteenth time through iteratively setting break points earlier and
earlier in the code execution sequence to find the source of the bug,
I got, and continue to get, no matter what I've tried:
The Debugger has exited due to signal 11 (SIGSEGV)
Here is the complete output from a recent session. I've labeled some
of the lines with (1), (2) for discussion purposes. These labels
were not emitted by the debugger or by my code.:
[Session started at 2005-12-05 16:33:56 -0800.]
GNU gdb 6.1-20040303 (Apple version gdb-413) (Wed May 18 10:17:02
GMT 2005)
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 "powerpc-apple-darwin".
Loading program into debuggerŠ
tty /dev/ttyp2
Program loaded.
(1)expand
/Volumes/Internal/Development/Modules/engine7/test/workingarchives/
sit/bib-00-rayx.sit
--password=password
--destination=/Volumes/Internal/Development/Modules/engine7/test/
results/
--clean
Unable to set breakpoint (null). Make sure to build the file (null)
with debugging symbols.
(2)/Volumes/Internal/Development/Modules/engine7/test/
workingarchives/sit/bib-00-rayx.sit
--password=password
--destination=/Volumes/Internal/Development/Modules/engine7/test/
results/
--clean
Catchpoint 10 (throw)(gdb) run
Catchpoint 11 (catch)[Switching to process 3376 local thread 0xf03]
RunningŠ
Catchpoint 12 (throw)Catchpoint 13 (catch)Pending breakpoint 9 -
""mime.classifier.cpp:37" resolved
Pending breakpoint 1 - ""sit.Archive.cpp:54" resolved
Pending breakpoint 2 - ""sit.Archive.cpp:53" resolved
Pending breakpoint 3 - ""sit.Archive.cpp:56" resolved
Pending breakpoint 4 - ""rsrc.map.cpp:27" resolved
Pending breakpoint 5 - ""sit.Archive.cpp:59" resolved
Pending breakpoint 6 - ""sit.archive_key.cpp:26" resolved
Pending breakpoint 7 - ""sit.archive_key.cpp:25" resolved
Pending breakpoint 8 - ""sit.archive_key.cpp:32" resolved
(3)expanding:
/Volumes/Internal/Development/Modules/engine7/test/bugs/4386/
zeegif.mme
The Debugger has exited due to signal 11 (SIGSEGV).The Debugger has
exited due to signal 11 (SIGSEGV).
(gdb)
****
The arguments listed at (1) and (2) , were the arguments I had used
in a previous session, but I have changed them in the executable
environment to reference another file. but...
The output at (3), which is from my own code (std::cout <<
"expanding: " << path << std::endl; or code to that effect, where
'path' is taken from argv), indicates that in fact, the current
arguments are being passed in. The listed path is the correct input
argument.
I could live with that anomaly, if It would just stop at a break
point an let me debug my code. I could go back and debug a
codwarrior build with ease, would probably figure out this particular
bug in about 10 minutes. However, long term, now that I have to use
xcode for our release products, that is not an acceptable debugging
strategy.
I have to figure out what's bugging the debugger, and hope someone on
this list will be able to help.
Thanks,
--
------------------------------------------------------------------
Mike Halpin,
In the beginner's mind there are many possibilities. In the
expert's, there are few.
-- Shunryu Suzuki Roshi
------------------------------------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden