I wrote:
My next experiment is to put both File_Array and Virtual_File into the
same storage pool and see what happens with that.
I not only did that, I also put Contents_Access into that same storage
pool (Contents_Access is the value associated with a Virtual_File, which
in turn is used as the elements in a File_Array).
And the end result is that, upon exit, you get this:
raised PROGRAM_ERROR : g-debpoo.adb:1274
This corresponds to this block of code:
if Header.Block_Size < 0 then
if Pool.Raise_Exceptions then
raise Accessing_Deallocated_Storage;
else
So...on exit we're trying to access already-deallocated storage. Nice.
I modified the Contents_Access finalization code to configure the debug
pool to not raise exceptions and instead to print out the various
information it can when encountering this error. The end result looks
like this:
error: Accessing deallocated storage, at 0x00002B9C548EB270
0x00002B9C548EB60E 0x00000000007DA5E9 0x00000000007DA896
0x00000000004863F4 0x00000000004871E0 0x00000000004862E9
0x0000000000486237 0x00002B9C5467ECFC 0x0000000000451372
0x000000000044A274 0x00002B9C54D2D4C8 0x0000000000448528
First deallocation at 0x00002B9C548EAD4D 0x00002B9C548EB7A8
0x00000000007DA862 0x00000000007DA896 0x00000000004863F4
0x00000000007E247D 0x00000000007E20E3 0x0000000000802905
0x00002B9C5377EA52 0x00002B9C55771477 0x00002B9C55780ADF
0x00002B9C55781D93 0x00002B9C55781F71 0x00002B9C55098BFE
0x00002B9C557735EE 0x00002B9C536BB040 0x000000000080242C
0x00002B9C5377E958 0x00002B9C55771477 0x00002B9C55780ADF
Initial allocation at 0x00002B9C548EAD4D 0x00002B9C548EAF32
0x00000000007C17E1 0x00000000007C12CB 0x00000000007C1F00
0x00000000007D512D 0x00000000007F34E9 0x00000000007E5156
0x00002B9C559D6911 0x00002B9C559D975B 0x00002B9C559D9A44
0x00002B9C550796B0 0x00000000007EF8AD 0x00000000007EE29B
0x0000000001881F67 0x00002B9C5377E958 0x00002B9C55771477
0x00002B9C55780ADF 0x00002B9C55781D93 0x00002B9C55781F71
There are quite a number of these.
Now, the next logical step is to set a breakpoint at that location to
see where in the code it's generating that, and to allow me to translate
those addresses into something more meaningful. The problem is, I can't
figure out how. Setting breakpoints on exceptions doesn't seem to work
(and doesn't matter anyway when I have the pool configured not to
generate them).
g-debpoo.adb is part of the GNAT runtime, and it seems it's compiled in
such a way as to make it impossible to debug it (the end result is that
runtime library calls, when made from a program, will be treated as an
atomic operation by the debugger, so doing a "step" and doing a "next"
wind up being identical -- the debugger won't, at a source code level,
let you step into a runtime library function).
I tried copying that one file into a new source directory I created
under gnat-gps-4.0.1 for that purpose (and added that directory to
gps.gpr, of course), but that just causes the program to fail to
compile. It seems I have to bring over pretty much the entire runtime
library (including the one for gtkada) to get it to compile that way,
and I'd have to screw with the associated project files as well.
So I'm tempted to file another bug, this one against libgnat-4.1,
stating that we need to compile a debug version (that would land in
/usr/lib/debug) so that it's possible to set breakpoints within library
functions. We should do so for the various libgtkada-2.8 libraries as
well, but libgnat is by far the most important in this regard.
Thoughts?
--
Kevin Brown [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
