Dumping core on windows?

Dumping core on windows?

[Ben Greear]

Is there any way to configure windows to dump a core file
that GDB can decode?  (Or, get a stack-trace some other way?)

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Dumping core on windows?

[Brian Dessent]

Ben Greear wrote:

> Is there any way to configure windows to dump a core file
> that GDB can decode?

If you are using Cygwin, the dumper utility is provided for this.  See
the users guide.

> (Or, get a stack-trace some other way?)

Attach to the process and "bt"?  No core file is needed for that.  Maybe
you should supply some more details.

Brian

Re: Dumping core on windows?

[Ben Greear]

Brian Dessent wrote:
> Ben Greear wrote:
> 
> 
>>Is there any way to configure windows to dump a core file
>>that GDB can decode?
> 
> 
> If you are using Cygwin, the dumper utility is provided for this.  See
> the users guide.

I'm using mingw on Linux to cross-compile a windows executable.  It does
not require/use cygwin, but I can use cygwin if that will do what I need.
I'll investigate the dumper tool.

>>(Or, get a stack-trace some other way?)
> 
> 
> Attach to the process and "bt"?  No core file is needed for that.  Maybe
> you should supply some more details.

After hours or days, my application crashes.  It's not overly convenient for me
to attach gdb to the process(es), but it can be done if that is the only way.

Is there a way to have gdb automatically start running an app, for instance, something
like this:

gdb --exe=foo.exe --autostart --command="--arg1 --arg2=bar"

I know you can pipe commands in, but that's a bit inconvenient...

Thanks,
Ben

> 
> Brian
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Dumping core on windows?

[Christopher Faylor]

On Wed, Nov 16, 2005 at 11:58:04AM -0800, Ben Greear wrote:
>Brian Dessent wrote:
>>Ben Greear wrote:
>>>Is there any way to configure windows to dump a core file that GDB can
>>>decode?
>>
>>If you are using Cygwin, the dumper utility is provided for this.  See
>>the users guide.
>
>I'm using mingw on Linux to cross-compile a windows executable.  It
>does not require/use cygwin, but I can use cygwin if that will do what
>I need.  I'll investigate the dumper tool.

AFAIK, the only thing that's cygwin-specific about dumper.exe is to use
cygwin's "just in time" debugging facility so, although dumper.exe
should be able to produce a core file that gdb will understand, I don't
think there's any way to have it called automatically when a SEGV (or
whatever) happens.

>>>(Or, get a stack-trace some other way?)
>>
>>Attach to the process and "bt"?  No core file is needed for that.
>>Maybe you should supply some more details.
>
>After hours or days, my application crashes.  It's not overly
>convenient for me to attach gdb to the process(es), but it can be done
>if that is the only way.
>
>Is there a way to have gdb automatically start running an app, for
>instance, something like this:
>
>gdb --exe=foo.exe --autostart --command="--arg1 --arg2=bar"
>
>I know you can pipe commands in, but that's a bit inconvenient...

Perhaps "gdb --help" would be of some interest to you.  It reveals this
option:

  gdb --args foo --arg1 --arg2

cgf

Re: Dumping core on windows?

[Brian Dessent]

Ben Greear wrote:

> After hours or days, my application crashes.  It's not overly convenient for me
> to attach gdb to the process(es), but it can be done if that is the only way.

Since your app is not a Cygwin program you can't just set 'error_start'
in $CYGWIN.  But you can do the equivalent to set dumper as the windows
JIT debugger.  Set "HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\AeDebug\Debugger" to a REG_SZ of the filename and args
of dumper.  Use "%ld" to represent the PID.  e.g.
"c:\cygwin\bin\dumper.exe myapp %ld" will create myapp.core when the
program faults.  Set "HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\AeDebug\Auto" to a REG_SZ of "1" to have this happen
without the popup "This application has performed an illegal operation,
... [Debug]  [Close]".  However, if you do this then there will be no
indication of the fault -- other than the existance of the core file and
your app no longer running (and possibly an entry in the event log) --
so you might want to leave auto at 0 if you want to see when the fault
occurs.

Brian

Re: Dumping core on windows?

