# Segmentation faults: Wodran liegt's?

## NueX

Hallo!

Ich sitze hier vor einem Problem, dass mich seit geraumer Zeit wurmt, naja mehr als wurmt, und kein Ende nehmen will.

Bei der Hardware handelt es sich um einen gut gekühlten PC mit folgenden Hardware-Daten:

```
-Mainboard: Abit NF7-S

  -NForce2 Chipsatz

-CPU: Athlon XP 2600+

-RAM: 2*256MB Infineon PC3200 DDR

-Grafikkarte: ATI Radeon 9600 Pro

-Festplatte: Seagate Barracuda 80GB Festplatte
```

Auffällig waren zuerst unregelmäßige Abstürze unter Windows, dann die Unmöglichkeit Gentoo zu installieren, weil es während des bootstraps immer wieder Segmentation faults gab. Daraufhin habe ich memtest86 eine Nacht durchlaufen lassen, Ergebnis waren am nächsten Morgen 10 Fehler bei 96 Durchläufen, immer in Test 6, aber immer an anderen Stellen des RAMs. Das hat mich etwas gewundert, weil ich dachte, wenn der RAM wirklich hinüber wäre, dann gäbe es sicher zig mehr Fehler. Ich schloss auf Bios-Einstellungen.

Nun habe ich daraufhin im Bios den FSB-Ratio von "Auto" auf "BySPD" gestellt, wieder memtest86 angeschmissen, nach 46 Durchläufen stand er bei 0 Fehlern. Froh über das (scheinbar) gelöste Problem habe ich mich wieder an die Gentoo-Installation (stage1, 2004.0) gemacht und siehe da, es gab keine Segmentation faults während des bootstraps und des "emerge system"s mehr. Nachdem ich die gentoo-dev-sources-2.6.5 erfolgreich konfiguriert und gebootet hatte, wollte ich mich an die Installation von KDE machen.

Nun, an dieser Stelle befinde ich mich noch immer, denn es gibt immer wieder an total unterschiedlichen Stellen (mal nach 3, mal nach 90 Minuten) Segmentation faults in unterschiedlichsten Paketen. Mittlerweile habe ich schon 40 der über 70 Pakete erfolgreich emerged (halt einfach immer wieder den emerge neugestartet und gehofft, dass "es" nicht wieder passiert). Tja, nur irgendwie komme ich nicht über "kdebase" hinaus, irgendwann gibt es (bis jetzt) immer nen Segfault.

Da mich das Verhalten des PCs nun wirklich nicht glücklich macht und ich mit meinem Latein schon am Ende bin, poste ich hier.

Es kann dich wohl gesagt werden, dass es sich anscheinend um einen Hardware-Fehler handelt, weil die Segfaults immer an anderen Stellen beim Kompilieren auftreten, richtig? Wenn es nicht am RAM liegt (memtest86 zeigt schliesslich keine Fehler) wodran kann es dann liegen und wie kann ich Fehler ausräumen? Die CPU ist auch keinesfalls zu heiß, habe mit lm_sensors während des Kompilierens geschaut, die Temperatur liegt bei ~45°C. Liegt es vielleicht an den Memory Timings (stehen auch auf "BySPD")? Oder hat womöglich das Mainboard nen Knacks?

Mich wundert auch sehr, dass es zwischenzeitlich ging (bootstrap und "emerge system" ohne Probleme) und jetzt wieder Komplikationen gibt.

Ich wäre für jede Idee, jeden Tipp und jede Hilfestellung dankbar, soo hat man wirklich keine Freude an dem Computer.

Viele Grüße und Danke für's Lesen,

NueX

P.S.: kdebase läuft schon 25 Minuten, nach meinen Berechnungen bräuchte es 120 Minuten. Vielleicht wird es ja diesmal etwas. [Update: Wieder Segmentation fault, nach 27 Minuten  :Sad:  ]

P.P.S: Weiter Output:

```
# emerge info

Portage 2.0.50-r5 (default-x86-2004.0, gcc-3.3.2, glibc-2.3.2-r9, 2.6.5-gentoo)

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

System uname: 2.6.5-gentoo i686 AMD Athlon(tm) XP 2600+

Gentoo Base System version 1.4.3.13

distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]ccache version 2.3 [enabled]

Autoconf: sys-devel/autoconf-2.58-r1

Automake: sys-devel/automake-1.8.3

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CFLAGS="-march=athlon-xp -mcpu=athlon-xp -O3 -pipe -fomit-frame-pointer"

CHOST="i686-pc-linux-gnu"

COMPILER="gcc3"

[...]

CXXFLAGS="-march=athlon-xp -mcpu=athlon-xp -O3 -pipe -fomit-frame-pointer"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoaddcvs ccache sandbox"

[...]

USE="3dnow X acpi alsa apm arts avi berkdb cdr crypt cups dvd dvdr encode foomaticdb gdbm gif icq imlib java joystick jpeg kde libg++ libwww mad mikmod mmx motif mozilla mpeg ncurses nls oggvorbis opengl pam pdflib perl png python qt quicktime readline scanner sdl slang spell sse ssl svga tcpd truetype x86 xml2 xmms xv zlib"
```

