Cod de eroare în MS Visual Studio 2005 în RELEASE de configurare
Am un spațiu de lucru pentru a rula un encoder video H.263 într-o buclă de 31 de ori adică principalul este executat de 31 de ori pentru a genera 31 de fluxuri de biți codificate diferite. Acest spațiu de lucru MS Visual Studio 2005 are toate fișierele sursă C. Când creez o configurație "DEBUG" pentru spațiul de lucru și o construiesc și o execută, rulează bine, adică generează toate cele 31 de fișiere de ieșire cum era de așteptat. Dar când am setat configurația spațiului de lucru la "RELEASE" mdoe și repet procesul, codificatorul se blochează la un anumit test.
Acum, pentru a depana aceasta este verificată după cum urmează:
- Analiza codului pentru a vedea dacă în fiecare rulare a codificatorului a fost pierdută orice inițializare variabilă
- Verificați diferitele opțiuni de lucru (Soluție) în ambele moduri (DEBUG și RELEASE).
Există unele diferențe evidente, dar am transformat opțiunile legate de optimizare în mod explicit în ambele moduri.
Dar totuși nu a reușit să pună problema și să găsească o soluție pentru asta. Orice pointeri?
-Ajit.
Sunteți sigur că nu există directive precompilate care, de exemplu, ignoră un cod cu adevărat important în modul Release, dar le permite să le execute în Debug?
De asemenea, ați implementat orice înregistrare care ar putea să indice ansamblul precis care aruncă eroarea?
Este greu de spus ce ar putea fi problema fără a inspecta cu atenție codul. In orice caz...
Una dintre diferențele dintre versiunile de depanare și de lansare este modul în care este setat cadrul de stivă pentru apelurile funcției. Există anumite clase de lucruri rele pe care le puteți face (cum ar fi apelarea unei funcții cu un număr greșit de argumente) care nu sunt fatale într-o construcție de depanare, ci se prăbușește groaznic într-o ediție construită. Poate că ați putea încerca să modificați opțiunile legate de stivă în cadru (am uitat ceea ce sunt numite, îmi pare rău) în versiunea construiască la fel ca și depanarea construi și a vedea dacă aceasta ajută.
Alt lucru ar fi să permiteți toate avertismentele pe care le puteți avea și să le remediați pe toate.
Ar putea fi o problemă de concurrency a două fire. Configurația DEBUG încetinește execuția în jos, astfel că problema nu apare. Dar, doar o presupunere.
O problemă interesantă .. Sunteți sigur că nu aveți un cod de compilare cu condiție în jurul valorii de care nu este compilat în modul de eliberare? adică:
#if (DEBUG)
// Debug Code here
#else
// Release Code here
#endif
Acesta este singurul lucru pe care mă pot gândi cu adevărat .. Nu am experimentat niciodată așa ceva.
M-aș uita la accident în detaliu - dacă se prăbușește într-un caz de testare, atunci sună destul de ușor de reprodus, ceea ce este de obicei cea mai mare provocare.
Puteți adăuga simbolurile de depanare la versiunea de construire și rulați-o în depanator pentru a vedea unde și de ce sa prăbușit?
Un alt lucru de luat în considerare: în modul de depanare, variabilele sunt inițializate cu 0xCCCCCCCC în loc de zero. Asta ar putea avea unele efecte secundare urât.
Da, acele prăbușiri bastarde sunt cele mai greu de rezolvat. Din fericire, există câțiva pași pe care îi puteți face, care vă vor da indicii înainte de a reveni la analizarea manuală a codului și speranța de a găsi acul.
Când se prăbușește? La fiecare test? La un anumit test? Ce face acel test ca ceilalți nu fac asta?
Care este eroarea? Dacă este vorba despre o încălcare a accesului, există un model în care se întâmplă acest lucru? Dacă adresele sunt scăzute, ar putea însemna că există un indicator neinitializat undeva.
Este programul crashing cu configurarea Debug, dar fără debugger atașat? Dacă este așa, este cel mai probabil o problemă de sincronizare a firului, după cum a subliniat John Smithers.
Ați încercat să rulați codul printr-un analizor, cum ar fi Purify? Este lent, dar merită de așteptat.
Încercați să depanați oricum configurația de lansare. Acesta va anula numai ansambluri, dar vă poate da încă o indicație a ceea ce se întâmplă, cum ar fi în cazul în care pointer codul sare în mijlocul gunoiului sau atinge un breakpoint într-o bibliotecă externă.
Sunteți într-o arhitectură Intel? Dacă nu, urmăriți erorile de aliniere a memoriei, acestea se blochează fără avertisment pe unele arhitecturi, iar algoritmii codec tind să creeze aceste situații foarte mult, deoarece sunt optimizați prea mult.