Meldung - Speicherzugriffsfehler

[Eugenex]

Hallo Liebe Debianer,

nach der ersten Heilung meines EEE1000H Notebooks (2GB RAM) erschienen neue Symptomen:

Code: Alles auswählen

[   23.281395] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready (habe ich ausgeschaltet)
[  306.800845] perf interrupt took too long (2525 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
[  550.688491] perf interrupt took too long (2529 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
[  693.219850] a.out[946]: segfault at 2 ip b75dd127 sp bf86d758 error 4 in libc-2.22.so[b7562000+1b1000]
[  712.084884] perf interrupt took too long (5029 > 5000), lowering kernel.perf_event_max_sample_rate to 25000

Für die Ausführung sonstiger Anwendungen gibt es nichts auszusetzen. Soweit ich kleine sebstgeschribene Shell-Skripte bzw. C-Programme mit ./a.out starte, spuckt der Rechner einen Speicherzugriffsfehler aus ohne output-Ausgabe. Am stationaren PC (mit 1,6 GB RAM) verläuft alles problemlos.

Hat jemand von euch gleiches Erlebnis? Wie läßt sich dieses Problem lösen. Kann ich Speicherprozess rekonfigurieren?

Viele Grüße
Eugenex

[wanne]

Ich würde sagen 99.9% da ist ein Fehler im C programm. Sprich undefined behaviour.
kannst du das mal posten?

[Eugenex]

Ich würde sagen 99.9% da ist ein Fehler im C programm. Sprich undefined behaviour.
kannst du das mal posten?

Aber gerne:

Code: Alles auswählen

#include<stdio.h>

int addiere(int summand1, int summand2) {
	return (summand1 + summand2);
}

int main() {
	int summe = addiere(3, 7);
	printf("Summe von 3 und 7 ist %d\n", summe);
	return 0;
}

Sogar mit dem Beispiel
Und es ist nur mit EEE Asus!

[dufty2]

Und was sagt

Code: Alles auswählen

$ strace ./a.out

?

[Eugenex]

Und was sagt

Code: Alles auswählen

$ strace ./a.out

?

bash: trace: Kommando nicht gefunden!

Und was besagt die Zeile [ 693.219850] a.out[946]: segfault at 2 ip b75dd127 sp bf86d758 error 4 in libc-2.22.so[b7562000+1b1000]

[dufty2]

Das Teil heisst "strace" und nicht "trace"

ip und sp sind die instruction- und stackpointer und die anderen die (virtuellen) Adressen.

[Eugenex]

Das Teil heisst "strace" und nicht "trace"

ip und sp sind die instruction- und stackpointer und die anderen die (virtuellen) Adressen.

Hey dufty2, ich gab zuerst strace ./a.out ein, dann dachte ich mir, vlt. hast du dich verschrieben, und mit trace versuchte.

Auf jedem Fall ist im System etwas beschädigt, denn davor lief alles

[dufty2]

yo, denke ich auch, dass es nicht am Programmcode selber liegt, sondern am gcc, linker, links zu den dynamischen Bibliotheken, whatever.

[wanne]

bash: trace: Kommando nicht gefunden!

Man sollte annehmen das ein C Programmeier strace kennt.
Sonst sollte auch sonst jeder der irgend wie die Finger nach Testing steckt von selbst auf die Idee kommen, dass da ein apt-get install strace hilft.

Wie kompilierst du denn?
Kannst du auch mal das hergeben.

Code: Alles auswählen

env
gcc prog.c
ldd ./a.out

[Eugenex]

Man sollte annehmen das ein C Programmeier strace kennt.
Sonst sollte auch jeder, der irgend wie die Finger nach Testing steckt von selbst auf die Idee kommen, dass da ein apt-get install strace hilft.

Wie kompilierst du denn?
Kannst du auch mal das hergeben.

Code: Alles auswählen

env
gcc prog.c
ldd ./a.out

Danke dufty2, danke wanne, dann installiere ich strace dazu.

Wanne, bis jetzt habe ich zu einem geschriebenem Programmchen gcc prog.c eingegeben und a.out erzeugt.
Dann ./a.out prog.c eingegeben & ENTER.

Bei Shell-Ausführung: bash KOMI-Alphabet-Konv.sh - um die Datenbeschriftung in Komi-Sprache zu konvertieren.
Welche Option kannst du mir bei Shell empfehlen?

Danke für denn Tipp mit apt-get install strace

[MSfree]

Ich kann mir nicht vorstellen, daß auf dem System eine Bibliothek defekt ist. Das simple Programm oben benötigt nur zwei shared Libraries (linux-vdso und libc), die von praktisch jedem Executable auf dem System auch benötigt werden, so daß, sollte eine der beiden Libs defekt sein, auch die bash und eigentlich auch der ganze Bootvorgang schon abstürzen müßte.

Meinem Bauchgefühl nach ist da eher der Hauptspeicher defekt. Ich würde mal memtest86 installieren und laufen lassen.

[Eugenex]

Meinem Bauchgefühl nach ist da eher der Hauptspeicher defekt. Ich würde mal memtest86 installieren und laufen lassen.

Danke MSfree, da bin ich mir ganz sicher, denn bereits Bootvorgangs sehe ich am Bildschirm drm Blöcke mit Prüfsumme failed.

[Eugenex]

Beitrag gelöscht!

[Eugenex]

Beitrag gelöscht!

[wanne]

Das Programm, das du da gepostet hast war das definitiv nicht.

printf(int a);

Ist definitiv falscher C Code.
Kannst du nochmal ein strace mit einem uns bekannten Programm hergeben?
Kaputter RAM hätte sich garantiert schon beim Booten geäußert, wenn der so zuverlässig abkackt.
PS: Du nutzt schon ein ganz normales Debian Testing?

Ansosnten: Das Problem liegt in der datei:
/lib/i386-linux-gnu/i686/cmov/libc.so.6
Das ist die i686 Version der libc. Nicht die i386 Version.
Kannst du mal testen, ob gcc gegen die gleiche Datei linkt?

Code: Alles auswählen

ldd /usr/bin/gcc

Und zur Sicherheit: Kannst du mal schauen ob das ein i686 Prozessor ist? (Wobei es sonst wohl ein illegal Instruction gegeben hätte.)

Code: Alles auswählen

cat /proc/cpuinfo | grep flags | head -1

Damit wird da sicher sind, dass das auf die libc-2.22.so linkt:

Code: Alles auswählen

ls -l /lib/i386-linux-gnu/i686/cmov/libc.so.6

Und zu Letzt: Kannst du mal das machen:
Aber wie gesagt. Bitte mit einem Programm, wo der Sourcecode bekannt ist. (z.B. das oben.)

Code: Alles auswählen

./a.out 1>&2 
strace ./a.out > /dev/null 

[dufty2]

Code: Alles auswählen

user@Debian:~/Dokumente/Programmierung/C-Programmierung/integer$ gcc int.c 
int.c: In function ‘main’:
int.c:9:9: error: expected expression before ‘int’
  printf(int a);
         ^
user@Debian:~/Dokumente/Programmierung/C-Programmierung/integer$

Naja, dass bricht mit "error" ab, also darf es gar kein "a.out" mehr geben.
Daher erst mal "a.out" löschen.
Dein oben gezeigtes Proggi kompiliert bei mir selbst mit

Code: Alles auswählen

gcc -Wall -pedantic -std=c11 prog.c

[NAB]

Eugenex, ergänzend zu wanne ... du richtest da ein ziemliches Durcheinander an ...

1) $ ./a.out Hello_Word.c
Hier rufst du das kompilierte Programm "a.out" auf, mit dem Dateinamen "Hello_Word.c" als Übergabeparameter. Warum? Was soll das Programm mit dem Dateinamen?

2) int.c:9:9: error: expected expression before ‘int’
Hier schlägt das Kompilieren fehl. Du erzeugst also kein neues Programm "a.out". Danach startest du aber trotzdem ein "a.out". Irgendein altes, man hat keine Ahnung welches, aber es scheint defekt zu sein.

