[Delphi6] Rekenapplicatie crasht willekeurig hele PC

[Reptile209]

Ik ben bezig om voor mijn studie een progje te klussen dat een berg iteratief rekenwerk doet. Van tijd tot tijd gebeurt het me dat tijdens het rekenen mijn PC op standby lijkt te gaan iod: monitor op standby, je hoort de HD's downspinnen. Het lukt me niet om de fout op een bepaald moment te reproduceren.

Voor de chemici onder de lezers: het programma rekent een p-x,y diagram door via de Peng-Robson EOS. Voor de UT-ers: Fasenleer

Eerste ingeving: het ligt aan de belasting van mijn Athlon 1200 (non-oc-d) met Windows 2000 Pro, volledig gepatched. Kan bijna niet, aangezien er al tijdenlang een SoB-client op de achtergrond full-pool aan het rekenen is. Het enige verschil ermee is dat dat een ander prog is dan mijn app.

Voor de liefhebber: Reptile209.zip (24 kB) de (niet voor publicatie aangepaste ) code.

Tweede mogelijkheid: het ligt aan mijn code. Maar waar dan? Korte programmaschets (Delphi 6.0 dus, draaiend in de IDE):

Delphi:

...
procedure TForm1.Button1Click()
begin
  ...
  for n := 1 to 100
  begin  
    ...
    foo1()
    ...
    while (x<.01) do
    begin
      Application.ProcessMessages;
      ...
      bar1()
      ...
      x := foo2()
      ...
    end;
    // Memo1 bijwerken
  end;
end;

• Formpje om wat startwaarden in te voeren
• Een TForm.Button1Click die het volgende doet:
• Een for-lus met daarbinnen een while-lus die moet itereren naar een eindwaarde
• In de while wordt als eerste Application.ProcessMessages aangeroepen om mijn form in leven te houden.
• Vanuit de while worden een paar losse functies aangeroepen die wat rekenwerk verrichten. Niks exotisch: +, -, /, *, exp(), ln(), power() en sqrt(). Kan het power() zijn, omdat ik die anders nooit gebruik en dus nooit eerder een probleem is geweest? Zal nog een versie met een eigen power() proberen, hopen dat dat nog wat uitmaakt.
• Een paar labels tonen wat tussenwaarden
• Steeds als de while-lus klaar is, gaan de resultaten naar een TMemo.

Mijn app maakt géén gebruik van:
• threads (op de standaard TForm na dan he...)
• eigen geheugenallocatie
• pointers (alleen standaard array[1..2] gebeuren, niet eens groot dus)
• Recusieve dingen die het geheugen vol-lellen

Derde optie:
In mijn eventlog staat, nadat alles na mijn harde reset weer draait:

The computer has rebooted from a bugcheck. The bugcheck was: 0x0000000a (0x00000018, 0x000000ff, 0x00000000, 0x8046937c).

Dus eigenlijk een windows/driver probleem. Automatically Reboot staat uit, dus blijkbaar gaat windows over zijn nek bij het afdrukken van een BSOD.
Hoe kan een relatief simpel programma als dit nou een STOP veroorzaken?

Dusss
Waar moet ik in g*dsnaam gaan zoeken naar de oplossing voor dit probleem?
Wordt Application.ProcessMessages te vaak gebruikt (kan dat "te vaak"? Nee toch?) Is er "iets" in Delphi dat random foute code genereert? Toch alleen een driver die onder sommige "omstandigheden" flipt? Toch hardware?

Aaarrrggghh

PS. Ik hoop uit de replies op te kunnen maken dat het idd een Delphi - en dus P&W - probleem is. Zo niet, dan moet ik mijn geluk gaan beproeven in WOS, PM&G of desnoods OH...

[ Voor 10% gewijzigd door Reptile209 op 14-09-2004 00:52 ]

[farlane]

Lijkt me eerder een fout in je hardware of een bug in je systeem die misschien getriggerd wordt door code die je uitvoert.

[Reptile209]

farlane schreef op 13 september 2004 @ 23:43:
Lijkt me eerder een fout in je hardware of een bug in je systeem die misschien getriggerd wordt door code die je uitvoert.

