Conference turris::ada

This is being enetered for Jean-Michel, who's having problems access
our notes file.


=========================================

Hello,

We are having a problem right now, and I am trying to isolate which
component is triggering it, i.e. our application, the ADARTL or
the Decthread RTL.

This is under OpenVMS V7.1 (only), standard ADARTL and Decthread RTL's, 
comming from the SSB kit. The ada compiler is DEC ADA V3.3-22.

In our application, we have a procedure which does a TEXT_IO.OPEN, then
write to the file (TEXT_IO.PUT and PUT_LINE ) and close it. During this 
operation, a periodic timer Ast is fired by OpenVMS following a timer 
expiry. The timer request was set by the application.

We have found that if we call a procedure, call it A, which calls TEXT_IO
entries, we get an access violation in the first instruction of the Ast 
the first time the Ast is fired again after the main stream has entered 
the said procedure A. The first intruction of the prolog Ast code does a 
kind of stack checking, moving zero somewhere on the stack, way above its 
current location, so generating the access violation. If we remove all 
calls to the TEXT_IO procedures, the crash doesn't occur. Further testing 
has shown that keeping the call to TEXT_IO.OPEN only, triggers the 
problem too.

So it seems not to be a timing problem because we can reproduce it with 
an optimized version and with a non optimized version, this last one 
being loaded with the debugger.

In this application, we don't have any tasking at all, just a Main and 
some Ast's. (I understand that there is an implicit root task hanging 
around.)

I suspect that it could be a kind of stack pointer setup, something like
the Ast being delivered in the context of the root thread with, in this 
case, a stack size being to short, so we end up in the guard pages. 

The debugger output of "show task/all" shows only one task and the stack 
pointer being in S0. The access violation is also in an S0 address.

I understand this could be extremely difficult to track, but do you have 
any though about a way to track this ??

The only way I see is to reduce the stack usage asked by the Ast, but it 
may not be possible for us, or to change the stack size of the root task.

I don't think this is related to the Ada compiler itself, other than the 
fact that it is checking the stack with an offset being too big.

I understand that there may be not enough informations here, but I didn't 
find any usefull output to include, so if you need more, please ask me. 
Also, trying to reduce the code to a smaller example was not successfull.

Thank's a lot for your help,

Jean-Michel

This sounds like you have the situation described in the OpenVMS release notes
about AST handlers written in Ada.  If this is correct, the AST is being
delivered to DECthreads' null thread, and the stack probing code (automatically
generated for Ada code) then produces an ACCVIO.  The only workaround available
is to switch to using pragma Ast_Entry.

Clarification.  If this is the problem described in .2, then this is a
known problem, and is documented in the VMS release notes.

Workaround is to recode using pragma AST_ENTRY.

Charlie

Ok, I had a feeling it was something like this. But, there is
a point which is not clear for me. If we don't call the
TEXT_IO.OPEN, things work well, we don't get any crash. I would
like to understand the effect of calling OPEN. It may be that the
Stack pointer is not restored to its right value following the
call to OPEN, I know, silly idea but who knows ;-)

What do you think ??

Jean-Michel

This is just a guess, but: changing what you call can affect timing, which in
turn can influence whether you happen to be running the null thread when an AST
fires.  The change in behavior could be entirely accidental, and have nothing to
do with any property of the OPEN routine.

Of course, if this guess were proved to be wrong, I wouldn't be surprised.  :-)
However, you might be able to partially test this guess as follows: does the
behavior go away if you call a dummy routine which just burns CPU time and
otherwise does nothing (to insure the null thread doesn't run)?

Hello,

Related to this topic, is this problem tied to Ada or could it
happen with another language. Our problem is that, although the
main of the application is written in Ada with Ast's in it, we
are also using a sharable image written in C which has some Ast's
in it. I suspect the problem is general and not tied to Ada.

Thank's,

Jean-Michel 

I'll take a quick shot, but Mike may have to correct me.

DECthreads made a change in VMS 7.0 so that our stack checking no longer
works for Ada written AST handlers, unless they have pragma AST_ENTRY
associated with them.  The stack size without that pragma is too small
for us.  I don't know if this would effect C...

Charlie