This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

-ethan

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- thompson.com/stuff/gdb-answer.html )

Attachment: test.c
Description: Binary data



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]