reactos-kernel

Re: [ros-kernel] More useful stack traces

[Casper H. <ch...@us...>]

s=F8n, 2002-07-14 kl. 14:00 skrev David Welch:
> On Sat, Jul 13, 2002 at 11:27:19PM +0200, Casper Hornstrup wrote:
> > How?
> >
> I think this feature rather falls between two stools: for non-technical u=
sers
> we need a core dump facility which can be automatically decoded offline a=
nd
> emailed to us; developers (who don't have two machines) need a kernel
> debugger which uses all debugging information and has source code
> available as well.

A core dump facility would be nice, but I think it is complementary to
the linenumber information in stack traces; not a replacement for it. To
be able to core dump, the storage driver stack must be loaded so disks
are accessible. For all crashes before this happens, core dumping is
useless. Also, I don't always setup a system with a debugger because it
is difficult and sometimes it helps a lot just knowing the line of code
where a crash occur.

Casper

Re: [ros-kernel] More useful stack traces

[Casper H. <ch...@us...>]

s=F8n, 2002-07-14 kl. 13:53 skrev Casper Hornstrup:
> s=F8n, 2002-07-14 kl. 14:00 skrev David Welch:
> > On Sat, Jul 13, 2002 at 11:27:19PM +0200, Casper Hornstrup wrote:
> > > How?
> > >
> > I think this feature rather falls between two stools: for non-technical=
 users
> > we need a core dump facility which can be automatically decoded offline=
 and
> > emailed to us; developers (who don't have two machines) need a kernel
> > debugger which uses all debugging information and has source code
> > available as well.
>=20
> A core dump facility would be nice, but I think it is complementary to
> the linenumber information in stack traces; not a replacement for it. To
> be able to core dump, the storage driver stack must be loaded so disks
> are accessible. For all crashes before this happens, core dumping is
> useless. Also, I don't always setup a system with a debugger because it
> is difficult and sometimes it helps a lot just knowing the line of code
> where a crash occur.
>=20
> Casper

Also, core dumping is only useful to developers when they have symbol
information. This would mean that either 1) the core dump would contain
the symbols (meaning that non-stripped images need to be used or the
symbols come from the .sym files) or b) core dumps are limited to beeing
generated by official releases so the developer has the symbol
information available. If b) then 6 months is probably too long between
releases. It would be nice if GDB will understand the core dumps.

Casper

[ros-kernel] atapi.c debug results

[Royce M. I. <ro...@ev...>]

(atapi.c:1458) AtapiSendAtapiCommand() done
(atapi.c:644) SrbStatus = SRB_STATUS_PENDING
(atapi.c:647) AtapiStartIo() done
(atapi.c:670) AtapiInterrupt() called!
(atapi.c:680) Srb: c0080450
(atapi.c:684) CommandPortBase: 170  ControlPortBase: 376
(atapi.c:687) IsAtapi == TRUE
(atapi.c:1959) AtapiErrorToScsi() called
(atapi.c:1985) ATAPI error: SCSI_SENSE_NOT_READY
(atapi.c:2069) AtapiErrorToScsi() done
(atapi.c:839) AtapiInterrupt() done!
(atapi.c:670) AtapiInterrupt() called!
(atapi.c:675) AtapiInterrupt(): Unexpected interrupt
(atapi.c:605) AtapiStartIo() called
(atapi.c:1335) AtapiSendAtapiCommand() called!
(atapi.c:1362) AtapiSendAtapiCommand(): TargetId: 1
(atapi.c:1382) status=51
(atapi.c:1383) waited 0 usecs for busy to clear
(atapi.c:1449) CdbSize: 12
(atapi.c:1458) AtapiSendAtapiCommand() done
(atapi.c:644) SrbStatus = SRB_STATUS_PENDING
(atapi.c:647) AtapiStartIo() done
(atapi.c:670) AtapiInterrupt() called!
(atapi.c:680) Srb: c0369d8a
(atapi.c:684) CommandPortBase: 170  ControlPortBase: 376
(atapi.c:687) IsAtapi == TRUE
(atapi.c:704) Read data
(atapi.c:719) TransferLength: 18
(atapi.c:720) TransferSize: 18
(atapi.c:733) IsLastBlock == TRUE
(atapi.c:839) AtapiInterrupt() done!
(atapi.c:670) AtapiInterrupt() called!
(atapi.c:675) AtapiInterrupt(): Unexpected interrupt
(atapi.c:670) AtapiInterrupt() called!
(atapi.c:675) AtapiInterrupt(): Unexpected interrupt

