Необъяснимое поведение при интеграции порта xR FreeRTOS (pthreads) и вспомогательного кода pthreads - PullRequest
0 голосов
/ 14 января 2020

У меня нет идей, как выяснить, откуда возникла моя проблема.

Я пытаюсь включить обработчик UDP Asyn c в существующий эмулятор FreeRTOS, оба из которых основаны на pthreads. Реализация FreeRTOS - это, по сути, оболочка для pthreads, а обработчик UDP создает задачу FreeRTOS, которая затем порождает поток pthread для каждого сокета, так что порожденные потоки могут иметь свою собственную сигмацию для обработки указанного порта UDP c с указанным обратным вызовом. .

В качестве проверки работоспособности я вчера переместил код обработчика UDP в отдельную сборку, чтобы протестировать его, и он работает без сбоев, нашел здесь . Все проверки valgrind также не показывают ошибок. Эмулятор FreeRTOS также стабилен, когда не добавлен обработчик UDP, находится здесь . Нестабильная интеграция может быть найдена здесь .

Теперь при интеграции двух я получаю поведение, которое мне пока не удалось успешно отладить. Ошибка представляет собой heisenbug в том, что во время отладки я не могу воссоздать его всегда. Все valgrind (memcheck, helgrind и drd) не могут воссоздать ошибку, сообщая только об ошибках в связанных библиотеках, таких как SDL2, X11, mensa graphics et c. Посмертная GDB может зафиксировать ошибку, а также при использовании (gdb) set disable-randomization off.

Обратный след от GDB показывает мне следующее

(gdb) bt

# 0 0x00007faa2f45a41b в pthread_kill () из /usr/lib/libpthread.so.0

# 1 0x0000564392f5c93b в prvResumeThread (xThreadId = 0) в / home / alxhoff / gitT / GITH GITH /FreeRTOS_Kernel/portable/GCC/Posix/port.c:561

# 2 0x0000564392f5c38b в vPortYield () в / home / alxhoff / git / GitHub / FreeRTOS-Emulator / lib / FreeRTOS_Ker /Posix/port.c:329

# 3 0x0000564392f5d986 в xQueueGenericReceive (xQueue = 0x564396692bd0, pvBuffer = 0x0, xTicksToWait = 4294967295 / free-ght) Эмулятор / lib / FreeRTOS_Kernel / queue. c: 1376

# 4 0x0000564392f5b0d3 в vDemoTask1 (pvParameters = 0x0) в /home/alxhoff/git/GitHub/FreeRTOSr53.smulator : 338

# 5 0x0000564392f5c754 в prvWaitForStart (pvParams = 0x5643966b2780) в /home/alxhoff/git/GitHub/FreeRTOS-Emulator/lib/FreeRTOS_Kernel/portable/GCC/Posix/port.c:496

# 6 0x00007faa2f4524cf в файле start_thread () из / usr / lib .so.0

# 7 0x00007faa2efcd2d3 в clone () из /usr/lib/libc.so.6

Проблема заключается в том, что prvResumeThread не передан действительный идентификатор потока, как показано в # 1. Переходя к источникам FreeRTOS, я полагаю, что это не должно иметь место, так как при добавлении обработчика UDP и его соответствующей задачи создаются те же потоки, их добавление как-то приводит к тому, что pxCurrentTCB FreeRTOS становится недействительным при выполнении xTaskGetCurrentTaskHandle, который извлекает дескриптор потока для ошибочного вызова prvResumeThread в # 1 обратной трассировки. Изменение порядка создания задач приводит к той же ошибке, которая заставляет меня думать, что я имею дело с какой-то утечкой памяти, но, учитывая, что я не могу воспроизвести ошибку с помощью valgrind, я не уверен, как ее диагностировать.

Я беспокоюсь, что это похоже на пост «отладка моей программы», но я не уверен, какие методы или инструменты я могу использовать для дальнейшей диагностики, учитывая мой ограниченный опыт многопоточной отладки, и мне это нужно пу sh в правильном направлении.

Приветствия

...