Господа, кто-нибудь сталкивался с проблемой, когда сообщения которые выводятся посредством printf()теряются?
Суть проблемы в следующем:
Тестирование некоторого компонента проекта производится путем анализа его консольных сообщений.
А в течение одной тестовой сессии в одном тестовом цикле присутствует весь блок вывода, а в другом — некоторые строки теряются а вместо них пустые строки.
Note: Система очень ebedded.
Здравствуйте, Poomba, Вы писали:
P>Доброго времени суток.
P>Господа, кто-нибудь сталкивался с проблемой, когда сообщения которые выводятся посредством printf()теряются? P>Суть проблемы в следующем: P>Тестирование некоторого компонента проекта производится путем анализа его консольных сообщений. P>А в течение одной тестовой сессии в одном тестовом цикле присутствует весь блок вывода, а в другом — некоторые строки теряются а вместо них пустые строки. P>Note: Система очень ebedded.
Иногда такое бывает когда спецификатор типа в параменте printf не соответствует реальному типу печатаемого параметра.
Здравствуйте, Poomba, Вы писали:
P>Суть проблемы в следующем: P>Тестирование некоторого компонента проекта производится путем анализа его консольных сообщений. P>А в течение одной тестовой сессии в одном тестовом цикле присутствует весь блок вывода, а в другом — некоторые строки теряются а вместо них пустые строки. P>Note: Система очень ebedded.
Так навскидку -- похоже на проблемы многопоточности. У вас эти сообщения из одного потока выводятся (или задачи или какие там термины в вашей embedded системе)?
А может банальная ошибка в механизме вывода. У нас вот за время сопровождения одной embedded системы три разных человека три раза делали кольцевой буфер (для разных нужд), и каждый раз при wrap-around'е терялся байтик, на отлов чего тратилось от недели до месяца.
А ещё, если у вас вывод идёт через последовательный порт, проверьте настройки (baud rate, битность-чётность-flow control). Мало ли.
Всё. На большее без дополнительных данных фантазии не хватает.
Здравствуйте, Poomba, Вы писали:
P>Note: Система очень ebedded.
Стоило бы назвать, что это за система.
А вообще, никто не обещает ни атомарности, ни потокобезопасности printf (и других функций вывода) в один FILE.
Соответственно, если какой-то второй поток решит параллельно что-то вывести на экран, то возможны любые спецэффекты.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Poomba, Вы писали:
P>>Note: Система очень ebedded. К>Стоило бы назвать, что это за система.
К>А вообще, никто не обещает ни атомарности, ни потокобезопасности printf (и других функций вывода) в один FILE. К>Соответственно, если какой-то второй поток решит параллельно что-то вывести на экран, то возможны любые спецэффекты.
Система таки-да многопоточная.
Описание примерно следующее:
бортовой компьютер для а\м
архитектура SH4
ОС QNX RTOS 630 SP номера не припомню.
Есть очень "специфический" фреймворк, на котором базируется аппликация, и который собственно и диктует архитектуру приложения.
В нашем случае это Model Oriented и Component based.
На счет issue: предлагаете сделать обертку для printf и защитить вывод в STDOUT скажем мутексом?
Накладных расходов будет...
Здравствуйте, quodum, Вы писали:
Q>Здравствуйте, Poomba, Вы писали:
P>>Суть проблемы в следующем: P>>Тестирование некоторого компонента проекта производится путем анализа его консольных сообщений. P>>А в течение одной тестовой сессии в одном тестовом цикле присутствует весь блок вывода, а в другом — некоторые строки теряются а вместо них пустые строки. P>>Note: Система очень ebedded.
Q>Так навскидку -- похоже на проблемы многопоточности. У вас эти сообщения из одного потока выводятся (или задачи или какие там термины в вашей embedded системе)?
да, похоже на то. Вывод осуществляется из различных потоков, а если "пошаманить" то и процессов. Но это не суть важно, мысль понял, спасибо.
Q>А может банальная ошибка в механизме вывода. У нас вот за время сопровождения одной embedded системы три разных человека три раза делали кольцевой буфер (для разных нужд), и каждый раз при wrap-around'е терялся байтик, на отлов чего тратилось от недели до месяца.
Ring Buffers — это наше все! Но похоже не в этом дело.
Q>А ещё, если у вас вывод идёт через последовательный порт, проверьте настройки (baud rate, битность-чётность-flow control). Мало ли.
Q>Всё. На большее без дополнительных данных фантазии не хватает.
Здравствуйте, Poomba, Вы писали:
P>На счет issue: предлагаете сделать обертку для printf и защитить вывод в STDOUT скажем мутексом? P>Накладных расходов будет...
Хочешь сказать, что в куниксе дорогие мутексы?
Коллизии, может быть, и дорогие, а сами мутексы дешёвые. Иначе бы там все бамбук курили.
Ну хорошо, если профайлер покажет, что это дорого — напиши дешёвый и глупый мутекс на спинлоке.
Хотя printf — сам по себе очень дорогое удовольствие, перед которым мутекс — ерунда.
А нельзя ли как-то переделать архитектуру, так, чтобы за логи и экран отвечал отдельный сервис, и этот сервис сериализовал бы всю работу по выводу?
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Poomba, Вы писали:
P>>На счет issue: предлагаете сделать обертку для printf и защитить вывод в STDOUT скажем мутексом? P>>Накладных расходов будет...
К>Хочешь сказать, что в куниксе дорогие мутексы? К>Коллизии, может быть, и дорогие, а сами мутексы дешёвые. Иначе бы там все бамбук курили.
К>Ну хорошо, если профайлер покажет, что это дорого — напиши дешёвый и глупый мутекс на спинлоке. К>Хотя printf — сам по себе очень дорогое удовольствие, перед которым мутекс — ерунда.
Ок, попробую, спасибо.
К>А нельзя ли как-то переделать архитектуру, так, чтобы за логи и экран отвечал отдельный сервис, и этот сервис сериализовал бы всю работу по выводу?
Есть такой У этого сервиса есть несколько каналов, но мне было сказано что они все уже заняты, и надо имплементить новый для тебя.И вообще мы тут вам не склад trace-ов. А ты уверен что больше ничего сделать нельзя?(Если честно я сам не понимаю в чем проблема: добавить еще один listener-поток не могут что ли?) НУ и я честно полез в матчасть. Просто раньше спецэффектов с принтфами не наблюдалось и все было гуд. А тут повылазило.
Перекуём баги на фичи!
