kristina@sandia.uucp (Kristina Buchholtz (9226)) (04/30/91)
Hi, I am trying to run Isis the above-mentioned configuration, and have
a few problems.
-- ISSUE 1 --
First, a piece of code that works fine on our SUN4's is crashing on our
DEC's. The code contains the following:
address *gaddr_p;
groupview *gv;
.
.
.
gaddr_p = pg_lookup("use_sat_param");
gv = pg_getview(*gaddr_p)
The pg_getview causes a segmentation fault and a core dump.
If I comment out the pg_getview, everything works fine. Are there any known
bugs that cause this?
-- ISSUE 2 -- (Interfacing to Ada)
Next, does anybody have experience interfacing Isis to Ada (or any other
language, for that matter)? I am attempting to interface Isis to Verdix
6.0 Ada. I have an ada client program that does pragma interfaces to C to get
the Isis functions that I need. The ada does the appropriate Isis_Init, then
does:
Isis_Task(
Types.C_Pointer(client_Maintask'ADDRESS), "client_maintask" & ASCII.NUL
);
Isis_Entry(
1, Types.C_Pointer(Read_New_Table'ADDRESS), "read_new_table" & ASCII.NUL
);
Isis_Mainloop(Types.C_Pointer(Client_Maintask.ADDRESS));
When Client_Maintask gets called, I get an Ada Storage_Error (and the
message: Error in kernel:: exception handler: below bottom of user stack),
which I can get rid of if I do a PRAGMA SUPPRESS(Storage_Check); the same
thing happens when read_new_table gets called. Now, on our SUN4's, if I do
the pragma suppress, read_new_table gets called and can actually do something.
However, on our DEC's, when read_new_table gets called, I get the message:
(This is what I get when not in debugger)
pid 16416 (ada_client) was killed on kernel access, at pc 0x40b670
Bus error (core dumped)
(This is what I get when in debugger)
"Bus error" [10]
Bus error (SIGBUS) code: 1 (u_coode: 43)
Anybody have any ideas on this?
-- ISSUE 3 -- (Doing Ada I/O)
Thirdly, even on the SUN4's (and even if I have a pragma
suppress(storage_check) in place), if the subprogram read_new_table tries to do
any Ada I/O operations (i.e. text_io.put_line), I get a storage_error.
I am hoping that if I actually start up Isis from an ada program instead of
a C program, the right environment will be set up and I'll be able to do
ada i/o. Can anyone confirm or deny this?
Thanks for any help
Kristina Buchholtzken@CS.Cornell.EDU (Ken Birman) (04/30/91)
In article <454@sandia.UUCP> kristina@sandia.uucp (Kristina Buchholtz (9226)) writes: >Hi, I am trying to run Isis the above-mentioned configuration, and have >a few problems. > >-- ISSUE 1 -- > >First, a piece of code that works fine on our SUN4's is crashing on our >DEC's. The code contains the following: > >address *gaddr_p; >groupview *gv; >. >. >. >gaddr_p = pg_lookup("use_sat_param"); >gv = pg_getview(*gaddr_p) > >The pg_getview causes a segmentation fault and a core dump. No surprise: pg_getview expects a pointer and you are passing the address by value. My guess is that this only worked on your SUN4 because it chose to pass the "by value" address as a pointer to a stacked copy, and so the routine saw a pointer anyhow; the MIPS compiler probably noticed that an address is 8 bytes long and decided to pass it in two registers, exposing the bug. >If I comment out the pg_getview, everything works fine. Are there any known >bugs that cause this? Well, ahem... This sort of thing is detected using the ANSI headers from ISIS, for example from GCC. You could try compiling with them enabled if you run into this a lot -- this will cause the compiler to enforce the correct argument type signatures and would have flagged this as a bug. >-- ISSUE 2 -- (Interfacing to Ada) > >Next, does anybody have experience interfacing Isis to Ada (or any other >language, for that matter)? I am attempting to interface Isis to Verdix >6.0 Ada. I have an ada client program that does pragma interfaces to C to get >the Isis functions that I need. The ada does the appropriate Isis_Init, then >does: >Isis_Task( > Types.C_Pointer(client_Maintask'ADDRESS), "client_maintask" & ASCII.NUL > ); >Isis_Entry( > 1, Types.C_Pointer(Read_New_Table'ADDRESS), "read_new_table" & ASCII.NUL > ); >Isis_Mainloop(Types.C_Pointer(Client_Maintask.ADDRESS)); > >When Client_Maintask gets called, I get an Ada Storage_Error (and the >message: Error in kernel:: exception handler: below bottom of user stack), >which I can get rid of if I do a PRAGMA SUPPRESS(Storage_Check); the same >thing happens when read_new_table gets called. Now, on our SUN4's, if I do >the pragma suppress, read_new_table gets called and can actually do something. >However, on our DEC's, when read_new_table gets called, I get the message: > >(This is what I get when not in debugger) >pid 16416 (ada_client) was killed on kernel access, at pc 0x40b670 >Bus error (core dumped) > >(This is what I get when in debugger) >"Bus error" [10] >Bus error (SIGBUS) code: 1 (u_coode: 43) > >Anybody have any ideas on this? > I have no idea how this version of ADA works, so this is just a guess, but it sounds like the ADA code is unhappy with the ISIS dynamic stack allocation scheme -- we do move the stack pointer to point to a dynamically allocated area of memory and hence "below the bottom of the user stack". I myself am interested in an ISIS-ADA interface and would be willing to help with this offline. But, is Verdix the right version of ADA to work with? I would need to see documentation on how its tasking works and how the foreign function call interface works. In the limit, you may need to do a separate program that uses RPC to interact with your ADA code and does ISIS system calls on its behalf. >-- ISSUE 3 -- (Doing Ada I/O) > >Thirdly, even on the SUN4's (and even if I have a pragma >suppress(storage_check) in place), if the subprogram read_new_table tries to do >any Ada I/O operations (i.e. text_io.put_line), I get a storage_error. > >I am hoping that if I actually start up Isis from an ada program instead of >a C program, the right environment will be set up and I'll be able to do >ada i/o. Can anyone confirm or deny this? > This goes beyond my weak understanding of ADA. Perhaps someone else will have an idea... -- Kenneth P. Birman E-mail: ken@cs.cornell.edu 4105 Upson Hall, Dept. of Computer Science TEL: 607 255-9199 (office) Cornell University Ithaca, NY 14853 (USA) FAX: 607 255-4428