[Ben Greear]

Brian Dessent wrote:
> Ben Greear wrote:
> 
> 
>>After hours or days, my application crashes.  It's not overly convenient for me
>>to attach gdb to the process(es), but it can be done if that is the only way.
> 
> 
> Since your app is not a Cygwin program you can't just set 'error_start'
> in $CYGWIN.  But you can do the equivalent to set dumper as the windows
> JIT debugger.  Set "HKLM\SOFTWARE\Microsoft\Windows
> NT\CurrentVersion\AeDebug\Debugger" to a REG_SZ of the filename and args
> of dumper.  Use "%ld" to represent the PID.  e.g.
> "c:\cygwin\bin\dumper.exe myapp %ld" will create myapp.core when the
> program faults.  Set "HKLM\SOFTWARE\Microsoft\Windows
> NT\CurrentVersion\AeDebug\Auto" to a REG_SZ of "1" to have this happen
> without the popup "This application has performed an illegal operation,
> ... [Debug]  [Close]".  However, if you do this then there will be no
> indication of the fault -- other than the existance of the core file and
> your app no longer running (and possibly an entry in the event log) --
> so you might want to leave auto at 0 if you want to see when the fault
> occurs.

That sounds like exactly what I want!  I'll let you know how it goes.

Thanks,
Ben

> 
> Brian
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Dumping core on windows?

[Christopher Faylor]

On Wed, Nov 16, 2005 at 02:23:37PM -0800, Brian Dessent wrote:
>Ben Greear wrote:
>>After hours or days, my application crashes.  It's not overly
>>convenient for me to attach gdb to the process(es), but it can be done
>>if that is the only way.
>
>Since your app is not a Cygwin program you can't just set 'error_start'
>in $CYGWIN.  But you can do the equivalent to set dumper as the windows
>JIT debugger.  Set "HKLM\SOFTWARE\Microsoft\Windows
>NT\CurrentVersion\AeDebug\Debugger" to a REG_SZ of the filename and
>args of dumper.  Use "%ld" to represent the PID.  e.g.
>"c:\cygwin\bin\dumper.exe myapp %ld" will create myapp.core when the
>program faults.  Set "HKLM\SOFTWARE\Microsoft\Windows
>NT\CurrentVersion\AeDebug\Auto" to a REG_SZ of "1" to have this happen
>without the popup "This application has performed an illegal operation,
>...  [Debug] [Close]".  However, if you do this then there will be no
>indication of the fault -- other than the existance of the core file
>and your app no longer running (and possibly an entry in the event log)
>-- so you might want to leave auto at 0 if you want to see when the
>fault occurs.

Have you actually tried this, Brian?  I was going to suggest something
like this but I wasn't sure if it worked with dumper.

cgf

Re: Dumping core on windows?

[Brian Dessent]

Christopher Faylor wrote:

> Have you actually tried this, Brian?  I was going to suggest something
> like this but I wasn't sure if it worked with dumper.

Yeah, I tried it before posting and it seemed to work - it created the
core but I didn't try loading it into GDB.  At first I thought it did
not, though, because I was trying to specify a path to the filename
argument of dumper, which does not work - it seems to create it using
the given filename in the CWD of the faulting program, regardless of any
path you give it.

And I forgot to mention that you can run "drwtsn32 -i" to reinstall the
default Dr. Watson fault handler after you're done with dumper.

