Re: problems debugging
Re: problems debugging
- Subject: Re: problems debugging
- From: Mike Halpin <email@hidden>
- Date: Tue, 6 Dec 2005 16:50:14 -0800
Title: Re: problems debugging
Jim,
included the normal and the additional log in Bug
ID# 4367963.
Though I'll be happy if this eventually leads to a better
product, I'd be extremely appreciative in the meantime if any insight
which might allow me to avoid this error and continue with my work is
communicated. The fact that it did kind of work originally, may
indicate that there is a way to restore things to that state short of
a software update.
Thanks, Mike H.
At 12:54 PM -0800 12/6/05, Jim Ingham wrote:
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 debuggerS
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]
RunningS
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
--
------------------------------------------------------------------
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