Maar dat is mijn punt juist: ik kan helemaal niets in mijn code vinden dat ook maar vaag in de buurt komt van wat voor hardware dan ook (video daargelaten, maar dan zou ik meer problemen moeten hebben lijkt me). Als ik nou enorm aan het netwerken/geluidsbewerken/cd-branden zou zijn in m'n software, a-la. Maar qua belasting is dit programma net wat complexer dan "Hello World!"...

Edit:
Voor de liefhebber die dit niet meteen van me aanneemt heb ik het geheel even online gezet: Reptile209.zip (24 kB)

[ Voor 16% gewijzigd door Reptile209 op 13-09-2004 23:48 ]

[tharkun]

Wat gebeurt er als je het programma op een andere pc runt? Als het aan je programma ligt zou het dan ook moeten gebeuren.

[Delphi32]

Net gedraaid hier: project in D6 geopend, F9 gedrukt, en knop Start gedrukt. Binnen een paar seconden klaar zonder problemen. Moet ik andere testwaarden invullen?

[Reptile209]

@tharkun: Moet het nog op een andere PC proberen, maar ik weet niet of het dan ook misgaat: ik kan het zelf al niet eens fatsoenlijk reproduceren.

@Delphi32: nee, de waarden maken geen zak uit, die worden (nog) niet eens ingelezen . Dat is voor de finishing touch. Hij hoort ook idd gewoon met een paar seconden/minuten klaar te zijn.

[farlane]

Reptile209 schreef op 13 september 2004 @ 23:45:
Maar dat is mijn punt juist: ik kan helemaal niets in mijn code vinden dat ook maar vaag in de buurt komt van wat voor hardware dan ook (video daargelaten, maar dan zou ik meer problemen moeten hebben lijkt me).

Het kan zijn dat je op jouw systeem met jouw applicatie plotseling bij een geheugenplek komt die kaduuk is, of een bad sector op je harde schrijf of iets in die trend.

[OZ-Gump]

Hier ook even gedowned, in Delphi 7 geopend, op F9 gedrukt en 8 keer op start: 8 keer netjes binnen een paar seconden klaar. Het lijkt dus toch ergens in je PC te zitten.... Misschien een chipje van een geheugenmodule kapot?

Tenzij je in Delphi componenten hebt geïnstalleerd die je originele Delphi source naar de knoppen hebben geholpen.

[heuveltje]

Hier compileert en draait ie ook in 1 keer zonder problemen.
(alleen je vergeet ergens iets te resetten, als ik nog een keer op uitrekenen klik geeft ie invalid fpo. maar dat zal het probleem niet zijn lijkt me)

probeer hem eens zelf te compileren en dan de executable te posten.
als die hier wel draait ligt het aan je pc. crasht ie dan is er ergens een compiler instelling fout lijkt me...

[Reptile209]

Hij wordt nog leuker: als ik 'm draai op mijn PC en die van een huisgenoot (met wat actuele wijzigingen maar wel dezelfde .exe), krijg ik verschillende resultaten:
(wel een zooi kolommen weggelaten omdat die verder niet relevant zijn en alleen de layout vern*ken)

Bij huisgenoot, Celeron 366
en bij andere huisgenoot met een Athlon XP 2200 (ofzo):

code:

Resultaten
                V L O E I S T O F       
x1        fug.(1)   fug.(2)   comp.z    
0.000    0.000786   4.373435  0.019924  
0.040    3.084543   4.257432  0.032826  
0.080    6.048907   4.142088  0.045286  
0.120    8.892419   4.027439  0.057300  
0.160   11.613951   3.913513  0.068865  
0.200   14.212771   3.800329  0.079982  
0.240   16.688629   3.687889  0.090655  
0.280   19.041851   3.576174  0.100894  
0.320   21.273462   3.465136  0.110713  
0.360   23.385322   3.354685  0.120138  
0.400   25.380292   3.244670  0.129203  
0.440   27.262435   3.134860  0.137959  
0.480   29.037253   3.024911  0.146475

Op dit punt blijft de app blijkbaar in een nog op te lossen eindeloze lus, maar geen fouten of crashes verder.

Bij mij, Athlon 1200:

code:

Resultaten
                V L O E I S T O F       
