program działa na win7, na XP out of memory

0

Witam

Mam problem z napisana przeze mnie aplikacją. Pisałem ją w Visualu 2005 na windowsie 7. Aplikacja na tej platformie działa sprawnie. Ilość zajmowanej pamięci jest zależna od rozmiaru pliku wejściowego. I tak przy pewnym pliku program zajmuje 60MB pamieci (wg menadzera urzadzen).

Wszystko byłoby dobrze, ale dla pewności odpalilem ten program na windowsie XP. I tu moje zdziwienie: przy tym samym pliku wejsciowym program wysypuje sie z powodu braku pamieci (na maszynie z 2GB ramu). Wg. menadzera urzadzen zajmowana pamiec skacze od 20MB do ponad 1GB (do czasu wywalenia sie programu).

Dodam, że w duzej czesci moj program opiera sie na malloc(), realloc() i free(), ale naprawde nie widze miejsca gdzie zaalokowana pamiec moglaby pozostac nie zwolniona. Poza tym przeciez w win7 program działa dobrze nie zajmujac wiele pamieci (jak na rozmiar danych wejsciowych)

Gdzie w takim razie może leżeć problem?

Z góry dzięki za odpowiedzi

Pozdrawiam

0

Odpal go w Visualu na XP, po zakonczeniu dostaniesz w Output spis wyciekow.

0

i dlatego pod windowsem kozysta sie z funkcji windowsowych.
malloc/free jest na linuxa.

0

No właśnie a ani w XP ani w 7 visual nie wykrywa wycieków pamięci!

Skąd mogą się brać takie różnice w pamięciożerności programu pod tymi dwoma systemami?

Poniżej zamieszczam screeny z programu process explorer dla tych samych danych wejsciowych (na tyle małych że program na XP jeszcze działa:

user image
user image

Dodam, że w programie korzystam tylko z biblioteki MFC i czystego c++.

0

@msvcrt_ssie: Bzdury.
@falouu: ciezko wyrokowac bez kodu. Czego uzywasz do operacji na pliku wejsciowym? Moze jakas funkcja z mfc, ktora jest nieodpowiednia albo ma blad? Miedzy XP a 7 biblioteki na pewno sie roznia, na oko to tu powinien byc punkt zaczepienia.

0
msvcrt_ssie napisał(a)

i dlatego pod windowsem kozysta sie z funkcji windowsowych.
malloc/free jest na linuxa.

Zważywszy, że nie ma nic wspólnego z Linuksem - to runtime C/C++. Wracaj do swoich nieudanych rootkitów, zakompleksiony szczeniaku. Może mi wytłumaczysz dlaczego Microsoft często i gęsto z malloc w niektórych programach korzysta?

Win7 ma inaczej zorganizowane zarządzanie pamięcią i pewnie lepiej sobie radzi z błędami programisty... Bez kodu to ciężko powiedzieć czym tego DoSa robisz, Visual podczas debugowania (na XP) powinien większość patologii zgłaszać. Zastanowiłbym się nad fragmentacją - może alokujesz od cholery małych obiektów, z czego część zwalniasz/realokujesz, w efekcie sterta jest rozszerzana do oporu i pełna dziur, za małych jednak żeby tam jakiś większy obiekt wcisnąć.

Ze screenów generalnie nic nie wynika, pomóc może kod, logi z outputu Visuala itd.

0
johny_bravo napisał(a)

Moze jakas funkcja z mfc, ktora jest nieodpowiednia albo ma blad? Miedzy XP a 7 biblioteki na pewno sie roznia, na oko to tu powinien byc punkt zaczepienia.

Akurat na MFC bym nie stawiał, są niezależne od systemu chociaż do niego dołączone, nowsze i tak są doinstalowywane z redistów/z Visualem (wszystko ponad MFC 6.0 - mfc42.dll). Piętro poniżej WINAPI - native api i kernel - różnice są ogromne, ale raczej na korzyść programisty - system stał się bardziej wyrozumiały i odporny na błędy.

0

@deus. : Chyba trafiles w sedno, to co piszesz to słowo w słowo opis mojej aplikacji - alokacja od cholery malych tablic obiektow, potem ich realokacja (zmniejszanie). Nie wiedziałem, że w tym może być problem. Myślałem że korzystając z tych funkcji mam niejako "zautomatyzowane" zarządzanie pamięcią i system będzie ją alokował mądrze. Widocznie XP tego nie potrafi. Będę musiał to jakoś inaczej rozwiązać

Wielkie dzięki deus. ,

Dzięki też wszystkim, którzy zainteresowali się tematem

Pozdrawiam

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