Initializing system32\drivers\vfatfs.sys...
Bug detected code: 0x1D
Divide Error Exception: 0(0)
Processor: 0 CS:EIP 8:c003ce2b <hal.dll: 3ce2b>
cr2 0 cr3 272000 Proc: c0301aa6 Pid: 1 <SYSTEM> Thrd: c03126f4 Tid: 1
DS 10 ES 10 FS 30 GS 10
EAX: ffffffff   EBX: c0086750   ECX: c008c988
EDX: ffffffff   EBP: c00809c0   ESI: 00200000
EDI: 00000000   EFLAGS: 00010286 kESP: c0080904 kernel stack base c007e000
ESP c0080904
Frames: <ntoskrnl.exe: 3cbdd><ntoskrnl.exe: 3cc38><ntoskrnl.exe:
2ad96><ntoskrnl
.exe: 334bb><ntoskrnl.exe: aa54><ntoskrnl.exe: ab51><ntoskrnl.exe:
b0f0><ntoskrn
l.exe: 117c>

Re: [ros-kernel] atapi.c debug results

[Royce M. I. <ro...@ev...>]

OOps.... discard the other one... big typo on my part...

(atapi.c:1458) AtapiSendAtapiCommand() done
(atapi.c:644) SrbStatus = SRB_STATUS_PENDING
(atapi.c:647) AtapiStartIo() done
(atapi.c:670) AtapiInterrupt() called!
(atapi.c:680) Srb: c0080450
(atapi.c:684) CommandPortBase: 170  ControlPortBase: 376
(atapi.c:687) IsAtapi == TRUE
(atapi.c:1959) AtapiErrorToScsi() called
(atapi.c:1985) ATAPI error: SCSI_SENSE_NOT_READY
(atapi.c:2069) AtapiErrorToScsi() done
(atapi.c:839) AtapiInterrupt() done!
(atapi.c:670) AtapiInterrupt() called!
(atapi.c:675) AtapiInterrupt(): Unexpected interrupt
(atapi.c:605) AtapiStartIo() called
(atapi.c:1335) AtapiSendAtapiCommand() called!
(atapi.c:1362) AtapiSendAtapiCommand(): TargetId: 1
(atapi.c:1382) status=51
(atapi.c:1383) waited 0 usecs for busy to clear
(atapi.c:1449) CdbSize: 12
(atapi.c:1458) AtapiSendAtapiCommand() done
(atapi.c:644) SrbStatus = SRB_STATUS_PENDING
(atapi.c:647) AtapiStartIo() done
(atapi.c:670) AtapiInterrupt() called!
(atapi.c:680) Srb: c0369d8a
(atapi.c:684) CommandPortBase: 170  ControlPortBase: 376
(atapi.c:687) IsAtapi == TRUE
(atapi.c:704) Read data
(atapi.c:719) TransferLength: 18
(atapi.c:720) TransferSize: 18
(atapi.c:733) IsLastBlock == TRUE
(atapi.c:839) AtapiInterrupt() done!
(atapi.c:670) AtapiInterrupt() called!
(atapi.c:675) AtapiInterrupt(): Unexpected interrupt
(atapi.c:670) AtapiInterrupt() called!
(atapi.c:675) AtapiInterrupt(): Unexpected interrupt

Initializing system32\drivers\vfatfs.sys...
Bug detected code: 0x1D
Divide Error Exception: 0(0)
Processor: 0 CS:EIP 8:c003ce2b <ntoskrnl.exe: 3ce2b>
cr2 0 cr3 272000 Proc: c0301aa6 Pid: 1 <SYSTEM> Thrd: c03126f4 Tid: 1
DS 10 ES 10 FS 30 GS 10
EAX: ffffffff   EBX: c0086750   ECX: c008c988
EDX: ffffffff   EBP: c00809c0   ESI: 00200000
EDI: 00000000   EFLAGS: 00010286 kESP: c0080904 kernel stack base c007e000
ESP c0080904
Frames: <ntoskrnl.exe: 3cbdd><ntoskrnl.exe: 3cc38><ntoskrnl.exe:
2ad96><ntoskrnl
.exe: 334bb><ntoskrnl.exe: aa54><ntoskrnl.exe: ab51><ntoskrnl.exe:
b0f0><ntoskrn
l.exe: 117c>

Re: [ros-kernel] More useful stack traces

[David W. <we...@cw...>]

On Sun, Jul 14, 2002 at 02:52:55PM +0200, Casper Hornstrup wrote:
> Also, core dumping is only useful to developers when they have symbol
> information. This would mean that either 1) the core dump would contain
> the symbols (meaning that non-stripped images need to be used or the
> symbols come from the .sym files) or b) core dumps are limited to beeing
> generated by official releases so the developer has the symbol
> information available. If b) then 6 months is probably too long between
> releases. 
>
The way I envisaged it working was that the user would run a tool to
postprocess the core dump and produce information which could be emailed to us.
We wouldn't want people sending 256MB files (or whatever the average memory
size is these days) anyway. Obviously the core dump would have to contain
a module list but the actual matching up of addresses to symbols could be
done offline. Also we would need to have debugging information produced
on builds of all types and included in offical releases. I don't see this
as a big problem, ntoskrnl and the default hal have been built with '-g'
unconditionally for years.

