| |
 Стек ряпается, Проблемы со стеком |
|
|
|
|
  May 24 2006, 13:40
|
Частый гость
Группа: Новичок
Сообщений: 170
Регистрация: 26-05-05
Из: Москва
Пользователь №: 5 405
|
Доброго времени суток! Не знаю, как грамотно изложить пробему, но факт в том, что при выполнении очередной итерации цикла в функции происходит изменение дерева Call Stack в окне IAR Embedded Workbench (4.31). Соответственно функция, вызванная из main(), по выполнении указанного цикла обратно больше не возвращается, и заканчивается это дело прерыванием Undefined. Бьюсь весь день, не могу понять, где собака рылась. Ясно, что много неопределённостей, но может есть у кого мысли? Железки: AT91SAM7S64, J-Link + RDI. Добавлю на всякий случай окончание map-файла: Код 01 _LitobSmall
| Stack used (prev) : 00000AC8
| + function block : 00000018
<-Sub-tree of type: Function tree
| Stack used : 00000AE0
****************************************
* *
* SEGMENTS IN ADDRESS ORDER *
* *
****************************************
SEGMENT SPACE START ADDRESS END ADDRESS SIZE TYPE ALIGN
======= ===== ============= =========== ==== ==== =====
INTVEC 00000000 - 0000003F 40 com 2
ICODE 00000040 - 00000253 214 rel 2
DIFUNCT 00000254 - 0000027B 28 rel 2
CODE 0000027C - 00006D57 6ADC rel 2
INITTAB 00006D58 - 00006D6F 18 rel 2
DATA_ID 00006D70 - 00006F3B 1CC rel 2
DATA_C 00006F3C - 00007B18 BDD rel 2
DATA_I 00200000 - 002001CB 1CC rel 2
DATA_Z 002001CC - 00200CD5 B0A rel 2
HEAP 00200CD8 - 00201CD7 1000 rel 2
CSTACK 00201CD8 - 002030D7 1400 stk 2
SVC_STACK 002030D8 - 00203117 40 stk 2
IRQ_STACK 00203118 - 00203517 400 stk 2
FIQ_STACK 00203518 - 00203557 40 stk 2
****************************************
* *
* END OF CROSS REFERENCE *
* *
****************************************
27 992 bytes of CODE memory
13 654 bytes of DATA memory
3 521 bytes of CONST memory
Errors: none
Warnings: none
Сообщение отредактировал Master - May 24 2006, 13:43
|
|
|
|
|
|
2 страниц 
< 1 2
|
 |
Ответов
(15 - 22)
|
|
May 24 2006, 19:51
|
Частый гость
Группа: Новичок
Сообщений: 170
Регистрация: 26-05-05
Из: Москва
Пользователь №: 5 405
|
Цитата Черканите, когда ... Уважаемый zltigo! Ваша точка зрения ясна. Большое спасибо за помощь.
|
|
|
|
|
|
|
|
May 25 2006, 04:29
|
Участник
Группа: Свой
Сообщений: 24
Регистрация: 21-10-04
Из: Пермь, РФ
Пользователь №: 934
|
Для поиска таких ошибок удобно использовать Hardware Breakpoint (J-Link/MT-Link).
Ставишь брык на запись в область памяти и отладка остановится прямо на команде записи. Затем изучаешь Registers/Disassembler
|
|
|
|
|
|
|
|
May 25 2006, 09:00
|
Частый гость
Группа: Новичок
Сообщений: 170
Регистрация: 26-05-05
Из: Москва
Пользователь №: 5 405
|
Цитата(sapID @ May 25 2006, 07:29)  Для поиска таких ошибок удобно использовать Hardware Breakpoint (J-Link/MT-Link).
Ставишь брык на запись в область памяти и отладка остановится прямо на команде записи. Затем изучаешь Registers/Disassembler Ну типа спасибо  Поймите правильно, я некоторое представление об отладке программ имею. В моём случае нужен бряк по изменению содержимого памяти. Подскажите лучше, как RDI по такому условию настроить.
|
|
|
|
|
|
|
|
May 25 2006, 10:49
|
Странник
Группа: Свой
Сообщений: 766
Регистрация: 29-08-05
Из: Екатеринбург
Пользователь №: 8 051
|
Цитата(Master @ May 25 2006, 00:01) Уважаемый zltigo! Прежде всего я благодарю Вас за участие и внимание к моей проблеме. Но вынужден заметить, что по-моему дело не в размере/расположении/названии стека - всё это я разумеется могу выдать (кстати по поводу оценки размера стека можно почитать здесь, где Andy Mozzhevilov также озадачивался данной проблемой). Со своей стороны надеюсь, что Вы, давая совет считать размер стека, сами выполняли данную процедуру и готовы поделиться своими успехами. Как то раз были у нас в конторе заскоки со стеком у MB90, долго маялись, в конце концов написал калькулятор стека (кстати, глядя на который Andy Mozzhevilov и затевал разговор) - calc_stk, но и это не помогло, дальнейший тЩательный разбор полетов выявил наезд стека на переменную, теперь все гуд. Это к тому что не стоит отбрасывать ни одну версию до последнего ... и проверять все очень тщательно и свежей/трезвой головой.
--------------------
"Как много есть на свете вещей, которые мне не нужны!" Сократ
|
|
|
|
|
|
|
|
May 25 2006, 12:45
|
Частый гость
Группа: Новичок
Сообщений: 170
Регистрация: 26-05-05
Из: Москва
Пользователь №: 5 405
|
Цитата(spf @ May 25 2006, 13:49) Как то раз были у нас в конторе заскоки со стеком у MB90, долго маялись, в конце концов написал калькулятор стека (кстати, глядя на который Andy Mozzhevilov и затевал разговор) - calc_stk, но и это не помогло, дальнейший тЩательный разбор полетов выявил наезд стека на переменную, теперь все гуд. В чём оказалась проблема? Если можно, расскажите поподробнее. У меня, чувствуется, похожая ситуация. Причём отследить мне так и не удалось, на какой операции программа вылетает в exception, т.к. происходит это в разных местах. Поставлю бряк в одном месте, она вылетает в другом. В общем, мистика да и только. Цитата(Master @ May 25 2006, 15:36) В чём оказалась проблема? Если можно, расскажите поподробнее. У меня, чувствуется, похожая ситуация. Получил подтверждение тому, что что-то лезет на стек: вставил задержку перед выводом в DebugUnit, и стек слетать перестал. Посему очень интересен Ваш способ выхода из данной ситуации.
|
|
|
|
|
|
|
|
May 26 2006, 04:05
|
Странник
Группа: Свой
Сообщений: 766
Регистрация: 29-08-05
Из: Екатеринбург
Пользователь №: 8 051
|
Цитата(Master @ May 25 2006, 18:45) В чём оказалась проблема? Если можно, расскажите поподробнее. У меня, чувствуется, похожая ситуация.
Причём отследить мне так и не удалось, на какой операции программа вылетает в exception, т.к. происходит это в разных местах. Поставлю бряк в одном месте, она вылетает в другом. В общем, мистика да и только. Проблема была банальная - "ручное" распределение памяти с небольшим наездом отдельных частей друг на друга, корни проблемы росли из особенностей архитектуры процессора. Все до мелочей уже не помню, в общих чертах: проц с регистровыми банками в памяти, на каком-то вираже добавили обработчик прерывания с индивидуальным банком регистров, некоторое время все работало, потом стали наворачивать, стало падать, но не стабильно... в конце концов выяснилось что при выполнении определенной функции в одной из задач и вызове в это время того самого прерывания (достаточно редкое) портилась пара адресов возврата. Т.к. банк регистров наезжал на стек задачи (или наоборот), а из-за "ручного" распределения памяти не было сообщения об ошибке при линковке, то операции с некоторыми регистрами в прерывании приводили к изменению значений в памяти, куда смотрел и указатель стека задачи. Память была "забита" под завязку, поэтому увеличивать стеки особы было некуда, да и калькулятор подтверждал что уже есть небольшой запас...
--------------------
"Как много есть на свете вещей, которые мне не нужны!" Сократ
|
|
|
|
|
|
|
|
May 26 2006, 04:33
|
Участник
Группа: Свой
Сообщений: 24
Регистрация: 21-10-04
Из: Пермь, РФ
Пользователь №: 934
|
Цитата(Master @ May 25 2006, 15:00) Цитата(sapID @ May 25 2006, 07:29)
Для поиска таких ошибок удобно использовать Hardware Breakpoint (J-Link/MT-Link).
Ставишь брык на запись в область памяти и отладка остановится прямо на команде записи. Затем изучаешь Registers/Disassembler
Ну типа спасибо Поймите правильно, я некоторое представление об отладке программ имею. В моём случае нужен бряк по изменению содержимого памяти. Подскажите лучше, как RDI по такому условию настроить. Типа, всегда пожалуйста Про RDI точно не знаю - работаю в режиме J-Link Там в отладке появляется менюшка J-Link -> Watchpoints Дальше все интуитивно понятно, кроме поля Mask - его, обычно, надо ставить 0xFFFFFFFF
|
|
|
|
|
|
|
|
May 26 2006, 06:59
|
Местный
Группа: Свой
Сообщений: 359
Регистрация: 9-12-05
Пользователь №: 12 034
|
Цитата(spf @ May 26 2006, 10:05) Проблема была банальная - "ручное" распределение памяти с небольшим наездом отдельных частей друг на друга... Не я один такой. Тут недавно тоже у себя обнаружил ошибку в ручном распределение внешней памяти LPC2292 на 4 кольцевых FIFO буфера. Все 4 буфера пересекались и длины не соответствовали. Когда нашёл волосы дыбом встали как я такое понаписать мог (в 3-х макросах запутался)! А ведь как-то год работало. Видимо потому как данные в буфер попадали на очень небольшое время.
|
|
|
|
|
|
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|