Beispiel:

```
[...]

config.pl: fast created 1 file(s).

make[4]: Leaving directory `/var/tmp/portage/kdebase-3.2.1/work/kdebase-3.2.1/kdeprint/slave/templates'

make[4]: Entering directory `/var/tmp/portage/kdebase-3.2.1/work/kdebase-3.2.1/kdeprint/slave/templates'

make[4]: Nothing to be done for `all'.

make[4]: Leaving directory `/var/tmp/portage/kdebase-3.2.1/work/kdebase-3.2.1/kdeprint/slave/templates'

make[4]: Entering directory `/var/tmp/portage/kdebase-3.2.1/work/kdebase-3.2.1/kdeprint/slave'

/usr/qt/3/bin/moc ./kio_print.h -o kio_print.moc

/bin/sh ../../libtool --silent --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/kde/3.2/include -I/usr/qt/3/include -I/usr/X11R6/include  -D_KDEPRINT_COMPILE -DQT_THREAD_SUPPORT  -D_REENTRANT -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -DNDEBUG -DNO_DEBUG -O2 -march=athlon-xp -mcpu=athlon-xp -O3 -pipe -fomit-frame-pointer -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -D_GNU_SOURCE  -c -o kio_print.lo `test -f 'kio_print.cpp' || echo './'`kio_print.cpp

/bin/sh ../../libtool --silent --mode=link --tag=CXX g++  -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -DNDEBUG -DNO_DEBUG -O2 -march=athlon-xp -mcpu=athlon-xp -O3 -pipe -fomit-frame-pointer -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -D_GNU_SOURCE    -o kio_print.la -rpath /usr/kde/3.2/lib/kde3 -L/usr/X11R6/lib -L/usr/qt/3/lib -L/usr/kde/3.2/lib  -module -avoid-version -module -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined -R /usr/kde/3.2/lib -R /usr/qt/3/lib -R /usr/X11R6/lib  kio_print.lo -lkio -lkdeprint

collect2: ld terminated with signal 11 [Segmentation fault]

make[4]: *** [kio_print.la] Error 1

make[4]: Leaving directory `/var/tmp/portage/kdebase-3.2.1/work/kdebase-3.2.1/kdeprint/slave'

make[3]: *** [all-recursive] Error 1

make[3]: Leaving directory `/var/tmp/portage/kdebase-3.2.1/work/kdebase-3.2.1/kdeprint/slave'

make[2]: *** [all-recursive] Error 1

make[2]: Leaving directory `/var/tmp/portage/kdebase-3.2.1/work/kdebase-3.2.1/kdeprint'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/var/tmp/portage/kdebase-3.2.1/work/kdebase-3.2.1'

make: *** [all] Error 2

 

!!! ERROR: kde-base/kdebase-3.2.1 failed.

!!! Function kde_src_compile, Line 128, Exitcode 2

!!! died running emake, kde_src_compile:make
```

Thanx.

----------

## birnbaumtruhe

Ich würde mal auf RAM tippen. Deine Aussage ist aber allerdings nicht ganz klar.

 *Quote:*   

> Daraufhin habe ich memtest86 eine Nacht durchlaufen lassen, Ergebnis waren am nächsten Morgen 10 Fehler bei 96 Durchläufen, immer in Test 6, aber immer an anderen Stellen des RAMs. Das hat mich etwas gewundert, weil ich dachte, wenn der RAM wirklich hinüber wäre, dann gäbe es sicher zig mehr Fehler. Ich schloss auf Bios-Einstellungen. 

 

bzw.

 *Quote:*   

> Wenn es nicht am RAM liegt (memtest86 zeigt schliesslich keine Fehler) wodran kann es dann liegen und wie kann ich Fehler ausräumen? Die CPU ist auch keinesfalls zu heiß, habe mit lm_sensors während des Kompilierens geschaut, die Temperatur liegt bei ~45°C.

 

