Crashujący się FPC

0

Ostatnio zacząłem dosyć sporo poprawiać w moim kompilatorze (na ten moment jestem w trakcie kończenia implementacji control-flow graph i paru innych rzeczy ;>) i zauważyłem, że im więcej kodu dodaję, tym częściej FPC się crashuje - aktualnie wygląda to tak, że jeżeli nie wykonam czystej całkowitej kompilacji (Lazarusowe Shift+F9), kończy się to komunikatem Compilation aborted

Ręczne wywołanie z konsoli:
ppc386 compiler.lpr -Fututajjestmasaścieżek -FUlib\ -Mobjfpc
Ujawnia:

Free Pascal Compiler version 2.6.3 [2013/06/21] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling compiler.lpr
Compiling CompilerUnit.pas
Compiling .\compiler\cfgraph.pas
Compiling .\compiler\symdef.pas
Compiling .\compiler\parser.pas
Compiling Opcodes.pas
Compiling .\compiler\Compile1.pas
Compiling .\compiler\Compile1.pas
Compiling .\compiler\Compile1.pas
Compiling .\compiler\Compile1.pas
Compiling .\compiler\Compile1.pas
Compiling .\compiler\Compile1.pas
Compiling .\compiler\Compile1.pas
Compiling .\compiler\Compile1.pas
Compiling .\compiler\Compile1.pas
Compiling .\compiler\Compile1.pas
Compiling .\compiler\Compile1.pas
Compiling .\compiler\Compile1.pas
Compiling .\compiler\Compile1.pas
Compiling .\compiler\Compile1.pas
Compiling Compile2.pas
Compile1.pas(632,45) Warning: Comment level 2 found
Compile1.pas(633,3) Warning: Comment level 2 found
Compile1.pas(1116,2) Warning: Comment level 2 found
Fatal: Compilation aborted
An unhandled exception occurred at $00462D10 :
EAccessViolation : Access violation
  $00462D10  TSTOREDDEF__IS_INTREGABLE,  line 1348 of symdef.pas
  $0045748E  TABSTRACTVARSYM__SETVARDEF,  line 1196 of symsym.pas
  $00457187  TABSTRACTVARSYM__DEREF,  line 1064 of symsym.pas
  $00457A81  TABSTRACTNORMALVARSYM__DEREF,  line 1311 of symsym.pas
  $00436D80  TSTOREDSYMTABLE__DEREF,  line 570 of symtable.pas
  $0046743D  TABSTRACTPROCDEF__DEREF,  line 3243 of symdef.pas
  $00436D24  TSTOREDSYMTABLE__DEREF,  line 563 of symtable.pas
  $0046B218  TOBJECTDEF__DEREF,  line 4664 of symdef.pas
  $00436D24  TSTOREDSYMTABLE__DEREF,  line 563 of symtable.pas
  $0043935F  TSTATICSYMTABLE__PPULOAD,  line 1485 of symtable.pas
  $0052A555  TPPUMODULE__LOAD_USEDUNITS,  line 1403 of fppu.pas
  $0052AB25  TPPUMODULE__LOADPPU,  line 1599 of fppu.pas
  $0052A1AD  TPPUMODULE__LOAD_USEDUNITS,  line 1312 of fppu.pas
  $0052AB25  TPPUMODULE__LOADPPU,  line 1599 of fppu.pas
  $0053356C  LOADUNITS,  line 815 of pmodules.pas
  $005337C6  PARSE_IMPLEMENTATION_USES,  line 877 of pmodules.pas
  $005345CD  PROC_UNIT,  line 1249 of pmodules.pas

(czysta (pierwsza) kompilacja (gdy katalog wyjściowy lib/ jest pusty) zawsze przechodzi ok, dopiero, gdy zaczyna wczytywać pliki *.ppu następuje crash)
Błąd występuje we wszystkich trzech wersjach, które sprawdzałem, tj.: 2.6.2, 2.6.3 i 2.7.1 (ostatnie dwie kompilowałem lokalnie u siebie prosto z dzisiejszego repo FPC).

