This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Bug Report: Illegal Instruction
- To: Alexandre Oliva <aoliva at cygnus dot com>
- Subject: Re: Bug Report: Illegal Instruction
- From: Bill <billl at unm dot edu>
- Date: Tue, 23 May 2000 21:56:59 -0600 (MDT)
- cc: gcc-bugs at gcc dot gnu dot org
> Run it within a debugger and see how it crashes. If it's a totally
> strange address, odds are that you've inadvertently overwritten part
> of the stack by overrunning a fixed-size buffer.
> I had previously ran it with a debugger (gdb 4.1.6). Here's the
> result:
> "Program received signal SIGILL, Illegal instruction.
> 0x0 in ?? () from /nfs/user/b/billl/test/notwork/TABLE
> (gdb)"
So it's very likely that you've somehow corrupted the stack, which was
already hinted at because moving part of the function into a separate
function altered the behavior.
I'd set a breakpoint in the method that fails to complete and run it
step-by-step, looking at the stack trace (`where') after each step.
When the stack trace breaks, you've found the culprit.
Okay, I set a break before the first for-loop. Here is the stack:
Breakpoint 1, Table::Print (this=0x2ff22c30, out=@0x20000db4) at
Table.C:191
191 Element ** El(NULL);
(gdb) where
#0 Table::Print (this=0x2ff22c30, out=@0x20000db4) at Table.C:191
#1 0x10000514 in main () at Run.C:15
#2 0x100001dc in __start ()
Then, using the debugger, I stepped through the code through to the
point of the "illegal instruction". The stack never changed. Here
it is just before the error. This is occuring on the third increment
of for-loop 1's control variable and on the start of the third run of
for-loop 2.
220 out << temp;
(gdb) where
#0 Table::Print (this=0x2ff22c30, out=@0x20000db4) at Table.C:220
#1 0x10000514 in main () at Run.C:15
#2 0x100001dc in __start ()
(gdb) n
Program received signal SIGILL, Illegal instruction.
0x0 in ?? () from /nfs/user/b/billl/test/notwork/TABLE
(gdb)
I do not see any differences between the two stacks. Hmmm ...
Bill