Den Fehler den du beschreibst hatte ich damals unter Windows auch. Ich hab dann mein Windows gelöscht und Gentoo installiert und hab insgesamt 6 Anläufte gebraucht bis es auf der Platte war. Als dann jedes Programm gesegfaultet hat dachte ich mir mal ein memtest zu machen und siehe da. RAM eingeschickt und umgetauscht.

P.S.: Möglicherweise von Interesse

https://forums.gentoo.org/viewtopic.php?p=625943&highlight=#625943

https://forums.gentoo.org/viewtopic.php?t=145498&highlight=segmentation+faultsLast edited by birnbaumtruhe on Thu Apr 15, 2004 8:34 pm; edited 1 time in total

----------

## NueX

 *Quote:*   

> Daraufhin habe ich memtest86 eine Nacht durchlaufen lassen, Ergebnis waren am nächsten Morgen 10 Fehler bei 96 Durchläufen, immer in Test 6, aber immer an anderen Stellen des RAMs. Das hat mich etwas gewundert, weil ich dachte, wenn der RAM wirklich hinüber wäre, dann gäbe es sicher zig mehr Fehler. Ich schloss auf Bios-Einstellungen.
> 
> Nun habe ich daraufhin im Bios den FSB-Ratio von "Auto" auf "BySPD" gestellt, wieder memtest86 angeschmissen, nach 46 Durchläufen stand er bei 0 Fehlern. Froh über das (scheinbar) gelöste Problem

 Also: zuerst hatte ich bei memtest86 Fehler, nach der Änderung der Bios-Einstellung hatte ich dort aber keine Fehler mehr. Und trotzdem hab ich die Segfaults. Gehe ich richtig in der Annahme, dass memtest86 zig (hunderte) Fehler zeigen würde, wenn der Ram richtig schrott wäre?

----------

## birnbaumtruhe

Das möchte ich jetzt nicht unterschreiben. Ich hatte persönlich knapp 8000 Fehler in den ersten 256 MB von 1 GB. Ich würde dir einfach raten mal den RAM von einem Freund/Arbeitskollegen, etc. einzubauen und zu sehen wenn dir das mit memtest einfach zu unsicher ist.

----------

## zielscheibe