Niezbyt jestem w stanie zgłosić ten błąd (ponieważ nie istnieje w mniejszej skali...), niezbyt jestem w stanie to poprawić, a poważnie utrudnia mi on dalsze pisanie - rekompilowanie za każdym razem całości jednak trochę trwa, stąd tutaj moje pytanie: co teraz powinienem zrobić (tzn.poza czekaniem na naprawę tego bugu, przyjmując, że team FPC o nim wie :P)?
Staram się odnaleźć mimo wszystko dokładniejszy powód błędu oraz ręcznie grzebać w kodzie Free Pascala, lecz póki co bezowocnie ;C

@-123oho, masterze FPC, oraz wszyscy inni: liczę, że pomożecie ;>


Btw, jakby co, to jestem w stanie podesłać ten aktualny kod, który crashuje kompilator (nie zacommitowałem go na GitHuba póki co).
1

@-123oho, masterze FPC, oraz wszyscy inni: liczę, że pomożecie ;>

Zgłaszałem ten błąd na bugtrackerze, związany zapewne on jest z tym, że FPC crashuje się przy tworzeniu generyków w specyficznych miejscach (Mantis #22671).
2.6.3 - a na co ci ta wersja... Używaj 2.7.1
Jeżeli nie jesteś w stanie zlokalizować błędu, dodaj -B do linii kompilacji :P .
W każdym razie obstawiam na generyki bo tylko w takim wypadku spotkałem się z tym błędem.

0

O! Szybki jesteś ;P

2.6.3 - a na co ci ta wersja... Używaj 2.7.1

Mam złe wrażenia z używania kompilatora w fazie super-mega-alpha, a przy tym dopiero dzisiaj pierwszy raz kompilowałem FPC u siebie, ponieważ wcześniej nie miałem potrzeby zaglądania do ich repo, stąd korzystałem wyłącznie z 2.6.


Czyli przynajmniej tyle, że jest to zgłoszone - póki co pozostaje więc rekompilować całość za każdym razem oraz próbować naprawić na własną rękę (co z moją znajomością internalsów FPC spali na panewce na samym początku, ale mniejsza z tym ;p).
0

O! Szybki jesteś ;P

Miałeś farta, boty mnie pojechały w pewnej grze ;)

Mam złe wrażenia z używania kompilatora w fazie super-mega-alpha

Ta... 2.7.1 już jest od ponad roku... I jeżeli ktoś robi wydanie to to zazwyczaj kwestia zmiany numerku :> Generalnie to chyba nie spotkałem się z sytuacją że wersja z SVN miała jakieś problemy czy z kompilacją czy z plikami wynikowymi, ale to zależy jak często się buduje FPC a ja generalnie korzystam z parumiesięcznych 2.7.1 z moimi poprawkami.

(co z moją znajomością internalsów FPC spali na panewce na samym początku, ale mniejsza z tym ;p).

Na budowie kompilatora też się nie znam (moim największym sukcesem jest rozpoznanie że procedura w której raz się wykładał FPC to procedura odpowiadająca za wskazywania rozmiaru operandu assemblera), natomiast RTL lekko ogarniam (przynajmniej na tyle żeby poprawić błąd heapa w DLLkach którego FPCteam nie chciał poprawić i teraz nie chce dodać :P ).

Czyli przynajmniej tyle, że jest to zgłoszone - póki co pozostaje więc rekompilować całość za każdym razem oraz próbować naprawić na własną rękę

W bugu który ci pokazałem jest i przykład i obejście bodaj. Kwestia poszukania - przydać ci się może to że FPC będzie przebudowywać tylko te unity które się zmieniły - więc łatwo możesz wykryć który unit jest winowajcą a potem poprawić deklaracje. Ew. włącz pokazywanie ładowanych plików i będziesz wiedzieć jakie pliki ppu są nie tak.
Co do naprawy to w naprawę wątpię - tylko jedna osoba na świecie tak na prawdę wie jak działają (twórca generyków w FPC) i jeszcze są one dalekie od stabilności, w sumie zgłosiłem z 3 bugi związane z nimi więc możesz się ustawić w kolejce do napraw.

Btw. ten bug na trackerze mogłeś znaleźć bez pytania: Wystarczyło wpisać dwie pierwsze procedury z GDB w google i znalazło wszystkie 3 bugi w których występował taki backtrace :) . No ale rozumiem że do naprawiania FPC jesteś początkującym jak nie budowałeś 2.7.1 sobie wcześniej.

