mikrocontroller.net

Forum: PC-Programmierung Stack corruption, aber valgrind und asan finden nichts, was kann ich noch tun?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Daniel A. (daniel-a)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe wiedermal einer dieser Fehler...  Im Grunde habe ich alle 
möglichen Fehlerursachen bereits ausgeschlossen, also könnte das Problem 
wieder überall sein.

Die Funktion, die im eigentlichen Programm nicht tut, was sie soll, habe 
ich mal direkt isoliert in einem Minimalprogramm aufgerufen, mit den 
gleichen Daten, und dort kommt das erwartete Resultat raus. Aber im 
richtigen Programm, wird eine if Bedingung ausgeführt, dessen Bedingung 
ich direkt vorher und nachher ausgebe, und die mit den werten eigentlich 
nicht ausgeführt werden dürfte. Der generierte Assemblercode im 
Minimalprogramm und im richtigen Programm ist der selbe. Da ich eine 
Form von Stack Korruption vermutete, habe ich Valgrind und ASAN darüber 
laufen lassen. Diese haben absolut nichts gefunden. Nur ein paar 
bekannte memory leaks in der curses library, aber absolut nichts in 
meinem Programm. Ich kompiliere es auch noch mit -fstack-protector-all, 
das hat auch nichts bemerkt. Der Fehler ist relativ robust, immerhin 
haben ein paar printf ausgaben ihn nicht verändert.

Ich bin mit meinem Latein gerade etwas am ende, was kann ich noch 
versuchen?

Ich sehe den Fehler im in der Funktion "tym_i_pane_set_cursor_position", 
bei der Zeile "if(y >= bottom)":
https://github.com/Daniel-Abrecht/libttymultiplex/blob/work-in-progress/src/pane.c#L320

Die debug ausgaben in Fehlerfall, die so eigentlich nicht möglich sein 
dürften, sind:
scroll_region_valid: false origin_mode: false
ox->x: 0 0 oy->y: 2 -1
sr top: 0 sr bottom: 59
1 ax: 0 ay: 1
top: 0 bottom: 59
2 ax: 0 ay: 1
!!!: 1 59 -57
tym_i_scroll_def_scrolling_region t 0 b 59 h 59 n -57
fx: 0 fy: 58

Wie an der Ausgabe zu erkennen ist, wurde der Ausdruck (y >= bottom) mit 
y=1 und bottom=59 irgendwie als wahr ausgewertet...

Das Minimalprogram liefert die erwartete Ausgabe:
scroll_region_valid: false origin_mode: false
ox->x: 0 0 oy->y: 2 -1
sr top: 0 sr bottom: 59
1 ax: 0 ay: 1
top: 0 bottom: 59
2 ax: 0 ay: 1
fx: 0 fy: 1

Die library verwende ich dabei mit folgendem Programmen:
https://github.com/Daniel-Abrecht/console-keyboard-multiplexer
https://github.com/Daniel-Abrecht/console-keyboard-basic

Der Fehler tritt auf, wenn "console-keyboard-multiplexer bash -l" 
aufrufe, und dann in dem Programm "echo -e '\e[1A'" ausführe, das wird 
in "parser.c" geparst, der ruft dann die "tym_i_csq_cursor_up", und die 
wiederum ruft die "tym_i_pane_set_cursor_position" auf, in der das 
Problem sichtbar wird.

Das Minimalprogram, in dem der Fehler, in dem das Problem nicht 
auftritt, und ein disassembly mit gcc der relevanten Funktion, ist im 
Anhang, aber ich glaube nicht, das dort das Problem liegt.

Was kann ich jetzt noch versuchen, um dem Fehler auf die Schliche zu 
kommen?