(BTW, there is a second %ld argument that the system will pass if
present, I'm not sure what it represents though.  Perhaps it's the
exception number, but I tried testing with an access violation but the
second parameter was 1928 - nothing close to 0xC0000005.  I thought it
also might have been the thread ID of the fault but that did not match
up either... so it's a mystery to me.)

Brian

Re: Dumping core on windows?

[Ben Greear]

Brian Dessent wrote:
> Christopher Faylor wrote:
> 
> 
>>Have you actually tried this, Brian?  I was going to suggest something
>>like this but I wasn't sure if it worked with dumper.
> 
> 
> Yeah, I tried it before posting and it seemed to work - it created the
> core but I didn't try loading it into GDB.  At first I thought it did
> not, though, because I was trying to specify a path to the filename
> argument of dumper, which does not work - it seems to create it using
> the given filename in the CWD of the faulting program, regardless of any
> path you give it.

Is there a way to get the program name programatically so that this
works with any application?  For instance, I'm using this value
for Debugger:

c:\cygwin\bin\dumper.exe btserver %ld

but I'm guessing that it will not work if any other application dies.

Also, is there a way to cause a fault in a program for
testing, similar to 'kill -11 pid' ?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Dumping core on windows?

[Brian Dessent]

Ben Greear wrote:

> Is there a way to get the program name programatically so that this
> works with any application?  For instance, I'm using this value
> for Debugger:

Not that I know of.  Of course, you could easily write a wrapper for
dumper that uses the PID to get the image name of the faulting process,
and calls dumper with that filename.  Or just patch dumper to do this.

> Also, is there a way to cause a fault in a program for
> testing, similar to 'kill -11 pid' ?

You can just run dumper directly with the pid of the running process to
generate a core file without causing a fault.  However this will cause
the process to terminate (something about a win32 limitation of not
being able to detach from a process without killing it.)

Brian

Re: Dumping core on windows?

[Christopher Faylor]

On Wed, Nov 16, 2005 at 05:38:45PM -0800, Brian Dessent wrote:
>Ben Greear wrote:
>>Is there a way to get the program name programatically so that this
>>works with any application?  For instance, I'm using this value for
>>Debugger:
>
>Not that I know of.  Of course, you could easily write a wrapper for
>dumper that uses the PID to get the image name of the faulting process,
>and calls dumper with that filename.  Or just patch dumper to do this.
>
>>Also, is there a way to cause a fault in a program for testing, similar
>>to 'kill -11 pid' ?
>
>You can just run dumper directly with the pid of the running process to
>generate a core file without causing a fault.  However this will cause
>the process to terminate (something about a win32 limitation of not
>being able to detach from a process without killing it.)

This limitation does not exist on XP or greater.  Corinna Vinschen modified
gdb to take advantage of that fact.

See DebugSetProcessKillOnExit.

cgf

gdb and threads on windows.

[Ben Greear]

For some reason, my applications shows 970 threads and is
effectively deadlocked.  This is on a windows-xp system.  The
win2k system does not appear to have this problem.  I attached
to the running process with gdb.  The backtraces for 2-970 look like
this:


Thread 7 (thread 7436.0xfe0):
#0  0x7c90eb94 in _libws2_32_a_iname ()
#1  0x7c90e9c0 in _libws2_32_a_iname ()


Thread 1 is slightly more interesting:

(gdb) bt
#0  0x7c90eb94 in _libws2_32_a_iname ()
#1  0x7c90e9c0 in _libws2_32_a_iname ()
#2  0x7c802542 in _libws2_32_a_iname ()
#3  0x5a703e6e in _libws2_32_a_iname ()
#4  0x5a70c6d0 in _libws2_32_a_iname ()
#5  0x003d2aa0 in ?? ()
#6  0xffffffff in ?? ()
(gdb) quit


I am using threads in the code, but this process never created any
threads explicitly.  Maybe something like a name resolver is 'helping' me?

Is there anything I can do to get gdb to give better backtraces?
(My app is not stripped, so symbols should be available.)

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Dumping core on windows?

[Ben Greear]

Brian Dessent wrote:
> Christopher Faylor wrote:
> 
> 
>>Have you actually tried this, Brian?  I was going to suggest something
>>like this but I wasn't sure if it worked with dumper.
> 
> 
> Yeah, I tried it before posting and it seemed to work - it created the
> core but I didn't try loading it into GDB.  At first I thought it did
> not, though, because I was trying to specify a path to the filename
> argument of dumper, which does not work - it seems to create it using
> the given filename in the CWD of the faulting program, regardless of any
> path you give it.

I got a core file out of the deal...but gdb is not happy loading it:

(gdb) core btserver.core
warning: core file may not match specified executable file.
warning: Couldn't find general-purpose registers in core file.

warning: Couldn't find general-purpose registers in core file.

#0  0x53676e69 in ?? ()
(gdb)

Any ideas?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com