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: Stackdump trace - problem and patch

Christopher Faylor wrote:
On Sat, Jan 01, 2005 at 03:54:23AM -0500, Jon A. Lambert wrote:
my application.  I tried various means of examining and setting the
registers in the stack to get to a frame that was within my app.  I
have read the various messages on the list describing how to get to
those frames.  It's rather tricky, and it availed me not.  Probably
a personal problem. ;-)

Probably. And, for that reason we're not going to be adding another cygwin option. There is little reason to provide workarounds like this when the real fix would be either to fix the user or the application.

Ah the user was looking to fix the application. The difficulty I was running into is identical to the scenario Robert Baruch posted here:

He was more concerned at getting the backtrace readable. I'm more concerned with fixing my application fast. If you look at his posted stackdump though you'll see it's definitely in userland, readable and more than enough information to solve the problem. That is easily pinpoint the problem had it been a real application.

I used his solution here:

His solution does work. My problem is that when your application isn't a trivial test but farly large, you have to chase the $ebp up the stack not just twice like he did but dozens of times. Or scan through it until you see something in your space. Of course I noticed my stackdump trace, like his too, looked just fine. The only problem was half the trace entries were in cygwinland and only eight were in userland, unfortunately in well tested and layered utility routines. I needed only two more trace entries to pinpoint my problem.

In particular, if dumper isn't providing a valid core dump, then it
should certainly be fixed.

Thanks for the effort provided in coming up with a patch, though,

That's okay. I thought I'd get fancy and provide some user configuration options. In any case 16 trace entries ain't enough for me, well because my application is a compiler/vm.

Even this would be more than helpful.
-  for (i = 0; i < 16 && thestack++; i++)
+  for (i = 0; i < 32 && thestack++; i++)

Anyway if not, I can always patch it there in everytime I upgrade.

Unsubscribe info:
Problem reports:

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