x1        fug.(1)   fug.(2)   comp.z    
0,000    0,000786   4,373435  0,019924  
0,040    3,084543   4,257432  0,032826  
0,080    6,048907   4,142088  0,045286  
0,120    8,892419   4,027439  0,057300  
0,160   11,613951   3,913513  0,068865  
0,200   14,212771   3,800329  0,079982  
0,240   16,688629   3,687889  0,090655  
0,280   19,041851   3,576174  0,100894  
0,320   21,273462   3,465136  0,110713  
0,360   23,385322   3,354685  0,120138  
0,400   25,380292   3,244670  0,129203  
0,440   27,262435   3,134860  0,137959  
0,480   29,037253   3,024911  0,146475  
0,520   30,711973   2,914316  0,154848  
*** Cheating on fug1 & 2 Liq
0,560   32,295888   2,802344  0,163210  
0,600   33,800759   2,687950  0,171746  
0,640   35,241288   2,569641  0,180716  
*** Cheating on fug1 & 2 Liq
0,680   36,635636   2,445302  0,190498  
*** Cheating on fug1 & 2 Liq
------- knip --------

De regels met "Cheating" is een exceptie die in een functie wordt veroorzaakt (ongeldige wiskundige bewerkingen, negeer ik vooralsnog even). 't Valt dus wel meteen op dat mijn PC wel voorbij de regel met 0,48 komt, terwijl hij daar op een andere PC blijft hangen. Ze maken dus blijkbaar niet precies dezelfde berekening...

Ander punt is dat deze .exe ontstond vlak voordat mijn systeem weer tijdens het rekenen om zeep werd geholpen. Als ik de app opnieuw start (buiten Delphi om) gaat het gewoon goed.

Ik ga nu idd maar eens met memcheck aan de gang en even kijken of ik hem opnieuw in Borland kan starten zonder opnieuw te compileren.
Zou dit verschil tussen de PC's ook nog veroorzaakt kunnen worden door een verschil in mathematische coprocessor oid (iets als de befaamde Intel-decimaalbug)?

heuveltje schreef op 14 september 2004 @ 13:23:
Hier compileert en draait ie ook in 1 keer zonder problemen.
(alleen je vergeet ergens iets te resetten, als ik nog een keer op uitrekenen klik geeft ie invalid fpo. maar dat zal het probleem niet zijn lijkt me)

Die bug heb ik er nu uit ja . De exe posten wordt pas vanavond, had memtest al gestart zonder eerst de .exe te kopieeren... Dus ik laat die eerst maar ff kraken. En ik begin inderdaad steeds meer te vermoeden dat het aan mijn PC moet liggen, aangezien 2 andere PC's met dezelfde app geen problemen geven hier. Of er moet "iets" rot zijn binnen Delphi...

[ Voor 13% gewijzigd door Reptile209 op 14-09-2004 15:35 ]

[farlane]

Reptile209 schreef op 14 september 2004 @ 15:21:
Zou dit verschil tussen de PC's ook nog veroorzaakt kunnen worden door een verschil in mathematische coprocessor oid (iets als de befaamde Intel-decimaalbug)?

Hmmm, als je verder programmafouten hebt gelimineerd als boosdoeners, lijkt het erop dat misschien je coproc kaduuk is ? Je doet behoorlijk wat floating point berekeningen zo te zien .....
Misschien ben je een bug in de delphi math libs tegengekomen ? Zeg het maar ..

[Tomatoman]

Tijd voor een nachtje memtest86 draaien. Mocht dat geen resultaat opleveren, zet dan de process priority eens op een lage stand. Verder kun je kijken of het probleem ook optreedt als je het progsel buiten de Delphi IDE draait, maar vooralsnog houd ik het op een hardwareprobleem.

[Reptile209]

tomatoman: memtest86 heeft net een kleine 6 uur gedraaid (23 tests): geen fouten gevonden. In mijn vorige post zijn de verschillende uitkomsten op alledrie de PC's "stand-alone" gedaan, dus zonder de IDE. Sterker nog: op beide PC's is Borland Delphi nooit geinstalleerd geweest.
AFAIKS (as far as i can see) blijven eigenlijk alleen nog de math-lib en de coprocessor over. Maar ik neem aan dat er geen processor-specifieke info wordt gecompileerd in de default instellingen, dus dat dezelfde "build" op alle PC's gelijke resultaten zou moeten hebben.

Is er een manier om onafhankelijk mijn coprocessor te testen?
* Reptile209 duikt google weer in

