Witam,
Od dłuższego czasu próbuję rozwiązać problem przy pewnym projekcie gdzie bardzo uporczywie dają mi się we znaki błędy powodujące kompletnie nieprzewidywalne efekty.
Dodałem do kodu funkcję zwracającą ilość wolnej pamięci na podstawie książki M. Kardasia.
Metodą prób i błędów udało mi się doprowadzić do sytuacji, w której pamięć zapełnia mi konkretny fragment programu.
Za drugim obrotem pętli while, według funkcji getFreeMem(), coś zabiera nagle 483 bajty (z 486 spada na 3). Możliwe też, że zostaje nadpisany 1 bajt za obszarem zmiennych ale przed stosem (funkcja M. Kardasia szuka pierwszego bajtu niezgodnego ze wzorcem i na tej podstawie określa wielkość stosu)
framestart=0 i while z takim warunkiem jest celowe. while(1) maskowało błędy.
Błędy są przy optymalizacji -Os, ALE przy -O0 również, z tym że zamazywany jest inny adres w pamięci. Co ciekawe dopisanie w pewnych miejscach jakiejś instrukcji np. cnt=2; powoduje, że adres zamazanych komórek zmienia się o 2 bajty. Tyle co zajmuje we flashu ten dopisany fragment kodu. Tak jakby miało to związek z licznikiem adresu.
We fragmencie poniżej nie ma tablic w RAMie
edit:
Przeprowadziłem dalsze próby i okazało się, tak jak podejrzewałem, że stos jest w normie tylko zamazywane są dwie komórki pamięci znajdujące się zaraz za zmiennymi. Dalsza cześć, aż do stosu jest nieruszona. W pewnych okolicznościach zamazywanie dotyczy już obszaru zmiennych i wtedy program się krzaczy.
Za drugim obrotem pętli stos jest większy o 2 bajty czyli wszytko w normie.
Zamazane są jednak 2 komórki RAMu, kilka bajtów za adresem __heap_start
Zwracam się z prośbą o przedstawienie możliwych przyczyn zamazania pamięci nie będących:
-niewłaściwym indeksowaniem tablic
-przepełnianiem stosu
Od dłuższego czasu próbuję rozwiązać problem przy pewnym projekcie gdzie bardzo uporczywie dają mi się we znaki błędy powodujące kompletnie nieprzewidywalne efekty.
Dodałem do kodu funkcję zwracającą ilość wolnej pamięci na podstawie książki M. Kardasia.
Metodą prób i błędów udało mi się doprowadzić do sytuacji, w której pamięć zapełnia mi konkretny fragment programu.
Za drugim obrotem pętli while, według funkcji getFreeMem(), coś zabiera nagle 483 bajty (z 486 spada na 3). Możliwe też, że zostaje nadpisany 1 bajt za obszarem zmiennych ale przed stosem (funkcja M. Kardasia szuka pierwszego bajtu niezgodnego ze wzorcem i na tej podstawie określa wielkość stosu)
framestart=0 i while z takim warunkiem jest celowe. while(1) maskowało błędy.
Błędy są przy optymalizacji -Os, ALE przy -O0 również, z tym że zamazywany jest inny adres w pamięci. Co ciekawe dopisanie w pewnych miejscach jakiejś instrukcji np. cnt=2; powoduje, że adres zamazanych komórek zmienia się o 2 bajty. Tyle co zajmuje we flashu ten dopisany fragment kodu. Tak jakby miało to związek z licznikiem adresu.
We fragmencie poniżej nie ma tablic w RAMie
edit:
Przeprowadziłem dalsze próby i okazało się, tak jak podejrzewałem, że stos jest w normie tylko zamazywane są dwie komórki pamięci znajdujące się zaraz za zmiennymi. Dalsza cześć, aż do stosu jest nieruszona. W pewnych okolicznościach zamazywanie dotyczy już obszaru zmiennych i wtedy program się krzaczy.
Za drugim obrotem pętli stos jest większy o 2 bajty czyli wszytko w normie.
Zamazane są jednak 2 komórki RAMu, kilka bajtów za adresem __heap_start
Zwracam się z prośbą o przedstawienie możliwych przyczyn zamazania pamięci nie będących:
-niewłaściwym indeksowaniem tablic
-przepełnianiem stosu
Kod: C / C++