Re: Debugging Apex Ada 4.2.0c on Windows XP Pro

["Pete E." <pete.eberlein@gmail.com>]

EXT-Turpin, Daniel S wrote:
> Thanks Pete.
>
> Haven't narrowed things down enough to contact Rational yet.  We have
over 500,000 lines of Ada and quite a number of other languages
involved.  I'm in the process of building up a stripped down executable
to the point where it causes a problem.  At the same time, I have to
come up with source I am allowed to release to them.  Proprietary
issues.
>
> Anyway, when I start up the debugger on the executable it gets
through initialization and goes to the Ready state.  At that point,
stepping into the executable or setting a break and hitting Go results
in a popup from a_db.exe that says "a_db.exe has encountered a problem
and needs to close.  We are sorry for the inconvenience."  The files
assembled for transmittal to Microsoft (which I can't do) include the
crash dump for a_db.exe and an appcompat.txt file that just lists
a_db.exe and kernel32.dll.  The error signature is:
>
> EventType: BEX  P1: a_db.exe  P2: 0.0.0.0  P3: 3e3f8ab6
> P4: dbghelp.dll  P5: 5.1.2600.2180 P6: 4110969a P7: 0001295d
> P8: c0000409 P9: 00000000
>
> After this, once the popups are dismissed, the a_db.exe process dies,
but the a_db_stop.exe process does not and must be killed to allow the
IDE to continue.
>
> Right now I'm really just looking to see if anyone has experience a
similar problem running on Windows XP.  I don't have this problem on
Windows 2000 systems.  I'm certain it's something in elaboration that
is causing an exception, but haven't been real successful in finding
where yet.  Our elaboration code is rather extensive as is our use of
exception based programming, which makes it tough to set a break on an
exception/signal since there are hundreds or even thousands of them
during elaboration.
>
> Dan

I haven't seen that problem on Windows XP myself, but I have not
upgraded to SP2 yet.  Do you know if it was previously a problem with
SP1?  I assume a simple hello world program works ok in the debugger?

Instead of breaking on exceptions, you can try to break on the name of
the elaboration procedure for a package.  For the package whose
elaboration procedure you want to break, export the name of the
elaboration procedure using 'pragma Export_Elaboration_Procedure
("package_name_body_elaboration");' in the package body.  In the
debugger, on the break dialog, set the dropdown to "On Location" and
use the same name "package_name_body_elaboration" you exported by the
pragma.  This might help you narrow down where the crash is coming
from.

Regards,
Pete Eberlein