Eccezione di underflow o overflow aritmetico durante il debug

Question

Questo è il giorno dei comportamenti strani.

Abbiamo un progetto Win32 realizzato con Delphi 2007, che ospita il runtime .NET e richiama .NET per mostrare nuovi moduli, come parte di un periodo di transizione.

Recentemente abbiamo iniziato a riscontrare eccezioni in posizioni e punti apparentemente casuali del nostro codice:Overflow o underflow aritmetico.

L'analisi dello stack di uno di questi è simile a questa:

at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.RunDialog(Form form)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()
at Gatsoft.Gat.UI.Windows.Forms.Remanaging.RemanageForm.DelphiOpenInNewMode(String employeeCode, String departmentCode, DateTime date) in C:\Dev\VS.NET\Gatsoft\Gatsoft.Gat.UI.Windows\Forms\Remanaging\RemanageForm.Delphi.cs:line 67

Nella soluzione Visual Studio, una delle librerie di classi più esterne (ad es.inserisce tutti i riferimenti possibili), ha impostato un programma di debug specifico, mirato all'output del progetto Delphi.Ciò ci consente di eseguire il debug del codice .NET da Visual Studio, anche se la maggior parte del programma è scritta in Delphi.

Il problema si verifica solo quando eseguito dal debugger, non se eseguiamo direttamente il file exe (tramite Explorer, scorciatoie o anche Ctrl+F5 all'interno di Visual Studio).

Apparentemente non c'è spyware sulla macchina (come suggerito da Questo).

Altre cose che possiamo controllare?

---

Modificare: Sembra che il debugger .NET stia abilitando questi flag SNaN e il debugger Delphi no.Dovremo approfondire la questione, ma per ora accetto @Lorenzo Boccacciaè la risposta.

Apparentemente risolto

Ok, sembra che abbiamo finalmente risolto il problema.Il problema ha iniziato a verificarsi senza che fosse collegato anche il debugger, per i nostri tester, quindi abbiamo dovuto dare priorità al problema.

Alla fine abbiamo riscontrato un problema comune con le macchine che presentavano il problema, si tratta di laptop Dell Lattitude D620 con una NVIDIA Quadro NVS 110M, con un vecchio driver di un'immagine di sistema utilizzata per eseguire il provisioning dei laptop, nel lontano 2006.

Ho trovato un post sul Web, anche se ho perso l'URL quando ho riavviato per aggiornare il driver dello schermo, che presentava un arresto anomalo del servizio .NET, soprattutto quando la macchina era impegnata a fare qualcosa sullo schermo.Un modo per riprodurre il problema era aprire un prompt dei comandi su C:\ e fare a DIR /S per forzare semplicemente una quantità enorme di aggiornamenti dello schermo, che causerebbero l'arresto anomalo.

Anche lui aveva una scheda video NVIDIA.

Il problema sulla mia macchina si verificava all'incirca ogni 2-4 avvii del nostro programma, ma dopo aver aggiornato il driver video ho avuto 123 avvii riusciti senza problemi.(A proposito, posso consigliarlo AutoHotKey per queste cose).

Sembra quindi che abbiamo trovato il colpevole, un driver NVIDIA vecchio/bucato.

Aggiornata questa domanda in modo che forse qualcuno in futuro possa risparmiare un po' di tempo.

Ora, se vuoi scusarmi, andrò a piangere in un angolo.

Sfidato!

Devo averlo sfortunato.Non appena ho pubblicato l'aggiornamento di cui sopra, il laptop di un collega si è guastato, dopo aver aggiornato il driver video.

Tuttavia, sono sicuro che ora sia un problema al di fuori della nostra applicazione, quindi resta solo da capire quali cose specifiche aggiornare.

---

Ulteriori aggiornamenti:Ok, la mia macchina ora sembra essere riparata, non così con la macchina dei miei colleghi.Finora abbiamo aggiornato il BIOS, i driver del chipset e attualmente è in arrivo il SP3 per XP.

Stasera verrà eseguito un test di burn-in, durante il quale l'app verrà lasciata in fase di avvio durante la notte, poiché il problema si è verificato durante l'avvio o alla prima esecuzione del codice WinForms .NET.Questa app è principalmente un'app Delphi Win32, ma ospita il runtime .NET e il problema sembra essere correlato al codice .NET.Quando "avviiamo" il runtime .NET, il problema può apparire oppure quando attiviamo la prima finestra .NET da Win32, può anche apparire.

---

Statisticamente sono pronto a rilasciare questo codice ora.Durante la notte l'applicazione è stata avviata 3051 volte senza errori, mentre prima che aggiornassi il driver video si bloccava ogni 2-4 volte.

Spinto e trovato(!/?)

Questa prova di risoluzione dei bug sembra come andare dal medico, dove segue la seguente conversazione:

Doc: Does this hurt?
Me: No...
Doc: What about now?

Ho spinto e spintonato l'applicazione e finalmente penso di aver trovato qualcosa che ha introdotto questo problema.

Nella nostra app ospitiamo il runtime .NET, da un'applicazione Win32 di Delphi 2007, e nel nostro codice adesivo abbiamo la seguente riga (ora):

  rc := CorBindToRuntimeEx('v2.0.50727', 'wks',
  STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN or STARTUP_CONCURRENT_GC,
  @clsid, @iid, UnkRuntimeEngine);

Delle due costanti al centro originariamente c'era solo uno 0, che significa scegli le impostazioni predefinite.Questo cambiamento è stato introdotto alcuni mesi fa e da allora il problema si è lentamente insinuato in noi.La modifica è stata introdotta per incoraggiare il profiler ANTS a caricare la nostra applicazione Win32 + runtime .NET ospitato per eseguire la profilazione delle prestazioni e le modifiche introdotte in quel momento hanno fatto sì che funzionasse.Inoltre, il problema con l'overflow/underflow aritmetico è lentamente peggiorato, quindi scommetto che il problema non si è presentato per un po' dopo la modifica, quindi non è stato attribuito a nessuna delle modifiche apportate.

Inoltre, poiché (originariamente) abbiamo riscontrato il problema solo durante l'esecuzione del debugger, abbiamo pensato che ci fosse qualcosa di sbagliato in Visual Studio e/o Delphi.

Ad ogni modo, statisticamente ora, con un browser su uno schermo che esegue ripetuti scrolling su e giù attivati ​​da un javascript (apparentemente necessario per attivare il bug), sono stato in grado di avviare con successo l'applicazione 726 volte con uno 0 nella chiamata e si blocca 5 volte su 17 con le due costanti presenti.

Doc: Does this hurt?

E non entriamo nel merito di chi ha apportato quel cambiamento in primo luogo.Sono sicuro che il colpevole vuole rimanere anonimo... tosse

Answer 1

una versione di debug di una DLL collegata potrebbe essere compilata con il supporto di segnalazione nan, vedere http://blogs.msdn.com/oldnewthing/archive/2008/07/02/8679191.aspx per un esempio di questo problema.

che heisenbug è stato causato da variabili non inizializzate, qui potrebbe esserci una dll collegata che abilita la funzione snan della CPU e si dimentica di disabilitarla al ritorno

Answer 2

Gli errori si verificano ancora se si collega il debugger dopo aver avviato l'applicazione?