Re: [ros-kernel] More useful stack traces

[Casper H. <ch...@us...>]

s=F8n, 2002-07-14 kl. 18:26 skrev David Welch:
> On Sun, Jul 14, 2002 at 02:52:55PM +0200, Casper Hornstrup wrote:
> > Also, core dumping is only useful to developers when they have symbol
> > information. This would mean that either 1) the core dump would contain
> > the symbols (meaning that non-stripped images need to be used or the
> > symbols come from the .sym files) or b) core dumps are limited to beein=
g
> > generated by official releases so the developer has the symbol
> > information available. If b) then 6 months is probably too long between
> > releases.=20
> >
> The way I envisaged it working was that the user would run a tool to
> postprocess the core dump and produce information which could be emailed =
to us.
> We wouldn't want people sending 256MB files (or whatever the average memo=
ry
> size is these days) anyway. Obviously the core dump would have to contain
> a module list but the actual matching up of addresses to symbols could be
> done offline. Also we would need to have debugging information produced
> on builds of all types and included in offical releases. I don't see this
> as a big problem, ntoskrnl and the default hal have been built with '-g'
> unconditionally for years.

So you say it should dump the whole memory instead of just part of it (a
small memory dump in NT)? I guess it would not be too difficult to skip
free pages when dumping. Since you want to do post-processing, it sounds
like you don't care if the core dump can be interpreted by already
available debuggers like gdb. So, should we write our own tools to
interpret the core dumps or modify existing?

Let's talk about what information we need from a core dump in order to
fix a bug. The bugreport with the coredump should contain enough
information to reproduce the crash. There is of course the state of the
CPU registers at the time of the crash. Then there is the module list
and the process list.

In any case core dumps are usually not enough to reproduce a bug. The
following article provides guidelines on how to produce meaningful
bugreports:

http://freshmeat.net/articles/view/149/

Casper

Re: [ros-kernel] More useful stack traces

[Royce M. I. <ro...@ev...>]

Is there any problem with using loadros with the new symbols?

How do you configure ReactOS for debugging? Is it the same as removing
NDEBUG from the source files?

----- Original Message -----
From: "Casper Hornstrup" <ch...@us...>
To: <rea...@li...>
Sent: Saturday, July 13, 2002 8:18 AM
Subject: [ros-kernel] More useful stack traces


> I have just committed a patch that enables ReactOS to understand .stabs
> symbols (only line number, function names, and source file names though,
> but this is enough to get useful stack traces when not using a
> debugger). When ReactOS is configured for debugging, ReactOS will try to
> load symbols for every module it loads. E.g. if ReactOS loads ndis.sys,
> it will also load \SystemRoot\symbols\ndis.sym if this file exists. The
> .sym files generated by ReactOS dating before today are text files. The
> new .sym files are binary files extracted by the tools/rsym build
> utility from the non-stripped module image. If you have old .sym text
> files in your ReactOS installation, you had better remove them on your
> next update or expect trouble.
>
> Symbol files for user-mode modules are shared across processes and
> cached, so the performance degration of using the symbol files is not
> significant.
>
> A new FreeLoader is not required, but necesarry if you want to get
> useful stack traces for modules passed by FreeLoader.
>
> I have made a new FreeLoader snapshot available at:
>
> http://reactos.wox.org/download.php?id=24
>
> and sources are available here:
>
> http://reactos.wox.org/download.php?id=25
>
> Happy bug-hunting to you all ;-)
>
> Casper
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel
>

Re: [ros-kernel] More useful stack traces

[Casper H. <ch...@us...>]

l=F8r, 2002-07-13 kl. 16:04 skrev Royce Mitchell III:
> Is there any problem with using loadros with the new symbols?

It may work, but I haven't used loadros for a while.

Just be sure to pass symbol files after the module they describe and
don't pass symbol files before system.hiv. E.g.

loadros ntoskrnl.exe hal.dll system.hiv ntoskrnl.sym hal.sym x.sys x.sym
is okay.

> How do you configure ReactOS for debugging? Is it the same as removing
> NDEBUG from the source files?

Do a "make clean". Then in the config file (reactos/config), change:

DBG :=3D 0

to

DBG :=3D 1

Then do a "make" and/or a "make install".

Casper