Der Fehler im Titel dieses Postings erscheint bei mir
IMMER UND IMMER WIEDER!!
Bei ganz normalen Befehlszeilen (Zuweisungen, die 100% okay sind!) und einfach so…
Hat jemand einen Tipp für mich!
Biiiiiiiittttttttteeeeeeeeeeeee…
Dankeschön
Euer Alexander
NACHTRAG
Compilieren geht ohne Probleme, erst beim Ausführen erscheint dieser Fehler!
Und ich arbeite mit dem g+±Compiler unter Linux!
So, jetzt müsste ich alles angegeben haben…
Hi Alex 
Ein Segmentation fault passiert immer genau dann, wenn ein Programm auf einen Speicherbereich zugreifen möchte, der ihm nicht gehört! Mit anderen Worten, irgendwas muss mit deinen Speicherzugriffen (Variablenzuweisungen, Variablenabfragen, …) schiefgehen.
Viele Grüße
Stefan.
Hi Alex
Ein Segmentation fault passiert immer genau dann, wenn ein
Programm auf einen Speicherbereich zugreifen möchte, der ihm
nicht gehört! Mit anderen Worten, irgendwas muss mit
deinen Speicherzugriffen (Variablenzuweisungen,
Variablenabfragen, …) schiefgehen.
Also mein Programm läuft zunächst!
Dann füge ich in den Main-Teil einfach die Zeile:
int prozentWert;
ein und schon erscheint dieser Fehler!
Wie das? Die Variable wurde noch nie verwendet und hat keinen Namen, den es schon für einen Befehl oder so gibt???
Komisch, oder???
Grüße und ein dickes HILFE!
Alexander
Viele Grüße
Stefan.
Zwei Varianten:
Dein Speicher ist defekt, so dass die Variablenadressen
verbogen werden.
Du greifst auf ein Array ausserhalb des Definitionsbereichs zu
(evtl. Strings?). Da immer „glatte“ Grenzen bei
Speicheranforderungen erzeugt werden, kann das in der ersten
Version harmlos sein, da noch ein paar Bytes uebrig sind, in der
zweiten, wo eine zusaetzliche Variable eingefuegt wird, zu einer
Speicherverletzung fuehren.
„3. Dein Computer wird intelligent“
Deine Freunde sind strace, um zu sehen, was an Systemaufrufen
passiert, und ddd (als nettes GUI zu gdb).
Ciao Lutz
Zwei Varianten:
- Dein Speicher ist defekt, so dass die Variablenadressen
verbogen werden.
Ich habe ja in meinem ziemlich umfangreichen Programm schon die verschiedensten Variablen deklariert! Warum will er dann diese eine nicht???
- Du greifst auf ein Array ausserhalb des Definitionsbereichs
zu
(evtl. Strings?). Da immer „glatte“ Grenzen bei
Speicheranforderungen erzeugt werden, kann das in der ersten
Version harmlos sein, da noch ein paar Bytes uebrig sind, in
der
zweiten, wo eine zusaetzliche Variable eingefuegt wird, zu
einer
Speicherverletzung fuehren.
Das klingt interessant, ich versteh’s aber nicht ganz! Ich benutze verschiedene Arrays, das stimmt! Und wie ist das dann…??
„3. Dein Computer wird intelligent“
Hä? Wie das?
Deine Freunde sind strace, um zu sehen, was an Systemaufrufen
passiert, und ddd (als nettes GUI zu gdb).
strace?
ddd?
wie benutze ich diese? noch nie gehört! sorry 
Ciao Lutz
Thanx a lot!
strace?
ddd?
wie benutze ich diese? noch nie gehört! sorry
Bei einem segmentation fault tippe ich auf *x, dann
man strace
und fuer ddd (data display debugger) mal eine Suchmaschine
anwerfen. Ist u.a. in den Redhat Powertools enthalten.
Ciao Lutz
Segmentation fault (STRACE)
Bei einem segmentation fault tippe ich auf *x, dann
man strace
Folgendes erscheint bei Benutzung von STRACE :
(Würde mich über eventuelle Tipps freuen)
execve("./pi01", ["./pi01"], [/\* 47 vars \*/]) = 0
brk(0) = 0x805143c
open("/etc/ld.so.preload", O\_RDONLY) = -1 ENOENT (No such file or directory
open("/etc/ld.so.cache", O\_RDONLY) = 4
fstat(4, {st\_mode=S\_IFREG|0644, st\_size=34866, ...}) = 0
old\_mmap(NULL, 34866, PROT\_READ, MAP\_PRIVATE, 4, 0) = 0x40014000
close(4) = 0
open("/usr/lib/libstdc++-libc6.1-2.so.3", O\_RDONLY) = 4
fstat(4, {st\_mode=S\_IFREG|0555, st\_size=1227181, ...}) = 0
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\247"..., 4096) =
old\_mmap(NULL, 4096, PROT\_READ|PROT\_WRITE, MAP\_PRIVATE|MAP\_ANONYMOUS, -1, 0) =
old\_mmap(NULL, 293928, PROT\_READ|PROT\_EXEC, MAP\_PRIVATE, 4, 0) = 0x4001e000
mprotect(0x40058000, 56360, PROT\_NONE) = 0
old\_mmap(0x40058000, 49152, PROT\_READ|PROT\_WRITE, MAP\_PRIVATE|MAP\_FIXED, 4, 0x
old\_mmap(0x40064000, 7208, PROT\_READ|PROT\_WRITE, MAP\_PRIVATE|MAP\_FIXED|MAP\_ANO
close(4) = 0
open("/lib/libm.so.6", O\_RDONLY) = 4
fstat(4, {st\_mode=S\_IFREG|0755, st\_size=525421, ...}) = 0
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220F\0"..., 4096) = 4
old\_mmap(NULL, 117688, PROT\_READ|PROT\_EXEC, MAP\_PRIVATE, 4, 0) = 0x40066000
mprotect(0x40082000, 3000, PROT\_NONE) = 0
old\_mmap(0x40082000, 4096, PROT\_READ|PROT\_WRITE, MAP\_PRIVATE|MAP\_FIXED, 4, 0x1
close(4) = 0
open("/lib/libc.so.6", O\_RDONLY) = 4
fstat(4, {st\_mode=S\_IFREG|0755, st\_size=4070406, ...}) = 0
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\214"..., 4096) = 4
old\_mmap(NULL, 929308, PROT\_READ|PROT\_EXEC, MAP\_PRIVATE, 4, 0) = 0x40083000
mprotect(0x4015e000, 32284, PROT\_NONE) = 0
old\_mmap(0x4015e000, 20480, PROT\_READ|PROT\_WRITE, MAP\_PRIVATE|MAP\_FIXED, 4, 0x
old\_mmap(0x40163000, 11804, PROT\_READ|PROT\_WRITE, MAP\_PRIVATE|MAP\_FIXED|MAP\_AN
close(4) = 0
munmap(0x40014000, 34866) = 0
getpid() = 931
brk(0) = 0x805143c
brk(0x805145c) = 0x805145c
brk(0x8052000) = 0x8052000
gettimeofday(NULL, NULL) = 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
> gettimeofday(NULL, NULL) = 0
> --- SIGSEGV (Segmentation fault) ---
> +++ killed by SIGSEGV +++
man gettimeofday
error conditions: beide Pointer muessen gueltig sein, auch wenn
der zweite nicht benutzt wird. Hier zeigen beide auf NULL, was
garantiert ungueltig ist. Jetzt musst Du „nur“ noch gucken, wo
die Uhrzeit abgefragt wurde.
Ciao Lutz
PS: Meine Kristallkugel laesst befuerchten, dass das im Programm
gar nicht vorkommt. Das waere dann richtig kompliziert.
Hey Alexander!
Bei einem Segmentation fault, greift man immer auf Speicher zu,
der einem nicht gehört.
Das fällt dem Programm aber nicht sofort auf.
Es kann ihm irgendwann auffallen, oder gar nicht.
Wenn Du einfach eine Variable neu deklarierst, organisiert dein Programm den Speicher neu.
Das bedeutet, es kann sein, dass die Speicherverletzung erst
durch die Deklaration der neuen Variablen erkannt wird.
Normalerweise erzeugt dein Programm beim Absturz einen core.
Hast Du den Core mit einem debugger analysiert?
Wenn der Stack im core zerstört ist, hilft es nur noch print Zeilen einzufügen. Dann sieht man grob, wo das Programm abschmiert.
Und dann Code review
Sind beim compilieren alle warnings aktiviert?
Gruß Stefan
man gettimeofday
error conditions: beide Pointer muessen gueltig sein, auch
wenn
der zweite nicht benutzt wird. Hier zeigen beide auf NULL, was
garantiert ungueltig ist. Jetzt musst Du „nur“ noch gucken, wo
die Uhrzeit abgefragt wurde.
ich weiss, wo die uhrzeit aufgerufen wird, aber der einzige aufruf dens gibt, ist laut quelltext „okay“!! shit…
Ciao Lutz
PS: Meine Kristallkugel laesst befuerchten, dass das im
Programm
gar nicht vorkommt. Das waere dann richtig kompliziert.
is auch so schon kompliziert genug! gruß an die kristallkugel (darf mir gerne helfen…