Beim Kompilieren mit dem gcc-Compiler in der ESP32 IDF IDE bekomme ich gelegentlich folgenden Compilerfehler: C:/Users/Fritz/esp/v5.3.2/esp-idf/components/esp_lcd/rgb/esp_lcd_panel_r gb.c: In function 'rgb_panel_draw_bitmap': C:/Users/Fritz/esp/v5.3.2/esp-idf/components/esp_lcd/rgb/esp_lcd_panel_r gb.c:800:1: internal compiler error: Segmentation fault 800 | } | ^ Er scheint sich an der schließenden Klammer zu stören. Allerdings handelt es sich um ein File aus der Bibliothek LVGL, an dem ich nichts geändert habe. Außerdem tritt der Fehler nur sporadisch auf, nach einem Neustart der Compilation funktioniert es wieder. Was ist das für ein Fehler?
Moin, Fritz G. schrieb: > Was ist das für ein Fehler? Es ist - wer haette das gedacht - ein interner Compilerfehler. Kann passieren, wenn der Compiler einen Bug hat, oder - viel wahrscheinlicher - wenn die HW, auf der der Compiler laeuft, irgendwie schwindelig ist, also z.B. wackeliges RAM oder sowas... Gruss WK
Ich würde den Fehler eher bei/in deinem Arbeits-PC vermuten. Als Erstes mal testen, ob das Problem auf einer andere Maschine reproduzierbar ist.
Wenn dieser Fehler nicht reproduzierbar ist, und vielleicht sogar jedesmal an einer anderen Stelle auftritt, tippe ich eher auf einen Fehler des PCs.
Unter Windows auch gerne mal ein wild gewordener Virenscanner....
NB: Es gab auch schon einen CPU-Fehler, der bekannt wurde, weil er grosse Compiler-Jobs, wie beim Linux-Kernel, abnippeln liess. Wenn genug RAM in der Kiste steckte. Konnte ich reproduzieren.
:
Bearbeitet durch User
Wenn der Fehler auftritt, dann immer genau an der gleichen Stelle. Das schließt einen Hardwaredefekt des PC eigentlich aus, also ein Fehler im Compiler?
Fritz G. schrieb: > Wenn der Fehler auftritt, dann immer genau an der gleichen Stelle. Das > schließt einen Hardwaredefekt des PC eigentlich aus Nein. Teste am besten erstmal Deinen Speicher, z.B. mit memtest86+.
Fritz G. schrieb: > Das schließt einen Hardwaredefekt des PC eigentlich aus, also ein Fehler > im Compiler? Stutzig macht, dass du selbst schreibst, dass es nur gelegentlich auftritt. Wenn es mit dem gleichen Input (Sourcecode, Compileroptionen) stets an der gleichen Stelle auftritt – also auch beispielsweise direkt nach einem Reboot deines Computers, dann sieht es tatsächlich nach Compilerfehler aus. Um den repariert zu bekommen, müsstest du ihn aber für andere reproduzierbar machen können. Dann lohnt es sich, einen Bugreport einzureichen. Der muss aber den vollständigen (präprozessierten) Quellcode und die notwendigen Compileroptionen beinhalten.
Fritz G. schrieb: > Was ist das für ein Fehler? Ein segmentation fault ist ein Zugriff auf einen unerlaubten Speicherbereich. LG, Sebastian
Jörg W. schrieb: > Um den repariert zu bekommen, müsstest du ihn aber für andere > reproduzierbar machen können. Dann lohnt es sich, einen Bugreport > einzureichen. Der muss aber den vollständigen (präprozessierten) > Quellcode und die notwendigen Compileroptionen beinhalten. GCC kann den Preprozessor-Output erzeugen, dann läßt sich der Fehler mit einer einzigen Datei, die man dann an das Bug-Ticket anhängen kann, reproduzieren. Das setzt natürlich voraus, dass es sich dabei nicht um eine Uralte Version von GCC handelt.
Torsten R. schrieb: > Das setzt natürlich voraus, dass es sich dabei nicht um > eine Uralte Version von GCC handelt. Soll ja der in der ESP IDF mitgelieferte sein.
Fritz G. schrieb: > C:/Users/Fritz/esp/v5.3.2/esp-idf/components/esp_lcd/rgb/esp_lcd_panel_r gb.c:800:1: > internal compiler error: Segmentation fault > 800 | } > | ^ > > Er scheint sich an der schließenden Klammer zu stören. Nein. Es wird eben nur keine richtige Diagnostic ausgegeben. Alles was man daraus schlussfolgern kann ist, dass das Problem irgendwo beim Compilieren der genannten Funktion auftritt. > Was ist das für ein Fehler? Kann ein Problem im Compiler sein und wenn der Host ein ein Problem hat. Wirklich genaueres kann man nur sagen wenn man den Compiler (also cc1, cc1plus oder lto1) debugged. Einen ersten Hinweis erhälst du mit -v -Q -fdump-tree-all -fdump-ipa-all -fdump-rtl-all und Lesen der Dumps :-) Bzw. was ist das letzte Dumpfile, das noch erstellt wird.
Eine weitere Möglichkeit, der Hardware eines Rechners auf den Zahn zu fühlen, ist der Stresstest von "Prime95" vom GIMPS-Projekt (https://www.mersenne.org/download/). Wenn dort (oft bereits nach wenigen Sekunden bis Minuten) Fehler gemeldet werden, weißt Du, dass der PC ein Stabilitätsproblem hat. Hat man das ganze eine paar Stunden erfolgeich laufen lassen, dann kann man recht sicher sein, dass es nicht an der Hardware liegt. Hat mir bereits bei Rechnern geholfen, bei denen Memtest kein Problem fand. Manchmal ist ein PC gerade so an der Grenze zur Instabilität, dass man es im Alltag kaum jemals merkt, aber unter Last komische Dinge passieren.
Stefan R. schrieb: > Manchmal ist ein PC gerade so an der Grenze zur Instabilität, dass man > es im Alltag kaum jemals merkt, aber unter Last komische Dinge > passieren. Es gibt ja Leute, die auf Speichermodule von 3rd-Party-Assemblierern vertrauen, weil die halt günstiger sind als richtige. Früher, als die c't noch eine Computerfachzeitschrift war, haben die sich des Phänomens mal angenommen und den sehr passenden Begriff "RAMsch" dafür geprägt. Lang' ist's her, spätestens seit der feindlichen Übernahme der Redaktion durch einen früheren "BILD"- und "Spiegel-Social-Media"- »Journalisten« ist da aber eh' komplett Hopfen und Malz verloren.
Stefan R. schrieb: > Manchmal ist ein PC gerade so an der Grenze zur Instabilität, dass man > es im Alltag kaum jemals merkt, aber unter Last komische Dinge > passieren. Und ein esp-Progrämmchen compilieren ist „Last“? Oliver
Ich glaub nicht so richtig an einen PC/RAM Fehler. Bei PC Fehlern hatte ich meist bei mehreren Applikationen Probleme. Kennst du folgenden Bugreport: https://github.com/espressif/esp-idf/issues/12180 Probier mal den Workaround in https://github.com/espressif/esp-idf/issues/12180#issuecomment-2949466062
:
Bearbeitet durch User
Harald K. schrieb: > Früher, als die c't noch eine Computerfachzeitschrift war, haben die > sich des Phänomens mal angenommen und den sehr passenden Begriff > "RAMsch" dafür geprägt. > > Lang' ist's her, spätestens seit der feindlichen Übernahme der Redaktion > durch einen früheren "BILD"- und "Spiegel-Social-Media"- »Journalisten« > ist da aber eh' komplett Hopfen und Malz verloren. Du verdrehst aber auch Tatsachen wie dir es passt. Du meinst sicherlich Torsten Beeck, der ab 1.4.25 Chefredakteur bei c't ist. Das ist aber weder der große Chef von der c't noch vom heise Verlag. Zudem es mehrere Chefredakteure bei der c't gibt. Das bedeutet, alles was du dir zusammengereimt hast, ist Unsinn. Die Einzigste Zustimmung die du von mir bekommst ist, dass das Niveau des heise Verlages schon über Jahre fällt. Also die unzähligen online News Artikel muss man leider auch schon mit Vorsicht genießen und die korrigierenden Kommentare lesen. Nur darf man wiederum nicht den Fehler machen, die c't Redaktion mit dem heise Verlag in einen Topf zu werfen. Die c't gehört zum heise Verlag. Ja. Aber die c't Redakteure schreiben nicht den Müll im Heft, welche die heise Leute in den News schreiben. Das zu trennen fällt schwer, weiß ich, nur muss man es trennen können.
Veit D. schrieb: > Du verdrehst aber auch Tatsachen wie dir es passt. Beeck ist schon seit 2023 Chefredakteur, und nicht nur von der c't, sondern auch von "c't Fotografie" und "Mac & i", und vor allem von "heise online". Außerdem ist er in der Chefredaktion von Heise Medien für die inhaltliche Ausrichtung, Produktentwicklung und publizistische Leitlinien verantwortlich. (Quelle: Wikipedia). Ich "verdrehe" also keine Tatsachen; interessant ist allerdings, wieso Du mir das unterstellst. Könnte es sein, daß Du da aus irgendwelchen Gründen eine persönliche Agenda hast?
Hallo, na warum unterstelle ich dir sowas? Weil meine Quelle mir etwas anderes gesagt hatte. Oder denkst du ich antworte zum Spass? Was das mit einer persönlichen Agenda zu tun haben soll weiß ich nicht. Jeder der provokante Texte verfasst, muss mit Antworten bzw. Reaktionen rechnen. Es ist noch einfacher. Einfach jeder der irgendwas sagt, schreibt muss mit Reaktionen bzw. Kritik rechnen. Erst habe ich dich kritisiert. Danach hast du mich kritisiert. Ganz einfach. Jetzt ist es aber so, dass ich mich von einer Werbeeinblendung habe in die Irre leiten lassen. https://kress.de/news/beitrag/145149-torsten-beeck-uebernimmt-chefredaktion-von-c-t-juergen-rink-verlaesst-das-haus.html Das war mit der erste Treffer in der Suchmaschine. Im Text steht nur der 1.April ohne Jahresangabe. Die Werbeeinblendung ist von 2025. Deswegen dachte ich, es wäre erst ab diesem Jahr geschehen. Ich nehme hiermit alles zurück was Torsten Beek betrifft. Nicht was c't vs. heise Verlag angeht.
:
Bearbeitet durch User
Klaus H. schrieb: > Probier mal den Workaround in > https://github.com/espressif/esp-idf/issues/12180#issuecomment-2949466062 Was jetzt genau davon.
1 | set_source_files_properties(${CMAKE_SOURCE_DIR}/components/esp_lcd/rgb/esp_lcd_panel_rgb.c PROPERTIES HEADER_FILE_ONLY TRUE) |
oder Herabsetzen des Compiler optimization levels?
Alexander schrieb: > Klaus H. schrieb: >> Probier mal den Workaround in >> https://github.com/espressif/esp-idf/issues/12180#issuecomment-2949466062 > > Was jetzt genau > davon.1set_source_files_properties(${CMAKE_SOURCE_DIR}/components/esp_lc d/rgb/esp_lcd_panel_rgb.c > PROPERTIES HEADER_FILE_ONLY TRUE) > oder Herabsetzen des Compiler optimization levels? Probiers doch einfach aus. Oliver
Ich nutze das nicht. Notepadqq und Arduino IDE haben bisher gereicht. Wüsste auch gar nicht wo man das ändert.
:
Bearbeitet durch User
Wenn du das Problem gar nicht hast, brauchst du auch nichts zu ändern.
Wenn doch, wirds für dich halt schwierig, weil
> Wüsste auch gar nicht wo man das ändert.
Oliver
Alexander schrieb: > Ich nutze das nicht. Notepadqq und Arduino IDE haben bisher gereicht. > Wüsste auch gar nicht wo man das ändert. Hast Du das gleiche Problem wie der TO Fritz G? Der nutzt allerdings die ESP32 IDF IDE. Hast du tatsächlich das gleiche Problem? Keine Ahnung wie das unter der Arduino IDE geht, aber da findet sich sicher was über entsprechende Internetsuchen.
Klaus H. schrieb: > Hast du tatsächlich das gleiche Problem? Nein. Ich habe kein Problem. Ich habe mir den Link durchgelesen. Da sind mehrere "Lösungen" genannt u.a. Temp Verzeichnis löschen. Ich glaube aber nicht an einen Fehler im Code.
Alexander schrieb: > Nein. Ich habe kein Problem. Ah, OK. Das kam so nicht rüber. > Da sind mehrere "Lösungen" genannt u.a. Temp Verzeichnis löschen. > Ich glaube aber nicht an einen Fehler im Code. Der Beitrag zeigt, dass es vermutlich nicht an einem individuellen PC Problem liegt, darauf wollte ich raus. Die Vorschläge sind keine Lösungen, dass sind Workarounds, die vielleicht helfen, den Effekt vorerst zu beheben bis der ursprüngliche Fehler erkannt und behoben ist. > Ich glaube aber nicht an einen Fehler im Code. Kann ein Fehler im Code, im Compiler, in anderen Tools sein. Egal. Durch einfaches Ausprobieren der Vorschläge sieht man, ob das Problem damit vorerst beherrschbar wird.
Alexander schrieb: > Ich glaube > aber nicht an einen Fehler im Code. Das ist natürlich kein Fehler im Code, sondern tatsächlich mal ein Fehler im Compiler. Denn selbst wenn es fehlerhafter C-Code wäre, darf der nicht abstürzen. Oliver
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.