Z x86 na x64

0

Witam,
mam problem z migracją aplikacji z systemu 32-bitowego do 64-bitowego. Na x86 wszystko śmiga pięknie ładnie, a na x64 zaobserwowałem crash aplikacji w momencie kończenia pętli (domyślam się, że chodzi o fakt zwalniania lokalnych zasobów w pętli). Aplikacja sygnalizuje błąd i jako źródło wskazuje dllke: ntdll.dll. Ogólnie rzecz biorąc wszędzie poza tym jednym momentem aplikacja działa. Cóż mogę jeszcze dodać... Aplikacja korzysta z jeszcze paru projektów, których zasoby są w postaci dllek. Nie oczekuję gotowego rozwiązania, bo wydaje mi się, że takiego nikt mi nie poda, jednak chciałbym wiedzieć, w którą stronę mam się kierować w czasie tego typu migracji i analizy tego problemu. Może jest jakiś standardowy sposób postępowania?

Zauważyłem, że ta dllka ntdll.dll jest znacznie większa niż w systemach 32-bitowych. Domyślam się, że jest ona bardziej restrykcyjna w 64-bitowcach niż w 32, i dlatego nie puszcza, no ale mogę się mylić. Proszę o uwagi.

0

I tak bez kodu, a nawet bez informacji jaki to kompilator, mamy ci pomóc?

0

Kodu nie da rady załączyć, chodzi mi raczej o ogólne uwagi na co położyć nacisk przy analizie crash'a. Może ktoś miała problemy w czasie migracji podobne do moich i których przyczyną była dllka: ntdll.dll. Używam Visual Studio 2005.

0

Przyczyną były błędy w Twoim programie, ntdll nie jest niczemu winny. Weź debugger, jak poleci wyjątek to obejrzyj callstack...

0

Może gdzieś rzutujesz wskaźnik na inta, czyli zakładasz że wskaźnik ma 4 bajty...

0

Znalazłem błąd. Mam projekt z niezarządzanymi dllkami (/MD). Z jednej dllki wywoływałem funkcję z drugiej i jako argument wysyłałem w niej referencje do wektora. Następnie w tej drugiej dllce robiłem push_back co powodowało alokacje pamięci, ale w drugiej dllce. Po powrocie do pierwszej dllki po zwalnianiu wektora wyskakiwał błąd. Wyczytałem gdzieś na obcojęzycznych forach, że najlepiej przy takiej konfiguracji posługiwać się typami podstawowymi i tak też zrobiłem - zamieniłem wektor na char*. Problem zniknął. Może jednak jest lepsze rozwiązanie? Oczywiście zmiana na Multi-threaded (/MT) odpada.

I tak oto uwidocznił się wyciek, który na x86 się nie ujawnił. Problem widać nie miał związku z systemem plików.

0

Było i na 4p kilka razy. Runtime tworzy własną stertę, jeżeli jest więcej runtime'ów wewnątrz programu (statycznie wlinkowane w biblioteki itd.) to każdy z nich ma swój heap. Odwołanie się do jednego z pointerem z innego kończy się zazwyczaj tak jak wyżej. Po prostu nie linkuj statycznie.

0

O osobnych stertach wiedziałem, tylko nie wiem dlaczego wypadło mi to z głowy przy debugowaniu. Załóżmy, że chcę linkować statycznie. Co myślisz o tym:

Pierwsza dll

void receive(char *x, int size)
{
	strcpy_s(x, size, "Aaaa");
}

Druga dll

void send()
{
	char* x = new char[256];
	receive(x, 256);
	delete [] x;
}

Może nastręczać problemów? Tutaj już alokacji w drugiej dll nie ma, żadnych push_back'ów, także wydaje mi się, że powinno być ok, i żadnych ukrytych wycieków nie będzie.

//EDIT: delete [] x;

0

Owszem, nie będzie problemów. Musisz jedynie uniknąć zwalniania/realokacji poprzez różne moduły. Po prostu, kto zaalokował, ten zwalnia.

0

Dziękuję za pomoc.

1 użytkowników online, w tym zalogowanych: 0, gości: 1