2010-05-04 22 views
5

Moja instalacja Delphi schodzi z górki przez ostatnie kilka miesięcy. Wydaje się jednak, że co jakiś czas, gdy buduję wydanie, ma on dziwne błędy, które są rozwiązywane, gdy buduję, kompiluję, kompiluję, itd.Delphi 6 - Błędy znikają, gdy kompiluję się wiele razy

Rozmawiałem z innym programistą, który myśli, że to jest błędem kompilatora. Ten rodzaj degradacji wydajności w czasie zdarzył się również na innych komputerach.

Co może powodować problem z przepełnieniem stosu?

+7

Wygląda na to, że nadszedł czas na aktualizację. :) – kludg

+4

Osobiście odkryłem, że z Delphi zawsze lepiej było omijać wydania o numerach parzystych. Wszystkie były kruche. Oczywiście w późniejszych latach zdecydowałem, że dla własnego rozsądku pójdę dalej i pomijam również numery nieparzyste. – NotMe

+1

Jakie "dziwne błędy"? Czy oczekujesz od nas odgadnięcia lub przeczytania twoich myśli? :) – Alex

Odpowiedz

7

co widziałem większość to przypadek, w którym różne wersje tych samych jednostkach/dcus istnieć w różnych folderach/ścieżki, w zależności od prawie nieznacznych wahań kompilator/linker wykorzystuje inną ścieżkę i odbiera różne wersje jednostek zbudować exe.
Zrobiłbym wielkie wiosenne porządki, przyjrzałbym się ścieżkom do biblioteki/wyszukiwania, usunę wszystkie dliki i upewnię się, że nie ma duplikatów żadnej jednostki.
Uzgodnione, ponowne zainstalowanie Delphi może pomóc rozpocząć od czystego stanu.

+0

Jest to bardzo prawdopodobna możliwość. Dcus i komponenty, których używamy, to gigantyczne szczury, które zmutowały w ciągu ostatnich 10 lub więcej lat, a więc aplikacja została opracowana. Są pewne składniki, do których nie mamy nawet źródła, a jedynie skompilowane DCU. Czy masz jakieś zalecenie łatwego sposobu sprawdzenia wielu jednostek/dcus, i czy to wszystko? Jakikolwiek program lub wtyczki? – Daisetsu

+6

@Daisetsu: GAH! Nigdy nie powinieneś KIEDYKOLWIEK używać komponentów DCU! Gdybym był na twoim stanowisku, byłoby to moje następne pytanie StackOverflow: "Jak mogę zastąpić tutaj alternatywą, która ma dostępne źródło, z minimalną trudnością?" –

+1

@Mason: Całkowicie [email protected]: NIGDY nie używaj komponentów bez źródła. Nauczyłem się tego na własnej skórze. –

0

To niewiele, ale brzmi jak klasyczny przypadek "zgnilizny bitów". Zbyt wiele rzeczy na zbyt wiele sposobów wchodzi w interakcje zbyt długo w źle zaprojektowanym systemie operacyjnym, co prowadzi do dziwnych form uszkodzenia danych.

Pierwszą rzeczą, którą zrobię, jest odinstalowanie Delphi i ponowne zainstalowanie. Jeśli to nie pomoże, spróbuj ponownie zainstalować system Windows. (Jeśli działo się to wystarczająco długo, aby tak się stało, prawdopodobnie musisz ponownie zainstalować system operacyjny). Jeśli to nie pomoże, skontaktuj się z pomocą techniczną Embarcadero.

+4

Uważam, że to interesujące, że obwiniasz system operacyjny za problemy w jego kompilatorze, gdy sama Delphi (wiele wersji) ma historię wykazywania tego rodzaju niestabilnego zachowania, podczas gdy inne kompilatory po prostu działają. – NotMe

5

Zgadzam się z @ François na temat DCU, ale także chcę zwrócić uwagę: czasami ważne jest to, co zostało zbudowane przed tym, co budujesz. tzn. jeśli masz kilka projektów zawierających kod źródłowy, który powoduje, że różne pliki .dcu/bpl są tworzone we wspólnym katalogu, ale projekt, którego dotyczysz, nie wymaga jawnego wywoływania ich w repozytorium, skończyć z tym, co tam jest. Jeśli wyczyścisz dcus/dcps przed budowaniem, a potem odkryjesz, że twój projekt nie tworzy, to brakuje ci gdzieś klauzuli uses/require. Każdy projekt powinien być w stanie zbudować "czysty łupek", a nie polegać na resztach plików binarnych.