[kvdveer]

Kun je 'm niet compileren met een target zonder co-processor, evt door optimalisaties uit te zetten?
* kvdveer is niet zo bekend met delphi

[ Voor 8% gewijzigd door kvdveer op 15-09-2004 01:11 ]

[Verwijderd]

Goed punt.

Vrûûger in Turbo Pascal kon je wel floating point emulatie aanzetten, maar ik krijg 't nu in Delphi niet meer teruggevonden...

En al is het niet echt een oplossing, je kunt natuurlijk ook altijd een andere compiler pakken om eens te zien wat dat doet, zoals fpc of gpc.

[Reptile209]

Nog een heel klein stapje verder richting de oorzaak/oplossing: de minidump .
Bij de crash wordt nu een minidump aangemaakt door Windows die ik vervolgens met de MS Debugging Tools for Windows kan analyseren. Dat levert de volgende info op (opeens overigens een andere STOP-code: 0x1e):

*****************
* *
* Bugcheck Analysis *
* *
*****************

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: c0000090, The exception code that was not handled
Arg2: 00453668, The address that the exception occurred at
Arg3: 00000000, Parameter 0 of the exception
Arg4: 0012f6ac, Parameter 1 of the exception

Debugging Details:
------------------

EXCEPTION_CODE: (NTSTATUS) 0xc0000090 - {EXCEPTION} Floating-point invalid operation.

FAULTING_IP:
+453668
00453668 ?? ???

EXCEPTION_PARAMETER1: 00000000
EXCEPTION_PARAMETER2: 0012f6ac
CUSTOMER_CRASH_COUNT: 2
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x1E
LAST_CONTROL_TRANSFER: from 0000001e to 80430999
STACK_TEXT:
f4e717e8 0000001e c0000090 00453668 00000000 nt!KiDispatchException+0x30e


FOLLOWUP_IP:
nt!KiDispatchException+30e
80430999 ?? ???

SYMBOL_STACK_INDEX: 0
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!KiDispatchException+30e
MODULE_NAME: nt
IMAGE_NAME: ntoskrnl.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4047db83
STACK_COMMAND: kb
BUCKET_ID: 0x1E_nt!KiDispatchException+30e

Followup: MachineOwner
---------

Ofwel: het gaat mis op "een" floating-point operation, voor zover ik dit verhaal begrijp. Wat ik dan niet snap, is waarom Delphi geen code genereert die voor mijn part een hele vieze error geeft, maar een BSOD/Crash.
Ik heb inmiddels - voor zover ik dat kan nagaan - alle "gevaarlijke" stukken code met floating-point operaties in try...except blokken gegooid. De app crasht nu, in de huidige build, zowel in de IDE als stand-alone.

Het gehele pakket staat hier. De exe crasht wederom alleen bij mij; bij huisgenoten blijft het een eindeloze lus.

Zowel memtest86 als een burn-in test van SiSoft Sandra 2004 leveren geen hardware-fouten op.

Iemand nog een briljant idee wat er nu misgaat dat deze fout optreedt?

[LordLarry]

Dit is misschien iets:
http://www.efg2.com/Lab/Library/UseNet/1999/0520b.txt
http://www.efg2.com/Lab/Library/UseNet/1999/0709a.txt
http://www.efg2.com/Lab/Library/UseNet/1999/0725.txt
http://www.efg2.com/Lab/Library/UseNet/1999/1119b.txt
http://web.archive.org/we...Point.html?mtbrand=AOL_US

[Tomatoman]

De links van LordLarry herinneren me opeens aan een stukje van mijn eigen code dat gebaseerd is op code voor de common dialogs in Delphi.

Delphi:

var
  FPUControlWord: Word;
begin
  asm
    // Avoid FPU control word change in NETRAP.dll, NETAPI32.dll, etc
    FNSTCW  FPUControlWord
  end;
  try
    { doe hier iets interessants in Delphi code }
  finally
    asm
      FNCLEX
      FLDCW FPUControlWord
    end;
  end;
end;

Mocht het FPU control word inderdaad het probleem zijn, dan is dit de manier die de Delphi ontwikkelaars zelf als workaround hebben gekozen.

[ Voor 1% gewijzigd door Tomatoman op 15-09-2004 21:27 . Reden: 1x end; vergeten ]