3) Welche Debian-Version ist überhaupt installiert? i386 oder amd64? Dein Laptop müsste locker amd64 können.

[dirk11]

Kann den thread mal bitte jemand hier wegschieben? Mit "Problemen bei der Installation von Debian" hat das nun wirklich nichts zu tun.

[Eugenex]

Code: Alles auswählen

user@Debian:~$ ldd /usr/bin/gcc
	linux-gate.so.1 (0xb7781000)
	libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb771a000)
	libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7562000)
	/lib/ld-linux.so.2 (0x800d8000)
user@Debian:~$ cat /proc/cpuinfo | grep | head -1
Aufruf: grep [OPTION]... MUSTER [DATEI]...
„grep --help“ liefert weitere Informationen.
user@Debian:~$ ls -l /lib/i386-linux-gnu/i686/cmov/libc.so.6 
lrwxrwxrwx 1 root root 12 Apr  9 21:58 /lib/i386-linux-gnu/i686/cmov/libc.so.6 -> libc-2.22.so

user@Debian:~/prog$ gcc prog.c 
user@Debian:~/prog$ ./a.out prog.c 
Hello Programm!

user@Debian:~/prog$ ./a.out 1 > &2
bash: Syntaxfehler beim unerwarteten Wort `&'
user@Debian:~/prog$ ./a.out 1 > /dev/null
user@Debian:~/prog$ gcc -Wall -pedantic -std=c11 prog.c
user@Debian:~/prog$ 

Das Integer-Beispiel läßt sich nicht mehr mit gcc kompilieren außer einfachem "Hello Welt" Beispiel.
Mein Asus EEE ist 1,6GHz 32-Bit Prozessor mit einem Kern (zwei simuliert) und 2GB DDR2.
Ja, ich nutze eine i386 Testing-Version! Debian 9
Am stationarem PC wird alles korrekt ausgeführt, auch mit Testing!

Ähnliches berichteten mir meine Kommilitonen.

[dufty2]

Der cpuinfo-Befehl von wanne war nicht ganz korrekt, probier mal

Code: Alles auswählen

$ cat /proc/cpuinfo | grep "model name"

Dein "prog.c" hat er jetzt ja scheinbar kompiliert und auch ausgeführt,
weiss allerdings nicht, warum Du immer ein "prog.c" mit anhängst bei "./a.out".

Bei korrekter Ausführung sollte der Rückgabewert Null betragen, also testen z. B. so:

Code: Alles auswählen

$ ./a.out
Hello Programm!

$ echo $?
0
$

[NAB]

Tatsache ... dadrin soll ein Intel Atom N270 stecken, der ist von 2009 und kann trotzdem kein 64Bit ... unglaublich.

Code: Alles auswählen

user@Debian:~/prog$ gcc prog.c
user@Debian:~/prog$ ./a.out prog.c
Hello Programm!

user@Debian:~/prog$

Hier geht's doch. Problem verschwunden?

Und das "prog.c" in der zweiten Zeile ist immer noch überflüssig, außer du hast einen guten Grund dazu. Welchen?

[dufty2]

Tatsache ... dadrin soll ein Intel Atom N270 stecken, der ist von 2009 und kann trotzdem kein 64Bit ... unglaublich.

Das ist ganz und gar nicht unglaublich (wenn's denn stimmt, aber das werden wir ja dann am output der cpuinfo-Zeile sehen).
Denn die frühen Atoms konnten wirklich kein 64 bit, erst der N450 kann es, welcher im Eee PC 1005 ein Jahr später (2010) auf dem Markt kam.

[NAB]

(duffy2, der 64Bit Atom 330 kam 2008, aber das Thema will ich hier nicht vertiefen )

[wanne]

Ich gebe auf. Solange es nicht mal funktioniert, dass du die Kommandos richtig kopierst, hast du an Testing eigentlich sowieso nichts zu suchen.

Code: Alles auswählen

>&2

Leitet nach stderr um.
Das dagegen ist einfach kaputte Syntax:

Code: Alles auswählen

> &2

Den Sorcecode von einem Programm, das nicht funktioniert haben wir immer noch nicht. Genasusowenig wie eine passende Ausgabe von strace.
Möglicherweise ist der RAM kaputt. Vielleicht auch die Datei libc-2.22.so. Wahrscheinlich aber auch keins von beidem.

Wie schon angemerkt kannst du den RAM mit memtest86 mal überprüfen.
Falls der meckert weißt du wo dein Problem liegt.
Sonst wäre auch mal die HDD interessant Kannst du dir mal angucken mit den smartmontools:

Code: Alles auswählen

smartctl --all /dev/sda

Sollte beides keine Fehler bringen würde ich sage: Installier dir mal ein Debian Stable dann reden wir weiter.

[Eugenex]

Den Testing nutze ich nur wegen gewissen Features und noch anderen Vorteils-Gründen.
Alles Speichermedien des Rechners waren in Ordnung. Ich hätte es schließlich beim Ausführen anderer Anwendungen entdeckt.
Auf 1>&2 kommt es nicht an
Morgen lasse ich das Gerät an die Experten-Hände, den gcc-Kompiler und die Konfiguration zu kontrollieren, was wirklich los ist.
Und ich berichte es zurück.