Autor: Kaj (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel A. schrieb:
> Was kann ich jetzt noch versuchen, um dem Fehler auf die Schliche zu
> kommen?
Wenn es ein Coredump gibt, dann da mal mit gdb reingucken.
Einmal cppcheck ueber das Projekt laufen lassen und das ganze mal mit 
clang und sanitizer-Optionen compilieren und dann ausfuehren.

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaj schrieb:
> Daniel A. schrieb:
>> Was kann ich jetzt noch versuchen, um dem Fehler auf die Schliche zu
>> kommen?
> Wenn es ein Coredump gibt, dann da mal mit gdb reingucken.

Leider stürzt es nicht ab, sonst könnte ich mit dem Debugger schauen ws 
passiert. Es werden soweit ich sehe auch keine Variablen unerwartet 
überschrieben, sonst könnte ich das mit einem watchpoint im debugger 
weiter analysieren. Ich sehe nur den einen Seiteneffekt, wo an der einen 
stelle eine Bedingung ausgeführt wird, wenn sie nicht ausgeführt werden 
sollte.

> Einmal cppcheck ueber das Projekt laufen lassen

OK, Ich werde das heute Abend mal ausprobieren, mal seen ob das Tool mit 
meinem Codestyle umgehen kann. Es ist zwar (abgesehen von der Verwendung 
von weak und constructor attributen) gültiger C99 Code, aber einige 
Funktionen werden auf eine art und weise referenziert und angesprungen, 
die es für Tools schwierig machen kann zu erkennen, dass diese überhaupt 
verwendet werden, und andere Funktionen werden mit einem weak Symbol 
referenziert, werden aber nur aufgerufen nach einer Überprüfung ob diese 
auch tatsächlich existieren, was nicht immer der Fall ist. Bin schon 
gespannt, wie das Tool darauf reagiert.

> und das ganze mal mit clang und sanitizer-Optionen compilieren und dann
> ausfuehren.

Gute Idee. Clang nutzt zwar auch ASAN, aber andere Compiler und Optionen 
können natürlich andere Probleme finden und das Fehlerbild ändern. Falls 
ich das Programm so dazu bringen kann, nach der eigentlichen 
Problemursache gleich abzustürzen, dann hätte ich wieder einen 
Ansatzpunkt.

Autor: Oliver S. (oliverso)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne da groß in die Details eingestiegen zu sein, hilft vielleicht das 
hier weiter:

https://blog.regehr.org/archives/268

Oliver

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Ohne da groß in die Details eingestiegen zu sein, hilft vielleicht das
> hier weiter:
>
> https://blog.regehr.org/archives/268

Danke, dass ein Vergleich "((long)-1) > ((unsigned)1)" auf einigen 
Architekturen das "falsche" Resultat liefern kann, wusste ich nicht. Das 
muss ich bei mir im Code definitiv korrigieren. Eigentlich hab ich beim 
Kompilieren "-Wall -Wextra -pedantic -Werror" mitgegeben, aber der gcc 
scheint mir in letzter zeit recht unzuverlässig damit, Warnungen zu 
generieren.

Den Fehler, den ich Sehe, erklärt es aber trotzdem nicht. Ganz egal, wie 
der Compiler "((long)1) >= ((unsigned)59)" implizit castet, das dürfte 
trotzdem nie wahr sein, und im Minimalbeispiel tut es an der Stelle 
auch, was ich erwarten würde. Der vergleich ist ja kein UB, sondern nur 
im Standard Scheisse definiert.

Autor: CppBert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
auf jeden Fall einen aktuellen GCC 8 oder besser 9 mit UBSan probieren
die Warnungen/Prüfungen werden ja staendig verbessert, auch mal den 
clang probieren - moeglicherweise veraendert sich dein Fehlerbild 
dadurch

Autor: Daniel A. (daniel-a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cppcheck 1.76.1 hab ich nun drüber laufen lassen. Eine Funktion, die ich 
falsch benannt habe, habe ich mit dessen unused function information 
gefunden und noch ein paar Kleinigkeiten korrigiert:
https://github.com/Daniel-Abrecht/libttymultiplex/commit/609f4ee014d3df1e4ba6446e9b08ac4ac8e5b947

Ansonsten findet cppcheck jetzt selbst mit den "--enable=all 
--inconclusive" Optionen nichts mehr, abgesehen von ein paar unused 
Funktion Warnungen und ein paar "Redundant assignment of 'X' to itself" 
Warnungen, wo cppcheck die designated initialiser der form "(S){.a=a}" 
nicht richtig interpretiert. Die momentane Ausgabe ist im Anhang.

Die Debugausgabe hat sich geändert, die macht jetzt Sinn:
ox->x: 0 0 oy->y: 2 4294967295
sr top: 0 sr bottom: 59
1 ax: 0 ay: 4294967297
top: 0 bottom: 59
2 ax: 0 ay: 4294967297
!!!: 4294967297 59 4294967239
tym_i_scroll_def_scrolling_region t 0 b 59 h 59 n -57
fx: 0 fy: 58

Wie da vorher -1 statt 4294967297 zustande kam ist mir schleierhaft. Der 
Fehler ist in der cursor_up Funktion, und genauso vermutlich auch noch 
in ein paar anderen Funktionen. Muss ich jetzt korrigieren.

Damit wäre die Ursache klar. Mein Fehler war das bei so was hier:
void test(long x){
  printf("%ld\n", x);
}

int main(){
  unsigned a = 1;
  test(-a);
  return 0;
}
Ein unsigned integer underflow auftritt.

Einen schlechten Beigeschmack hat es trotzdem noch, ich weiss noch 
nicht, wie es zur ursprünglichen Ausgabe kommen konnte. Das kommt sicher 
irgendwann wieder zurück...

Compilieren mit clang 6 bringt auch keine Warnungen. UBsan und ASan hab 
ich damit jetzt aber nicht ausprobiert.

Wie auch immer.
Danke an alle, das Problem ist gelöst.

Autor: Kaj (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na siehste mal. Wieder mit einem einfachen Tool den Code besser gemacht 
und wieder was dazu gelernt. :)
Freut mich das wir helfen konnten.

Gruesse

Autor: Daniel A. (daniel-a)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ok, eine Sache wäre da doch noch... gcc 6.3.0 und clang 6.0.0 mit 
"-std=c99 -Wall -Wextra -pedantic -Werror", aber auch cppcheck 1.76.1 
haben bei den unsigned vs signed vergleichen und den integer underflows 
komplett versagt, mich zu warnen. Gibt es ein Tool, welches da etwas 
zuverlässiger ist?

Edit: Und hier auch noch die im letzten Beitrag vergessene momentane 
cppcheck Ausgabe.

: Bearbeitet durch User
Autor: Heiko L. (zer0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel A. schrieb:
> Compilieren mit clang 6 bringt auch keine Warnungen. UBsan und ASan hab
> ich damit jetzt aber nicht ausprobiert.

Die hätten vermutlich auch nichts gefunden, da es kein UB ist. Die 
-Wconversion Familie wäre wohl eher das richtige gewesen.

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Heiko L. schrieb:
> Daniel A. schrieb:
>> Compilieren mit clang 6 bringt auch keine Warnungen. UBsan und ASan hab
>> ich damit jetzt aber nicht ausprobiert.
>
> Die hätten vermutlich auch nichts gefunden, da es kein UB ist. Die
> -Wconversion Familie wäre wohl eher das richtige gewesen.

Gerade mal mit gcc 8.3.0 und "-Wconversion -Wall -Wextra -pedantic 
-Werror" folgendes Programm kompiliert:
#include <stdio.h>

void test(long x){
  printf("%ld\n", x);
  unsigned bla = 1;
  if(x >= bla)
    printf("test\n");
}

int main(){
  unsigned a = 1;
  test(-a);
  return 0;
}

Keine Warnung, nichts! Ich meine, klar, technisch gesehen ist das nicht 
falsch, das -a wird nicht zu einem signed int durch das minus, und der 
unsigned int kann sich nicht ändern, wenn er implizit in einen auf der 
Architektur grösseren long konvertiert wird, und UB ist es auch nicht, 
usw.  Aber trotzdem were es schön, wenn man da irgendwie gewarnt werden 
könnte...

Autor: Heiko L. (zer0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DPA schrieb:
> Keine Warnung, nichts!

Clang warnt an der Stelle auf 64bit Plattformen, was aber eigentlich ein 
Fehler zu sein scheint. gcc warnt mit Wconversion auch auf einer 32-bit 
Plattform nicht, was ebenso ein Fehler ist.
Nur msvc gibt schon mit Wall sogar Warnungen, wie du sie gerne hättest.

https://godbolt.org/z/5aZUai

Man könnte also sagen, dass das schon ginge, wenn nicht....

: Bearbeitet durch User
Autor: cppbert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was sagt UBSan?

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DPA schrieb:
> Oliver S. schrieb:
>> Ohne da groß in die Details eingestiegen zu sein, hilft vielleicht das
>> hier weiter:
>>
>> https://blog.regehr.org/archives/268
>
> Danke, dass ein Vergleich "((long)-1) > ((unsigned)1)" auf einigen
> Architekturen das "falsche" Resultat liefern kann, wusste ich nicht.

Es ist praktisch immer eine schlechte Idee, signed und unsigned zu 
mischen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.