Jak znaleźć przyczynę zakończenia aplikacji?

Aby wystąpił mój problem potrzebuję:

• ekranu dotykowego (klikanie myszką nie powoduje problemu, musi być dotyk)
• włączonego skórowania aplikacji za pomocą "alphaskins" (wyłączenie SkinManager1.active := false powoduje ze problem nie wystepuje)
• znerwicowanego użytkownika który szybko klika palcami (czas pomiędzy kliknięciami musi być krótszy niż to czas trwania procedury onClick)

Użytkownik kilka "Zapisz obraz" (trwa to około 800ms) zanim się zakończy operacja , klika ponownie i ponownie , proces znika !
Eurekalog niczego nie zgłasza , aplikacja niczego nie zgłasza , jak klikam myszka to wszystko działa OK , tylko dotyk sprawia problemy

Na debuger Delphi (remote debuger przez TCP/IP) ten problem nie występuje, mogę klikać 10 minut i zawsze działa OK
Na GDB też ten problem nie występuje , jak uruchomie program przez GDB to co prawda procesor trochę bardziej obciążony ale aplikacja działa poprawnie, na razie jest to moje wyjście awaryjne uruchomić program gdb -ex run ./program.exe

Nie mam zielonego pojęcia dlaczego proces znika !

Jakieś pomysły ?

Adamek Adam napisał(a):

Nie mam zielonego pojęcia dlaczego proces znika !

Jakieś pomysły ?

Jeden, ale nie z gatunku fire-and-forget...

Proces znika?
Normalnie działa, a nagle znika bez żadnego wyjątku?

Błąd przepełniania stosu tj. StackOverflow tak właśnie się zachowa.
A najłatwiej takiego babola popełnić nieskończoną rekurencją.

Nie wiem co tam dokładnie się dzieje u ciebie, ale program w trybie debug zawsze działa "wolniej".
I może przez to wolniej nie masz problemów?
Występuje jakiś timeout, który powoduje, ze kod zachowuje się ciut inaczej i problem nie występuje.

wloochacz napisał(a):

Adamek Adam napisał(a):

Nie mam zielonego pojęcia dlaczego proces znika !

Jakieś pomysły ?

Jeden, ale nie z gatunku fire-and-forget...

Proces znika?
Normalnie działa, a nagle znika bez żadnego wyjątku?

Dokładnie tak

Ten sam projekt działał (i działa) do tej pory bez problemów tylko na trochę innej platformie,
sytuacja na rynku półprzewodników wymusiła zmianę procesora , to wymusiło zmianę komputera oraz zmianę Windowsa10 z wersji 1607 na 21H2
nowy po lewej: http://cpuboss.com/cpus/Intel-E3940-vs-Intel-Atom-E3845

Zauważyłem jeszcze jeden ciekawy efekt:
Moja aplikacja jest wyświetlana na cały ekran !
Jak mam uruchomione okno eksploratora Windows pod aplikacją i użytkownik wyświetla kolejne okno (też na cały ekran) to na chwile przebija się okno eksploratora Windows (na chwile mignie okno które jest pod aplikacją choć ja nie ukrywam głównego okna)
Jak uruchomię przez GDB.EXE to nie ma tego efektu.

I jeszcze jeden:
Czasami jak wyświetlam nowe okno po przez chwile widzę że są pozbawione skórki , i dopiero po chwili rysują się prawidłowo
Jak uruchomię przez GDB.EXE to nie ma tego efektu.

Eksperymentowałem:

• zmieniłem wersje Alphaskin z 14 na 16
• przetestowałem alternatywę dla Eurekalog: madexcept
• zainstalowałem nowsze sterowniki do karty graficznaj intel
  Nic nie pomoglo

Jakoś mam wrażenie że to coś na linii nowy procesor i skórki ;)
Na żadnym innym komputerze nie ma tego efektu

Zmiana procesora robi zmianę. Ja kiedyś latami budowałem i uruchamiałem aplikację (okienkową VCL) na desktopie z AMD Ryzen i wszystko było cacy. Któregoś dnia kupiłem dziecku na naukę zdalną laptop z Intel Core. Pomyślałem że uruchomię na tym. No i ku mojemu zdziwieniu na laptopie leci NPE w konstruktorze potomka TWinControl. Konstruktor nie jakiś banalny, z triggerowaniem eventów VCL więc nie stricte sekwencyjny. Debugger działał i prostym fixem było dodanie w pewnym miejscu null checka dla jednej zmiennej. Dlaczego tak się działo na tym Intelu to nie wiem. Ale widać że zmiana procesora spowodowała jakieś zmiany w zachowaniu internals VCL a co za tym idzie sekwencyjność kodu używającego tej zmiennej się zmieniła. Oczywiście nie mam pewności że to dokładnie wina innego procesora ale tak obstawiam. Wszystko to działo się na Windows 10 i Delphi 10.4.

@Adamek Adam kompilujesz program 32bit czy 64bit ?
Trop z procesorem może być trafny, osobiście też miałem podobne przeboje ale to wiele lat temu gdy miałem uruchomić oprogramowanie napisane w Delphi na komputerku przemysłowym IEI z procesorem Geode z systemem windows xp... programy nawet się nie uruchamiały. Był jedynie jakiś komunikat którego już nie pamiętam :/
Jedyni pomysł jaki mi na chwilę obecną przychodzi do głowy po podmiana FastMM-a na FastMM4-AVX
https://github.com/maximmasiutin/FastMM4-AVX

U mnie też świat komputerów przemysłowych ,
Aplikacja 32bit (Delphi 2010) , projekt jest przystosowany do budowy na wyższych wersjach tylko że jestem niechętny zmianom jak już działa ,
ale pójdę tym tropem i sprawdzę wersję w najnowszym IDE

A co mam wlaczyc w FastMM4Options.inc "FastMM4-AVX" tak aby nie błądzić ?

Jest kolejna podpowiedz , jak aplikacja znika to ExitCode = 0xCFFFFFFF

Wyniki googla sugerują "STATUS APPLICATION HANG" a to prowadzi mnie do strony
Preventing Hangs in Windows Applications

I rzeczywiście aplikacja chwile przez zniknięciem wygląda jakby sie na chwile zawiesiła

Na razie najskuteczniejsze lekarstwo to podniesienie Delphi do 10.4 , aplikacja nie zamyka z ExitCode = 0xCFFFFFFF ale pojawiło się kilka nowych "ciekawych" problemów np.
do wprowadzania tekstu używam klawiatury dotykowej wbudowanej w Windows, i ta klawiatura z nieznanych powodów sama się ukrywa po wprowadzeniu jednego znaku