This is the mail archive of the
mailing list for the Cygwin project.
Re: gdb attach to process to produce stacktrace
Wait, wait, don't give up so quickly -- this is the same problem I
reported a while back as well, and I'd like to see a better
resolution than "doctor, it hurts when I move my arm"; "well then
don't move your arm!" ...some of us actually need to use our arms.
Maybe you can get around using sleep() this time, but you can't avoid
ever using system calls...
I see two problems when attaching to a process, or breaking (ctl-C)
one already loaded and running:
(1) All of the function calls on the stack prior to a "context"
switch (call from cygwin code to windows code, and also possibly from
user code to cygwin1.dll code) show up as '??', even though symbols
are available. This makes the stack trace useless because we don't
know where the user code is at when it made the call, can't use 'up'
and examine locals or arguments at the point of the call, etc...
(2) Can't step out of the Windows code back into the user code.
You're right, we don't really care what windows is doing, and so we'd
be happy to break out of it and get back to user code. But stepping
beyond the beginning of the "context switch" just continues
execution, and doesn't let us return to the calling function.
With both (1) and (2) in place, it's very difficult to debug a
program if we don't already know where the problem is, *particularly*
if it's blocking/crashing on an irreplaceable system call. What made
the system call? What arguments were in play? No way to know!
The only work around it seems is that if you can *guess* where the
execution is at, and set a breakpoint in your code after where the
function is to return, *and if your execution isn't already hosed by
this point*, gdb will stop at the breakpoint and then show you the
stack of your code, with all the current variable values and such
that make a debugger a debugger.
Personally, I don't consider cross-development under cygwin feasible
without a working debugger. So is there a workaround to these issues
besides replacing all the system calls? (In other words, not running
Windows...) Because if not, there's no point in me trying to support
our robot simulator under cygwin because users won't be able to debug
their code, which is the whole point of the simulator.
For a quick example, try figuring out why this example program is
crashing... The idea is simple: set up an array of strings containing
'a' through 'z', build a string from 100 random selections, and then
display the result.
No fair figuring it out from looking at the code (it's a suitably
subtle newbie type problem, though obfuscated enough it's not
glaringly obvious) -- pretend it's a "real" problem in a piece of
fairly complicated code that isn't just a dozen lines long, try using
gdb to figure it out. (for the lazy/hurried, answer posted here,
including comparison to what happens in cygwin: http://ethan.tira-
Description: Binary data
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html