L'output di un compilatore dipende dal sistema operativo in uso?

5

Nell'azienda in cui lavoro ho un software di gestione, scritto da un programmatore esterno. Chiamiamo il software PK. PK è stato inizialmente scritto negli anni '90 usando C ++. Da allora è stato regolarmente aggiornato e mantenuto, ma nel suo nucleo è sempre rimasto un software basato sulla tecnologia degli anni '90.

Siamo attualmente in fase di migrazione da Windows 7 a Windows 10 e ho ricevuto uno dei primi PC Win 10 per testare se tutto funziona come previsto sul nuovo sistema operativo. Tutto ha funzionato, ma PK. PK improvvisamente ha avuto frequenti incidenti. Ho detto allo sviluppatore del software che ci sono problemi con PK sotto Win 10 ma anche dopo numerosi aggiornamenti e modifiche al codice abbiamo ancora avuto questi arresti anomali. Lo sviluppatore non è riuscito a capire perché è andato in crash anche se sembra essere correlato alla gestione della memoria di PK.

L'ultima goccia che lo sviluppatore ha visto è stata la compilazione del software sul mio Win 10-PC. Ho compilato il codice sorgente con esattamente la stessa versione di Visual Studio 2008 e improvvisamente ha funzionato. Niente più arresti anomali.

Quindi la mia domanda è:

Può essere che lo stesso codice, compilato dallo stesso compilatore, produca un diverso binario dipendente dalla versione di Windows (Windows 7 e 10)?

E se sì: perché?

    
posta CKA 14.11.2018 - 09:21
fonte

3 risposte

4

Potrebbero esserci impostazioni del compilatore diverse tra le versioni IS.

L'applicazione potrebbe invocare comportamenti non definiti, nel qual caso può succedere di tutto. Ho avuto questo successo quando qualcuno ha introdotto UB sei mesi prima e ha causato crash 6 mesi dopo in codice di nuova introduzione completamente non correlato.

I una volta aveva un computer con RAM difettosa borderline e produceva codice che si bloccava quando un particolare file sorgente veniva compilato su quella macchina se la macchina era stata in esecuzione per ore.

    
risposta data 14.11.2018 - 10:16
fonte
3

Quello che stai descrivendo può accadere con binari identici tra versioni del sistema operativo se caricano in modo dinamico versioni diverse, compatibili con ABI, delle loro librerie dipendenti. Può anche accadere se le librerie sono identiche byte per byte e il sistema operativo modifica i criteri di gestione della memoria (ad esempio, fornisce un po 'di spazio invece di molto di più di quello richiesto dall'allocatore userspace). Un arresto anomalo causato da un errore di memoria potrebbe interessare solo un sistema il cui allocatore di memoria ha una strategia più conservativa di un'altra.

Hai effettivamente controllato l'utilizzo di qualcosa come, ad es. Dipendenze o Process Explorer che tutte le librerie caricate sono le stesse? Hai ispezionato i binari con un disassemblatore per vedere se ci sono differenze nel codice generato? Passare attraverso il codice nel debugger e vedere dove si blocca.

    
risposta data 14.11.2018 - 10:29
fonte
1

Il codice stesso è solo una piccola parte di ciò che va nell'eseguibile finale; tutto l'I / O e molte altre cose in genere utilizza funzioni di libreria , che sono piuttosto diverse nelle diverse versioni di Windows, spesso anche tra le varie versioni di Windows 10.

Di conseguenza, il codice potrebbe essere basato sul comportamento in un vecchio codice di libreria che non è più supportato, o che nemmeno avrebbe dovuto funzionare, ma in qualche modo lo ha fatto; o il codice ha UB con cui è andato via con le vecchie versioni della libreria, ma non più, ecc.

Per essere sicuro, dovrai analizzare il codice e trovare i motivi dei crash, quindi saprai se è sempre stato sbagliato e sei stato fortunato (90%) o se qualche codice della libreria non è più compatibile (10%).

    
risposta data 15.11.2018 - 04:11
fonte

Leggi altre domande sui tag