Zum Stabilitätstest bei Übertaktungsversuchen nutze ich am liebsten prime95 (ftp://mersenne.org/gimps/sprime235.tar.gz). Da es sehr spezifisch die einzelnen Komponenten fordert und Speicher- sowie Prozessorfehler innerhalb einer Stunde aufzudecken vermag, die noch kein OS zum Absturz bringen.

Sollten sich dabei Fehler herausstellen, würde ich an deiner Stelle auch einmal das Netzteil in die nähere Auswahl ziehen. Bei mir reichten die 300 W des Codegens nicht aus, um nach dem Grafikkartenupgrade einen stabilen Betrieb zu garantieren (gleiches Schema wie an deinem System). Vielleicht hast du ja noch eine ältere PCI Grafikkarte rumliegen. Nach einem Austausch sollten spannungsinduzierte Abstürze eigentlich auszuschließen sein.

----------

## NueX

Also ich möchte nun defekten RAM an sich ausschließen, denn ich habe jetzt den RAM einmal komplett durch anderen ersetzt, der 100% OK ist, weil er problemlos in einem andereren Rechner läuft. Es gab aber trotzdem nach sehr kurzer Zeit wieder Segmentation faults.

Zu schwaches Netzteil würde ich jetzt auch erstmal ausschließen, weil in dem Rechner ein 350Watt Enermax Netzteil drinsteckt und im Konsolenbetrieb ja noch nicht einmal 3D Grafik läuft, dass sich die Grafikkarte besonders anstrengen müsste.

Als nächste Schritt habe ich jetzt einmal prime95 installiert und da den Test gestartet, mal schauen, ob er was findet. Noch die Anmerkung: An dem Rechner ist nichts übertaktet!

----------

## tacki

schau dir mal das board genau an, ob ein paar kondensatoren verdächtig nach oben gewölbt sind....

----------

## NueX

Also: Ich habe nun mal über Nacht prime95 auf Windows mit dem Torture Test laufen lassen und es gab keine Fehler:

```
[Fri Apr 16 00:12:26 2004]

Self-test 1024K passed!

[Fri Apr 16 00:29:18 2004]

Self-test 8K passed!

[Fri Apr 16 00:46:45 2004]

Self-test 10K passed!

[Fri Apr 16 01:05:10 2004]

Self-test 896K passed!

[Fri Apr 16 01:23:31 2004]

Self-test 768K passed!

[Fri Apr 16 01:40:06 2004]

Self-test 12K passed!

[Fri Apr 16 01:56:31 2004]

Self-test 14K passed!

[Fri Apr 16 02:15:50 2004]

Self-test 640K passed!

[Fri Apr 16 02:33:03 2004]

Self-test 512K passed!

[Fri Apr 16 02:49:06 2004]

Self-test 16K passed!

[Fri Apr 16 03:06:12 2004]

Self-test 20K passed!

[Fri Apr 16 03:24:27 2004]

Self-test 448K passed!

[Fri Apr 16 03:43:16 2004]

Self-test 384K passed!

[Fri Apr 16 04:01:49 2004]

Self-test 24K passed!

[Fri Apr 16 04:18:39 2004]

Self-test 28K passed!

[Fri Apr 16 04:38:12 2004]

Self-test 320K passed!

[Fri Apr 16 04:56:09 2004]

Self-test 256K passed!

[Fri Apr 16 05:12:29 2004]

Self-test 32K passed!

[Fri Apr 16 05:29:03 2004]

Self-test 40K passed!

[Fri Apr 16 05:49:50 2004]

Self-test 224K passed!

[Fri Apr 16 06:08:07 2004]

Self-test 192K passed!

[Fri Apr 16 06:25:12 2004]

Self-test 48K passed!

[Fri Apr 16 06:42:28 2004]

Self-test 56K passed!

[Fri Apr 16 07:04:07 2004]

Self-test 160K passed!

[Fri Apr 16 07:21:02 2004]

Self-test 128K passed!

[Fri Apr 16 07:38:51 2004]

Self-test 64K passed!

[Fri Apr 16 07:57:39 2004]

Self-test 80K passed!

[Fri Apr 16 08:16:02 2004]

Self-test 112K passed!

[Fri Apr 16 08:34:58 2004]

Self-test 96K passed!

[Fri Apr 16 08:53:29 2004]

Self-test 1280K passed!

[Fri Apr 16 09:11:16 2004]

Self-test 1536K passed!

[Fri Apr 16 09:29:35 2004]

Self-test 1792K passed!

[Fri Apr 16 09:48:51 2004]

Self-test 2048K passed!

[Fri Apr 16 10:10:09 2004]

Self-test 2560K passed!
```

Das ist ja an sich schon mal gut. Ich werde prime95 wohl auch nochmal unter meinem Gentoo laufen lassen, und da das Ergebnis abwarten.

 *tacki wrote:*   

> schau dir mal das board genau an, ob ein paar kondensatoren verdächtig nach oben gewölbt sind....

 Meinst du verformt, d.h. evtl. dass die Abschlussplatten oben drauf gewölbt sind? Also auf den ersten Blick habe ich keine Veränderungen an den Kondensatoren entdeckt.

----------

## zielscheibe

Also ich glaube nicht mehr an einen physikalischen Ramfehler, als Ursache der Segmentation Faults.

Nach etwas Googlen habe ich aber etwas sehr interressantes zu deinem spezifischen Fehler gefunden.

```

 ld terminated with signal 11 [Segmentation fault] 

```

Ich tippe jetzt ganz stark bei deinem System auf einen Harddiskfehler siehe (prime95 greift nicht auf die hdd zu):

http://www.bitwizard.nl/sig11/

QUESTION

Ok it may not be the software, How do I know for sure? 

ANSWER

First lets make sure it is the hardware that is causing your trouble. When the "make" stops, simply type "make" again. If it compiles a few more files before stopping, it must be hardware that is causing you troubles. If it immediately stops again (i.e. scans a few directories with "nothing to be done for xxxx" before bombing at exactly the same place), try 

```

dd if=/dev/HARD_DISK of=/dev/null bs=1024k count=MEGS

```

Change HARD_DISK to "hda" to the name of your harddisk (e.g. hda or sda. Or use "df ."). Change the MEGS to the number of megabytes of main memory that you have. This will cause the first several megabytes of your harddisk to be read from disk, forcing the C source files and the gcc binary to be reread from disk the next time you run it. Now type make again. If it still stops in the same place I'm starting to wonder if you're reading the right FAQ, as it is starting to look like a software problem after all.... Take a peek at the "what are the other possibilities" question..... If without this "dd" command the compiler keeps on stopping at the same place, but moves to another place after you use the "dd" you definitely have a disk->ram transfer problem.

Viel Glück!

----------

## Sas

Ich würde auch fast aufs Board tippen. Kannst ja nochmal ne andere CPU testen, das ist weniger Arbeit, aber ich glaubs nicht wirklich.

----------

## NueX

Ich habe prime95 nochmal testweise unter Linux im "Torture Test" laufen lassen, auch hier (nicht anders als erwartet) keine Fehler:

```
[Sat Apr 17 11:13:56 2004]

Self-test 1024K passed!

[Sat Apr 17 11:28:56 2004]

Self-test 8K passed!

[Sat Apr 17 11:43:56 2004]

Self-test 10K passed!

[Sat Apr 17 11:58:58 2004]

Self-test 896K passed!

[Sat Apr 17 12:14:16 2004]

Self-test 768K passed!

[Sat Apr 17 12:29:16 2004]

Self-test 12K passed!

[Sat Apr 17 12:44:16 2004]

Self-test 14K passed!

[Sat Apr 17 12:59:25 2004]

Self-test 640K passed!

[Sat Apr 17 13:14:33 2004]

Self-test 512K passed!

[Sat Apr 17 13:29:33 2004]

Self-test 16K passed!

[Sat Apr 17 13:44:33 2004]

Self-test 20K passed!

[Sat Apr 17 13:59:33 2004]

Self-test 448K passed!

[Sat Apr 17 14:14:37 2004]

Self-test 384K passed!

[Sat Apr 17 14:29:37 2004]

Self-test 24K passed!

[Sat Apr 17 14:44:38 2004]

Self-test 28K passed!

[Sat Apr 17 14:59:39 2004]

Self-test 320K passed!

[Sat Apr 17 15:14:43 2004]

Self-test 256K passed!

[Sat Apr 17 15:29:43 2004]

Self-test 32K passed!

[Sat Apr 17 15:44:44 2004]

Self-test 40K passed!

[Sat Apr 17 15:59:47 2004]

Self-test 224K passed!

[Sat Apr 17 16:14:52 2004]

Self-test 192K passed!

[Sat Apr 17 16:29:52 2004]

Self-test 48K passed!
```

Ich werde wohl mal einen Athlon Thunderbird 1400 einsetzen und dann nochmal gucken, ob es noch Segfaults gibt.

Sonst probiere ich auch nochmal den Tipp von zielscheibe und melde mich dann mit den Ergebnissen wieder.

Auch ich tendiere dazu, zu vermuten, dass das Mainboard kaputt ist.

----------

## amne

Hier abgespalten:

Toffelsen Installations- und Supportthread

edit: und den Apostrophen aus dem Topic entfernt.  :Wink: 

----------

## NueX

Zum ursprünglichen Thema (wo das hier doch gerade schon aus der Versenkung geholt wurde): Nach langwierigem rumprobieren mit Bios-Updates & Co habe ich mal den Prozessor FSB von 166MHz auf 133MHz gestellt, und siehe da, keine Segfaults mehr. Etwas merkwürdig, vielleicht probiere ich es auch nochmal anders, aber immerhin hat alles schön kompiliert und läuft auch recht nett.

Schöne Grüße, NueX

 *amne wrote:*   

> edit: und den Apostrophen aus dem Topic entfernt. 

 Wieso denn das? Orthografisch wäre das aber richtig...  :Wink: 

----------

## amne

Oh, hoppla.  :Embarassed: 

Ich war mir todsicher dass das falsch ist. Normalerweise habe ich sowieso besseres zu tun als Fehler auszubessern, aber weil ich gerade dabei war... 

Dum di dum.

----------

## lolli78

hallo,

im skandinavischen forum bin ich auf diesen thread gestoßen: https://forums.gentoo.org/viewtopic.php?t=152146

da steht drin, dass amd-prozessoren wohl manchmal schwierigkeiten mit -fomit-frame-pointer haben. ich kann mir zwar nicht vorstellen, an was das liegen soll, da -fomit-frame-pointer eigentlich "nur" das debuggen auf der x86-plattform unmöglich machen soll, aber dem initiator dieses threads hat es geholfen.

vielleicht hilft es dir ja auch.

lorenz

----------

## dangod

Hi,

ich hatte ein aehnliches Problem. Nach mehreren Versuchen habe ich herausgefunden, dass es auch geklappt hat, als ich den Takt heruntergesetzt habe. 

Nach etwas "research" hat es dann aber auch funktioniert mit dem vorgeschlagenem Takt und etwas erhoehter DDR-RAM Spannung +0.1/+0.2 V.

Vielleicht klappts ja  :Wink: 

TschOe mit Oe Daniel

----------

## siliconburner

ich hate mal ein aehnliches problem, und da war das board kaputt, der ramfehler kam immer nur in einem slot. wenn die 166mhz fuer deine hardware cpu und ram richtig sind, solltest du wirklich mal den speicher woanders testen lassen und das board mal mit andrem ram und wennmoeglich auch ner andren cpu testen.

----------

