not the memory

not the memory

[Robert Schweikert]

Well,

For those of you who have answered some of my questions and for those
just following my tail. I finally got gcc-2.95.2 compiled on my RH6.2
dual CPU system. After all my tries I finally called the board
manufacturers tech support people and they asked about the CPU stepping
number and whether they are the same for the CPUs. Since I didn't know
that I had to open the machine and look at the CPUs. While jiggling
around I found the magic touch as after I had the machine back together
gcc-2.95.2 compiled without a hitch.

I haven't tried with the 2 CPU flag but will do so in the near future.

Thanks for the help.

Robert

--
Robert Schweikert                      MAY THE SOURCE BE WITH YOU
rjschwei@mindspring.com                         LINUX

Not the memory

[Robert Schweikert]

Martin,

I agree, it should never hang. Thus the idea of something getting
trashed makes perfect sense, since the behavior is somewhat random.
ALthough it mostly hangs when compiling gcc/ch/decl.c. Of course after I
reboot the machine the file compiles fine, further evidence that
something gets trashed while compiling. I am willing to compile this
thing by hand, i.e. issue a compile command for each file etc. This
would avoid the system from getting hammered, hopefully clear the cache
or whatever gets trashed and let me get to the end of this. Can you send
me a log from the "make bootstrap" that contains all the commands? Then
I can walk through and see where I get.

Thanks,
Robert

--
Robert Schweikert                      MAY THE SOURCE BE WITH YOU
rjschwei@mindspring.com                         LINUX

Re: Not the memory

[Martin v. Loewis]

> The trick is that loop calls abort() does anyone have any clue when this
> happens and why? This will hopefully point me in a direction of a fix.

It means that a NOTE_INSN_LOOP_END was found without any prior
NOTE_INSN_LOOP_BEG, which, of course, can never happen. I recommend
setting a break point on find_and_verify_loops, with a condition that
f is what it is in your case, and see whether the insn list is really
that corrupted. 

The next thing would then be to find out where it gets corrupted. You
could try to determine where the NOTE_INSN_LOOP_END is emitted, either
with a memory watchpoint, or by breaking on the three places where
NOTE_INSN_LOOP_END is emitted.

Please note that there is still no conclusive evidence that there is a
bug in gcc: It could be that your machine corrupts certain locations
in memory, which then results in gcc finding inconsistent data
structures. It doesn't have to be the memory hardware - a buggy device
driver could trigger the same effect. I remember a case where ReiserFS
would cause "random" compilation failures, by reading data off the
disk that had never been written.

> One more thing. I get the core dump only when I run "make", running
> "make bootstrap" hangs the system and I have to push reset, which of
> course is not the preferred way to shutdown the machine.

No matter what bug there is in the compiler, it should not make the
system hang, wouldn't you agree? So if the compiler manages to hang
the system, there must be a problem with the system - potentially the
same problem that causes the compilation to crash.

Regards,
Martin

Not the memory

[Robert Schweikert]

Alright, finally got back to working on this problem. I have now managed
to get a core file and thus a traceback which points me to loop.c as
follows:

Program terminated with signal 11, Segmentation fault.
#0  0x80ef58c in find_and_verify_loops (f=0x0) at loop.c:2645
2645                  abort ();
(gdb) where
#0  0x80ef58c in find_and_verify_loops (f=0x0) at loop.c:2645
#1  0x80ef75c in find_and_verify_loops (f=0x86059bc) at loop.c:2681
#2  0x80f1cda in strength_reduce (scan_start=0x856c7a0, end=0x1,
    loop_top=0xbfffd498, insn_count=135185031, loop_start=0xbfff9440,
    loop_end=0x3fa8, loop_cont=0x0, unroll_p=0, bct_p=0) at loop.c:4836
#3  0x80ec297 in delete_trivially_dead_insns (insns=0x856c7a0, nreg=1)
    at cse.c:9220
#4  0x80f1b0d in strength_reduce (scan_start=0x856c7a0, end=0x1,
loop_top=0x1,
    insn_count=0, loop_start=0x84d7acc, loop_end=0x84d6bc5,
    loop_cont=0x81faee0, unroll_p=140504824, bct_p=140504924) at
loop.c:4739
#5  0x804f47b in push_obstacks (current=0x84d7acc, saveable=0x1) at
tree.c:546
#6  0x81a65c0 in xspaces ()
#7  0x8197a7a in _IO_stdin_used ()
#8  0x804b687 in compile_file (name=0xbfffec80 "/tmp/cc4BaZdo.i")
    at toplev.c:3425
#9  0x80513b6 in tree_cons (purpose=0x9, value=0xbfffe984,
chain=0xbfffe9ac)
    at tree.c:2077
