VisualC++ runtime library problem: debug verzija radi kako treba dok release ver mi puca.

[ tupito @ 03.04.2006. 14:00 ] @

pravim toolbox za Matlab/Simulink a njegov glavni deo je S-function. S-Function je u stvari dll napravljen u VC++ koji Matlab poziva(exportuje jednu funkciju koju matlab poziva), i sve radi fenomenalno dok koristim debug verziju runtime library (/MDd).

Medjutim kad prebacim u release verziju (/MD), simulacija puca i Matllab mi govori da je ovaj moj nesrecni dll napravio "segmentation violation" a to u sustini
znaci pristup nealociranoj memoriji, e sad ako je moja programerska greska, po nekom mom rezonovanju , onda bi trebalo da puca i sa debug verzijom. A sto mi je najcudnije ja stavim release verziju runtime library , i sve to debugujem iz VC++ simulacija ne puca i sve radi kako treba ,a ako odmax posle pokrenem ctrl F5
lili ti "start without debugiing" smiulacija puca, tako da i ako je u pitanju neka moja greska nema sanse da otkrijem gde je(inace moj dll ima 30 000 linja).A probao sam sa vise verzija matlab-a i isto se desava.

Da li neko mozda ima neku ideju sta bi to moglo da bude , i kako to da resim?
A drugo pitanje je u vezi sa debug verzijom runtime library da li je ona sporija i koliko od release verzije? jer to je ono sto je meni najvaznije .

EDIT: ne koristim nista fancy sem STL-a

_{[Ovu poruku je menjao tupito dana 03.04.2006. u 16:04 GMT+1]}

[ Alex21 @ 03.04.2006. 14:39 ] @

Ovakve problemi znaju zadavat pravu glavobolju.

Iz mojeg iskustva, kod ovakvih stvari obično neki pointer odleti malo krivo ili indeksiraš polje preko granice (u biti sam dva puta rekao istu stvar :) ).

Zašto naposan kod u debug verziji dobro radi?
Zato što debuger oko svake varijable kod alociranja postavi guard bytove. Ti guard bytevi se inače koriste za detekciju prepisivanja po memoriji, tako da se
testira promijena njihovog sadržaja. U MFC-u se npr. to radi pozivom AfxCheckMemory() funkcije kod svake alokacije/delokacije, gdje se u uslučaju prepisa izbacije TRACE poruka.

Međutim, ako se ne koriste ovi mehanizmi, tada će guard bytevi omogućit da se neki bugovi provuku, za što vjerujem da se je tebi dogodilo.
Najvjerojatnije ti neki pointer odleti, koji kod debugiranja pomrčka guard bytove, a u release verziji druge stvarne varijable.

Znači, 99% da razlog nije u library kojeg pozivaš već u tvom kodu.

pozdrav

[ Dragi Tata @ 03.04.2006. 14:52 ] @

Probaj da kompajliraš Release verziju sa ugrađenim Debug info. Možda ti pokaže gde je problem.

[ tupito @ 03.04.2006. 15:51 ] @

ja mislim da sam to pokusao, stvar je u tome sto kada ga sa release verzijom bibloteke debagujem i izvrsam program korak po ko korak sve normalno radi i jednostavno nema sanse da pronadjem gresku.

[ NrmMyth @ 03.04.2006. 18:22 ] @

pregledaj sve switcheve, posebno one za optimizaciju

[ tupito @ 03.04.2006. 19:21 ] @

Probao sam to vec i opet isto sa i bez optimizacije. jedino sta sam primetio jeste runtime libriary ona jedina pravi razliku.

[ z@re @ 03.04.2006. 21:03 ] @

Pokusaj sa drugim kompajlerom.

[ yooyo @ 04.04.2006. 14:41 ] @

Proveri sve konstruktore i da li si inicijalizovao varijable na podrazumevane vrednosti.
Takve greske se desavaju ako npr zaboravis da postavis pointer na NULL, a negde u programu napises:

Code:

if (ptr != NULL) ptr->DoSomething();

yooyo

[ X Files @ 04.04.2006. 15:23 ] @

Pošto je pitanje za glavobolju, evo par pitanja tipa "proverite da li ste uključili kabl u struju".

Da li ima veze sa KOJOM verzijom VC++ je kompajliran DLL? Tj da li treba da bude ista verzija
kao kod MatLab-a? Znam da je u jednoj firmi koja pravi Plug-In-ove za AutoCad, program
MORAO da bude u istoj verziji kao i AutoCad.

Da li je taj DLL potpuno samostalan? Ima li jos neki fajl koji je ukljucen u igru. Meni se jednom
desilo da je program POGREŠNO određivao putanju kada se izdvoji iz Debug foldera.

Konačno, postavi ASSERT-e na svim kritičnim mestima. Ili ono što ja radim par puta godišnje
radi takvih idiotarija, stavljam deo po deo koda pod komentare, i čekam da vidim kada će
problem prestati.

[ tosa @ 04.04.2006. 16:55 ] @

Citat:

X Files: Da li ima veze sa KOJOM verzijom VC++ je kompajliran DLL? Tj da li treba da bude ista verzija
kao kod MatLab-a? Znam da je u jednoj firmi koja pravi Plug-In-ove za AutoCad, program
MORAO da bude u istoj verziji kao i AutoCad.

Moze biti i pogresan calling convention. Verzija VC++ ne moze imati nikakav znacaj, ako je calling
convention isti. Ukoliko nije ista dekoracija imena, dobices poruku o gresci da nedostaje metod/klasa/sta god.
Dakle u vasem slucaju je verovatno promenjena default calling convention...

Citat:

X Files: Konačno, postavi ASSERT-e na svim kritičnim mestima. Ili ono što ja radim par puta godišnje
radi takvih idiotarija, stavljam deo po deo koda pod komentare, i čekam da vidim kada će
problem prestati.

Nadam se da ne naplacujes mnogo radni sat ;)

[ X Files @ 04.04.2006. 21:27 ] @

Citat:

Nadam se da ne naplacujes mnogo radni sat ;)

:) "Ako neće breg Muhamedu - 'oće Muhamed bregu"

Naravno, vrsiti komentarisanje koda deo po deo je pravo ubistvo, pogotovo sto su
metode (funkcije) najcesce medjuzavisne. Na zalost, ja sam to morao da radim par
puta, i uvek sam otkrio neku glupost na koju uopste nisam ni sumnjao.

[ tupito @ 04.04.2006. 22:34 ] @

uuuh i nekako nadjoh gresku. mislim strasno....

u pitanju je bila neinicijalizovana promenljiva, a razlog sto je mi nije palo na pamet da je inicijalizujem ili da je proveravam jeste sto nicemu ne sluzi. prilikom citanja ulaznih podataka zbog nekih testiranja sam na brzinu ubacio tu bool promenljivu koja mi odredjuje da li da ucita neke test podatke. a kad sam zavrsio sa tim testiranjima potpuno sam zaboravio na tu promenljivu , u debugu ona je bila inizijalizovana na slucajnu vrednost i sve je radilo normalno, dok u releseu na nulu pa onda mi uctao potpuno neboluzne podatke a program bi nastavio da radi dok nebi pukao.

U svakom slucaju svima veliko hvala na pomoci!