[comp.unix.aix] Illegal execution error message

fsfrick@bones (David Fricker) (04/09/91)

I'm porting a local graphics program which uses the GL calls, and I
get the error message 'illegal execution' when it bombs.  The program
is a scientific plotting/graphics package (3d, contours, etc.) which 
compiles nicely (now), starts up okay, but bombs when asked to do
graphics.

I tried running 'xde' to track down the offending call, but the following
is all I get from the debugger:

	Unreadable instruction at address 0x0
	warning: could not locate trace table from starting address 0x0
	Could not determine current function

As you can see, this is not very helpful.  I would appreciate any hints,
suggestions, incantations, etc.

In case you're interested, my system is an RS/6000 model 530 running at
level 3003.  It has the 24-bit color, Z-buffered graphics board.


Thanks for any help.
david fricker
--
-----------------------------------------------------------------------------
David Fricker			|     phone: 216-433-5960
NASA Lewis Research Center     	|     M.S. 5-11
Cleveland, Ohio  44135         	|     email: fsfrick@bones.lerc.nasa.gov 

ed@bee.austin.ibm.com (Ed Holley) (04/10/91)

What that message generally means is that your program has done a
call to address 0.  The debugger cannot figure out how you got
there, because the information about the stack frame is unavailable.

What you need to do is to find out where your program is making the jump
to address 0, either by hand stepping through your program,
or by turning the dbx trace command on.  The second method is less work
for you, but is very slow.

In article <1991Apr9.134802.26440@eagle.lerc.nasa.gov>, fsfrick@bones
(David Fricker) writes:
> I'm porting a local graphics program which uses the GL calls, and I
> get the error message 'illegal execution' when it bombs.  The program
> is a scientific plotting/graphics package (3d, contours, etc.) which 
> compiles nicely (now), starts up okay, but bombs when asked to do
> graphics.
> 
> I tried running 'xde' to track down the offending call, but the following
> is all I get from the debugger:
> 
> 	Unreadable instruction at address 0x0
> 	warning: could not locate trace table from starting address 0x0
> 	Could not determine current function
> 

----------------------------------------------------------------
Ed Holley	IBM AWD
ibm net:	ed@bee.austin.ibm.com
vnet:		holley at austin
internet:	eholley@wombat.austin.ibm.com
uucp:		...!cs.utexas.edu!ibmchs!auschs!bee.austin.ibm.com!ed

marc@stingray.austin.ibm.com (Marc J. Stephenson/140000;1C-22) (04/10/91)

In article <1991Apr9.134802.26440@eagle.lerc.nasa.gov> fsfrick@bones (David Fricker) writes:
>I'm porting a local graphics program which uses the GL calls, and I
>get the error message 'illegal execution' when it bombs.
>I tried running 'xde' to track down the offending call, but the following
>is all I get from the debugger:
>	Unreadable instruction at address 0x0
>	warning: could not locate trace table from starting address 0x0
>	Could not determine current function
>As you can see, this is not very helpful.  I would appreciate any hints...
>Thanks for any help.
>david fricker

As already mentioned, your problem is that your program has jumped to address
0.  Once it gets to that point, the debuggers can't tell where you've been
because there's no context.  Useful information that you can possibly get
from the debuggers is the value of the link register ($link in xde/dbx) which
might have a value of where that attempted call was supposed to return to.
The GPRs may still have your calling parameter values in general purpose
registers 3-10 ($r3, $r4, etc.).  After you get the return address, you can
find out what routine that was in by doing a "listi <address>" - the debugger
will show you the instruction, with the routine name + offset in parens.

Usually this type of error shows up because of an uninitialized function
pointer call.

Hope that helps.

-- 
Marc Stephenson		      IBM PSPA (Personal System Programming - Austin,TX)
DISCLAIMER: The content of this posting is independent of official IBM position.
marc@stingray.austin.ibm.com 	VNET: MARC at AUSVMQ  	IBM T/L: 793-3796

lusgr@vax1.cc.lehigh.edu (Steve Roseman) (04/10/91)

In article <1991Apr9.134802.26440@eagle.lerc.nasa.gov>, fsfrick@bones (David Fricker) writes:
> I'm porting a local graphics program which uses the GL calls, and I
> get the error message 'illegal execution' when it bombs.  The program
> is a scientific plotting/graphics package (3d, contours, etc.) which 
> compiles nicely (now), starts up okay, but bombs when asked to do
> graphics.
> 
> I tried running 'xde' to track down the offending call, but the following
> is all I get from the debugger:
> 
> 	Unreadable instruction at address 0x0
> 	warning: could not locate trace table from starting address 0x0
> 	Could not determine current function
> 
> As you can see, this is not very helpful.  I would appreciate any hints,
> suggestions, incantations, etc.
> 
> In case you're interested, my system is an RS/6000 model 530 running at
> level 3003.  It has the 24-bit color, Z-buffered graphics board.
> 
> 
> Thanks for any help.
> david fricker
> --
> -----------------------------------------------------------------------------
> David Fricker			|     phone: 216-433-5960
> NASA Lewis Research Center     	|     M.S. 5-11
> Cleveland, Ohio  44135         	|     email: fsfrick@bones.lerc.nasa.gov 
-- 

Funny, I had the same problem today with a non-graphics C program.  It was
working until I moved some code from the main routine to it's own procedure,
and defined some of the variables as global.  The error occurred somewhere far
off in routines that resided in a library and were not even recompiled.

I finally looked at a loadmap (-b:loadmap:filename.map switch on cc or ld), and
lo and behold, there was a redefinition of the name 'access', one of those new
global variables.  I changed the name and it worked.  There was a conflict with
something named 'access' somewhere.

This may not be your problem, but it's worth a try.  Look around for redefined
names that seem suspicious (access was only one of a hundred listed as
redefined.)

Good luck,
Steve

-------------------------------------------------------------------------
Steve Roseman
Lehigh University Computing Center
LUSGR@VAX1.CC.Lehigh.EDU