EXC_BAD_ADDRESS при добавлении дополнительных локальных переменных в C - PullRequest
0 голосов
/ 31 марта 2011

Итак, у меня есть программа, которая работает, но когда я добавляю больше локальных переменных, она взрывается.

Добавлен код:

double prMaxT, prMinT, poMaxT, poMinT, linT;

Программа получила сигнал EXC_BAD_ACCESS, Не удалось получить доступ к памяти,Причина: KERN_INVALID_ADDRESS по адресу: 0x0000000000000000 0x0000000100001411 в bst_height (bst = 0x0) в bst.c: 72 72, возвращает bst_height_node (bst-> root);

flynn_p4 (7171): ошибка объекта 10010x7fff5fc00760: освобожденный указатель не был выделен * установить точку останова в malloc_error_break для отладки прерывания прерывания

Все переменные:

#define SIZE 1000
#define dSIZE 500
#define RUNS 5000
#define SEARCH_WIDTH 1501
#define SEARCHES 1000000
//main()
int rands[SIZE], dels[dSIZE], srch[SEARCHES], pre_h[RUNS], post_h[RUNS], i, j, z, found = 0, total = 0;
struct timeval whole_start, whole_end;
double prMaxT, prMinT, poMaxT, poMinT, linT;
struct bst *pre_max, *post_max, *pre_min, *post_min, *linear, *trees[RUNS];

Все это дает моей программе объем памяти ~1,2 МБ, поэтому я решил все утечки, которые смог найти.И ошибка не там, где GDB думает, что он находится в bst_height_node(), поскольку, если я закомментирую double s, все будет работать.

Так есть ли предел тому, сколько памяти main () может иметь настек и превышаю ли я его?Я переместил большие массивы в глобальное пространство, и это не исправило его, но больше всего я хочу знать, что происходит, а не просто исправить.

Среда сборки: gcc 4.2.1 на MacOS X 10.6.7 - 2010 Macbook Pro (если это актуально)

// Редактирует: я решил это с помощью флага gcc flag -pedantic, который дал мне:

gcc-pedantic -c -o bst.o bst.c gcc -pedantic -c -o main.o flynn_p4.c flynn_p4.c: в функции 'main': flynn_p4.c: 87: предупреждение: ISO C90 запрещает смешанные объявления и кодflynn_p4.c: 131: предупреждение: ISO C90 запрещает смешанные объявления и код gcc -pedantic -o flynn_p4 main.o bst.o

Так что мое объявление int на полпути через функцию вызвало это, DOH!

Ответы [ 3 ]

2 голосов
/ 31 марта 2011

Не знаю, каково ограничение стека по умолчанию. Я не пользователь MacOS, но, учитывая, что базовая система является Unix, попробуйте в оболочке ulimit -a, чтобы перечислить ограничения процесса.

Я бы предположил, что где-то в ядре он имеет жесткий предел, но до его достижения вы можете увеличить предел стека процессов с помощью ulimit -s.

(Но я должен признать, что я ожидал бы другого сообщения об ошибке в случае, если это действительно переполнение стека - это больше похоже на некоторые вещи с нулевым указателем)

1 голос
/ 31 марта 2011

Для таких кусков данных я бы определенно выделил их в кучу.Для вашего кода не имеет большого значения, храните ли вы указатели или массивы в стеке, но существует большая разница с размером стека.Да, есть ограничение на размер стека.

И даже если это сработало, что если вы (или, что еще хуже, кто-то еще) захотите вернуться и изменить макросы тех размеров?Или что, если у вас есть две функции с большими кадрами стека, которые прекрасно работали отдельно, но позже вы решили вызывать одну из другой?

0 голосов
/ 31 марта 2011

Добавление флага -pedantic в gcc показало объявление переменной не по месту через функцию:

gcc -pedantic -c -o bst.o bst.c gcc -pedantic -c-o main.o flynn_p4.c flynn_p4.c: в функции 'main': flynn_p4.c: 87: предупреждение: ISO C90 запрещает смешанные объявления и код flynn_p4.c: 131: предупреждение: ISO C90 запрещает смешанные объявления и код gcc -pedantic -o flynn_p4 main.o bst.o

-педантик выигрывает этот раунд

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...