EXC_BAD_ACCESS (KERN_INVALID_ADDRESS) во время выполнения malloc () - PullRequest
Новая
       54

EXC_BAD_ACCESS (KERN_INVALID_ADDRESS) во время выполнения malloc ()

1 голос
/ 08 апреля 2011

Я собираю библиотеку C в Mac OS X Snow Leopard с помощью следующего GCC: 

Diderot:~ brandizzi$ gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)

Когда я запускаю некоторые модульные тесты этой библиотеки (написанные на CuTest ) в одном из тестов возникла проблема: сигнал EXC_BAD_ACCESS.Это обычная проблема, и у меня есть некоторое представление об этой проблеме - я парень из Linux, который назвал это «Ошибка сегментации», понимаю, что происходит, и обычные способы решения этой проблемы.Что удивительно, так это то, что плохой доступ выполняется внутри выполнения malloc функции .Посмотрите на эту обратную трассировку, которую я получил в GDB: 

(gdb) bt
#0  0x00007fff89000a34 in tiny_free_list_add_ptr ()
#1  0x00007fff88ffe147 in tiny_malloc_from_free_list ()
#2  0x00007fff88ffcfdd in szone_malloc_should_clear ()
#3  0x00007fff88ffceaa in malloc_zone_malloc ()
#4  0x00007fff88ffb1a8 in malloc ()
#5  0x0000000100008c72 in util_copy_string (string=0x100008e48 "libsecretary") at src/util.c:7
#6  0x0000000100008126 in project_new (name=0x100008e48 "libsecretary") at src/project.c:8
#7  0x00000001000078b9 in secretary_start (secretary=0x10080b000, name=0x100008e48 "libsecretary") at src/secretary.c:23
#8  0x00000001000020f8 in test_secretary_move_task_from_project_to_project (test=0x1001005b0) at src/test/secretary.c:146
#9  0x0000000100006eae in CuTestRun (tc=0x1001005b0) at cutest/CuTest.c:143
#10 0x00000001000075c1 in CuSuiteRun (testSuite=0x100800000) at cutest/CuTest.c:289
#11 0x0000000100001527 in RunAllTests () at src/test/run_all.c:22
#12 0x000000010000156b in main () at src/test/run_all.c:32

Этот тестовый пример имеет следующие строки, и ошибка всегда происходит в четвертой.Если я переключаю линии каким-либо образом, проблема все еще возникает в четвертой: 

Secretary *secretary = secretary_new();
Task *task = secretary_appoint(secretary, "Test task transference");
Project *destination = secretary_start(secretary, "Chocrotary");
Project *origin = secretary_start(secretary, "libsecretary");

Итак, как malloc() может вызвать такую ​​проблему?Я даже не передаю указатель на это!Это ошибка?Кто-нибудь видел что-то подобное?

Заранее спасибо!

Ответы [ 2 ]

3 голосов
/ 08 апреля 2011

Скорее всего, что-то раньше при выполнении программы записывает в память, на которую не имеет права, что повреждает структуры данных кучи.Затем, позже, malloc вызывается и пытается следовать за указателем, который был перезаписан бессмысленным (или индексировать что-либо через значение, которое перезаписано бессмысленным, или что-то еще), и boom.

Возможно, вы захотитепопробуйте запустить тестовый набор под valgrind, чтобы увидеть, с чего все пойдет не так.

0 голосов
/ 02 марта 2013

Причин для этой проблемы очень много: одна не выделяла память, указатель указывает на неправильное место и т. Д. И т. Д.

В моем случае я выделял массив, например Project с MAX_PROJECT_COUNT позициями.Я написал 

Project *array = malloc(MAX_PROJECT_COUNT);

, но он не учитывает размер структуры Project!Правильное решение было бы 

Project *array = malloc(MAX_PROJECT_COUNT*sizeof(Project));

Обратите внимание, однако, что ваша проблема может значительно отличаться, поэтому невозможно применить то же решение.

...