#10 0x400339cb in ?? ()

The trick is that loop calls abort() does anyone have any clue when this
happens and why? This will hopefully point me in a direction of a fix.

One more thing. I get the core dump only when I run "make", running
"make bootstrap" hangs the system and I have to push reset, which of
course is not the preferred way to shutdown the machine.

Help is appreciated.

Thanks,
Robert

--
Robert Schweikert                      MAY THE SOURCE BE WITH YOU
rjschwei@mindspring.com                         LINUX

Re: Not the memory

[Martin v. Loewis]

> How do I run gcc in the debugger? 

Run gcc with -v to see how subprocesses are invoked. Add --save-temps
so no temporary files will be used. Then run the subprocess that
crashed in gdb.

> Are the debugging symbols generated automatically when gcc is built,
> this would seem kind of odd as it would inflate the code.

Yes, it is built with debugging information. It doesn't inflate the
code segment, only the total object size.

Regards,
Martin

Re: Not the memory

[Victor]

Correction: try GDB

Re: Not the memory

[Victor]

You are not alone, I have the same thing. I tried to compile new gcc and
kernel on RH6.2 and got signal 11 all the time. I installed TurboLinux and
I haven't had a single problem since. My hardware is this: MVP4 chipset by
via running AMD K6-2 500 cpu. I went through two sticks of ram (both of
which work) but neither worked with RH6.2

My install of RH6.2 had the gcc 2.91.66 compiler and I think that's what
was causing the problem. TurboLinux has no problems and I had no problems
compiling either 2.2.16 or 2.4.0-test2 kernel.

If you find a solution to this problem, please email me as well. I think it
is either the compiler or some libraries the compiler uses that cause this.
However this crashing of linux more resembles windows than it does linux,
don't it? Random errors and noone has an explanation for it. I have posted
two three linux newsgroups and no answer on what is the source. I
constantly hear that Signal 11 is a hardware problem but my hardware works
fine under TurboLinux, OpenBSD, and Windows. So it seems to only "break"
under RH6.2

As was suggested, you can try GCC (and if you do, please post what you
find) but I have no clue as to how exactly to run this so that you get some
sensible result.

Victor

Robert Schweikert wrote:

> Even after successfully building GDB and Motif, both pretty large
> compiles I was starting to buy into the memory problem thing for not
> being able to build gcc, but well its not. I put in a new memory stick
> and low and behold still get my sig 11 when building gcc-2.95.2.
>
> Any one have any ideas on this? I am running RH6.2 on a dual PII system
> with 128 MB RAM and installed the 2.95 gcc release from the RH contrib
> area?
>
> Thanks,
> Robert
> --
> Robert Schweikert                      MAY THE SOURCE BE WITH YOU
> rjschwei@mindspring.com                         LINUX

Re: Not the memory

[Robert Schweikert]

Martin,

How do I run gcc in the debugger? Are the debugging symbols generated
automatically when gcc is built, this would seem kind of odd as it would
inflate the code.

Your help is appreciated.

Robert

"Martin v. Loewis" wrote:

> > Even after successfully building GDB and Motif, both pretty large
> > compiles I was starting to buy into the memory problem thing for not
> > being able to build gcc, but well its not. I put in a new memory stick
> > and low and behold still get my sig 11 when building gcc-2.95.2.
> >
> > Any one have any ideas on this?
>
> The definitive approach for determining a cause of a sig 11 is to use
> a debugger. Run the compiler (or whatever program crashes) in a
> debugger, and find out why it crashes.
>
> Regards,
> Martin

--
Robert Schweikert                      MAY THE SOURCE BE WITH YOU
rjschwei@mindspring.com                         LINUX

Re: Not the memory

[Martin v. Loewis]

> Even after successfully building GDB and Motif, both pretty large
> compiles I was starting to buy into the memory problem thing for not
> being able to build gcc, but well its not. I put in a new memory stick
> and low and behold still get my sig 11 when building gcc-2.95.2.
> 
> Any one have any ideas on this?

The definitive approach for determining a cause of a sig 11 is to use
a debugger. Run the compiler (or whatever program crashes) in a
debugger, and find out why it crashes.

Regards,
Martin

Not the memory

[Robert Schweikert]

Even after successfully building GDB and Motif, both pretty large
compiles I was starting to buy into the memory problem thing for not
being able to build gcc, but well its not. I put in a new memory stick
and low and behold still get my sig 11 when building gcc-2.95.2.

Any one have any ideas on this? I am running RH6.2 on a dual PII system
with 128 MB RAM and installed the 2.95 gcc release from the RH contrib
area?

Thanks,
Robert

--
Robert Schweikert                      MAY THE SOURCE BE WITH YOU
rjschwei@mindspring.com                         LINUX