0

Tak btw, to w tym bugu występuje chyba jakiś race-condition lub coś w tym rodzaju, ponieważ nawet jak pracowałem nad wersją, która aktualnie jest na GitHubie, czasami następowały crashe (nawet, jeżeli nic nie zmieniałem w plikach) i musiałem kilkukrotnie naciskać F9 (ale już nie Shift+F9, tylko po prostu zwyczajną kompilację)...

W bugu który ci pokazałem jest i przykład i obejście bodaj. Kwestia poszukania - przydać ci się może to że FPC będzie przebudowywać tylko te unity które się zmieniły - więc łatwo możesz wykryć który unit jest winowajcą a potem poprawić deklaracje. Ew. włącz pokazywanie ładowanych plików i będziesz wiedzieć jakie pliki ppu są nie tak.

O - to jest pomysł! ;>


Edit: chyba udało mi się odnaleźć przyczynę błędu (poniekąd ;P; spójrz na mój post na Mantisie), zobaczymy co z tego wyniknie ;]
0
Patryk27 napisał(a):

Tak btw, to w tym bugu występuje chyba jakiś race-condition lub coś w tym rodzaju, ponieważ nawet jak pracowałem nad wersją, która aktualnie jest na GitHubie, czasami następowały crashe (nawet, jeżeli nic nie zmieniałem w plikach) i musiałem kilkukrotnie naciskać F9 (ale już nie Shift+F9, tylko po prostu zwyczajną kompilację)...

W moim błędzie powtarzalność błędu była zawsze, ale mój problem był ograniczony do minimum. Być może Lazarus coś miesza w konfiguracji i lubi częściej przebudowywać niektóre pliki. Osobiście wiem że to jak Lazarus buduje projekty jest dziwne, bo zdarzało mi się że mimo zmian w pliku dane dalej były brane z pliku ppu.
Mówienie o race-condition gdy masz ogromny projekt który nie jest tak łatwo ogarnąć jest przedwczesne. Większość błędów które wykrywałem z początku wydawała się losowa ale przy redukcji okazywało się np. że zależnie od wersji crash występował tylko przy danych przełącznikach, albo tylko w bardzo konkretnym przypadku. FPC chyba nie używa wątków przy budowie projektów.

Jeżeli będziesz mieć problem ze znalezieniem błędu to mogę spróbować wyizolować problem jeżeli udostępnisz gdzieś swoje pliki źródłowe+skrypt budujący (just not GitHub, nie mam żadnego softa do tego). Poleganie na Lazarusie w tym wypadku jest dużym błędem, buduj przez skrypt.

0

(just not GitHub, nie mam żadnego softa do tego)

Jest tam u góry taki magiczny przycisk z chmurką (po prawej od "Clone in Windows"), który umożliwia pobranie wszystkiego w formie ładnej paczuszki *.zip, nie potrzeba żadnego dodatkowego softu.
Lecz problem wydaje się być taki, jak opisałeś w Mantisie: deklaracja specjalizacji klasy generycznej wewnątrz procedury kończy się crashem.

Poleganie na Lazarusie w tym wypadku jest dużym błędem, buduj przez skrypt.

Aktualnie już tak robię ;>

0

Jest tam u góry taki magiczny przycisk z chmurką (po prawej od "Clone in Windows"), który umożliwia pobranie wszystkiego w formie ładnej paczuszki *.zip, nie potrzeba żadnego dodatkowego softu.

Widzę że ludzie poszli po rozum do głowy, już się domyślam dlaczego nie mam softa do githuba...

Lecz problem wydaje się być taki, jak opisałeś w Mantisie: deklaracja specjalizacji klasy generycznej wewnątrz procedury kończy się crashem.

No to w takim wypadku powtarzalność powinna być always ;) .

Aktualnie już tak robię ;>

Kolejny krok: Używanie 40+ linikowych skryptów budujących korzystających z FPC z SVN z własnymi poprawkami, pakujących gotowe pliki wynikowe mało znanym packerem oraz własny program który poprawia niezgodność między tym packerem a FPC... :P

1 użytkowników online, w tym zalogowanych: 0, gości: 1