Расшифровка вывода при halt

[Антон Федосов]

Снова здравствуйте. Есть проблема.
Имеем относительно завершенный проект на uos-embedded c процом 1892ВМ10Я. Недавно обнаружились зависания "на ровном месте", выбрасывает хальт с тектом (см. ниже). Зависает при разных обстоятельствах и в разное время, закономерностей не выявлено. Грешим на недостаточные размеры стеков и обдумываем вывод хальта.
Отсюда вопросы:
1. Что значит столбец Space в выводе хальта? Это сколько памяти использовано или сколько осталось свободной?
2. В столбце Address лежат адреса задач (значение указателя на функцию задачи) или что-то другое?
3. Что начит надпись (damaged) в столбце задач? Это зависшая задача?
4. Как определить поврежденную задачу? У нас больше десятка задач крутится, а тут в списке всего четыре.


Assertion failed in function `task_activate':

C:/workspace_mips/vega_v1/examples/mips-elvees/../../sources/kernel/internal.h, 124: ! task_is_waiting (task)


Task      Address     Prio        Stack    Space    Msg    Ticks

idle      1001e94     0      1002020    216    (nil)    99702

main_task      1002f88     1      1003220    644    (nil)    94731

t_en      10039c8     1      1003b88    428    (nil)    94731

(damaged)      1005a24     1      1005cd0    416    (nil)    5122

(damaged)      1004cf0    *1      1004f98    388    (nil)    94738

    Owning 0x1002ac8

(damaged).stack {0x1005040/0x1005058..0x1004f98/0x1004f58, 0xb8002a08, 0x1004fe0}

[(damaged).01005054]  01002adc  010005dc  30001c01  01000000

[(damaged).01005044]  01000654 >01002ac8  01000000  0100504c

[(damaged).01005034]  010005dc  30001c01  b800e0ec  01005030

[(damaged).01005024]  01001914  01000000  01000000  01003d18

[(damaged).01005014] *b8002a08  01000000  0000001c  01000000

[(damaged).01005004]  00000184  00000020  01004fe0  b8002a08

[(damaged).01004ff4]  01004f58  01004f98  0000000a  0000000a

[(damaged).01004fe4]  01001628  00000000  b8010908  01004ff0

[(damaged).01004fd4]  00000020  01004fe4  01001735  00000000

[(damaged).01004fc4]  010018c2  01005030  b8000c84  01004fe0

[(damaged).01004fb4]  01004fb4  01001628  b8002a08  00000001

[(damaged).01004fa4]  01004f98  00000000  01005040 =01004f58

[(damaged).01004f94]  00000010  00000001  40240000  00000000

[(damaged).01004f84]  40240000  00000000  40240000  00000000

[(damaged).01004f74]  00000020  00000000  00000030  00000000

[(damaged).01004f64]  b8002c00  010020fc  00000000  00000000


*** Please report this information

*** System halted.

[Александр Литягин]

Насколько мне склероз не изменяет, damaged выясняется тестом специальной функции - см kernel/uos.h кажется. Она определяла валидность указателей. Онидолжны попасть или в сегмент данных или в сегменты прошивы.

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

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

Я, когда это безобразие выяснял, ставил хуки на переключение задач. В которых делал валидацию очереди при вызове шедулера. 

Space , по моему склерозу, место в стеке никогда не затрагивавшееся. Принтер задачи считает место снизу стека сзаполненое шаблоном. 

5 дек 2017 г. 10:16 AM пользователь "Антон Федосов" <izon...@gmail.com> написал:

--
Вы получили это сообщение, поскольку подписаны на группу "uOS embedded".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес uos-embedded+unsubscribe@googlegroups.com.
Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес uos-em...@googlegroups.com.
Чтобы зайти в группу, перейдите по ссылке https://groups.google.com/group/uos-embedded.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Антон Федосов]

Спасибо. Будем думать.

вторник, 5 декабря 2017 г., 10:16:46 UTC+3 пользователь Антон Федосов написал: