Peter wrote:
> > Hi folks,
> > For years I've depended on debugging within the IDE, but once
> > in a while we get an exception only in a running app and thus
> > need to track it down.
> >
> > Of late, we've been generating MAP files in the hope we could
> > use these to isolate the culprit program or data areas in such
> > cases.
> >
> > But for the life of me, I don't know how to convert from
> > "EAccessviolation at c4fffe" to the segmented addresses
> > presented the MAP file. That is to say, I *did* once know
> > (multiply top bytes by 16, then add lower ones, or some such),
> > but I have no idea if that kind of approach is what I need to get
> > from reported address to MAP file information.
> >
> > I wonder if someone who is more in the know would care to spell
> > it out a little. <g>
Ok, forget all that 'multiply by 16' stuff - that's for real mode, not
32-bit flat protected mode.
The MAP segments are only logical segments (it's a linear address space) and
in any case, all the code is in logical segment 1 (.text) so all you need to
know is there in the sizes and offsets.
Now, to go from an exception address to a MAP offset, you need to take into
account your ImageBase (normally $400000 in 32-bit Delphi) and the starting
code offset which appears to be $1000 (can't remember why)
So the executive summary is ExceptAddr - $401000, look up within segment
0001: in the 'Publics by Value' section.
In the end, I wrote a unit which parses detailed MAP files and has a number
of routines to tell you the file, function, and line number for a given
address. It has a AsMapAddr() function to do the translations for you. Our
application logs any exceptions, assertions, etc. along with the addresses
to a file. I then wrote a simple tool called MapLook which you can use to
load a MAP file (we save one away for each build we ship) and then
interactively determine where various addresses resolve to.
Mighty handy for those strange exceptions we get in the field. We were able
to determine that one strange exception was due to a buggy video driver for
an obscure and cheap '3d' accelerator card corrupting the FPU state inside
DrawIcon (I kid you not) via combined use of TD32 and MapLook.
The MAP file parsing takes longer than I'd like but then our detailed MAP
files are in the order of 10+ Mbs :-) I'm sure I can probably optimise that
if I ever get some spare time...
Ideally, I'd like to extend this to log away a whole stack trace since
sometimes the final exception location doesn't tell you enough of the code
path to grok the root cause. One of these days, I'll have to spelunk around
and see if it's possible to write some code to build a stack trace.
The problem is that I think the exception handlers will have unwound back
and possibly clobbered the initial stack frame so it might require some
serious Win32 exception voodoo to try to get that saved away before Delphi
can start stack unwinding. I've got a MSJ article about that stuff by Matt
Pietrek lurking around here somewhere...
TTFN,
Paul.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
