caxapa.ru :: Писал три месяца проект, писал.. тот внезапно перестал работать....

POV_ (06.12.2019 09:42, просмотров: 41052)

Писал три месяца проект, писал.. тот внезапно перестал работать.... GCC 6 В одном из мест один из многочисленных вызовов sprintf валит прогу. Оптимизация -Oz убрала ошибку. Но это же нехорошо, хотелось бы понимания косяка. Что опытные товарищи по гцц могут подсказать?

- В функции RxTx(554 знак., 08.12.2019 00:29)
  - Что за ересь?! С чего бы у меня был использован один и тот же буфер?.. POV_(70 знак., 08.12.2019 11:49, )
  - "buffer у тебя глобальная переменная" - Где? - VLLV(08.12.2019 08:23)
    - POV_ код ниже приводил. - RxTx(09.12.2019 14:16)
  - Беда, коль пироги начнет печи сапожник, Ruslan(290 знак., 08.12.2019 07:31)
  - спасибо! ТС так и вылечил -> - Evgeny_CD(08.12.2019 00:46, ссылка)
    - Мне показалось он "вылечил", а сделал перестановку кроватей. ;-) - RxTx(08.12.2019 00:56)
      - Мне кажется, что суть этого важного глюка до нас еще толком не дошла. Evgeny_CD(82 знак., 08.12.2019 01:51)
        
        "Важный глюк" - фантазия. "Многопоточность может случиться в однопоточной системе" - заблужение. "Очень поучительно" - фантазия. Молодец, возьми с полки пирожок. - SciFi(08.12.2019 11:20)
        
        Нет ли тут интересного... POV_(73 знак., 09.12.2019 11:53, )
        
        Вызов вложенной функции - всего лишь несколько байт стека. - VLLV(09.12.2019 12:16)
        
        А вызов одной и той же функции в иерархии вызовов несколько раз - многопоточность в однопоточном приложении. И если эта функция не реентерабельна, то вылет. - Evgeny_CD(09.12.2019 14:12)
        
        Ну ты же понял что там происходит. sprintf() ожидает что её %s параметр (его char* буфер) имеет ожидаемую ей длину. RxTx(655 знак., 09.12.2019 16:10)
        
        Ты как "баба - сам придумал, сам - обиделся". Нет никакой печати в тот же буфер! Глаза промой наконец. - POV_(09.12.2019 17:02, )
        
        Ты покажи весь код и полностью. А не набрасывай на вентилятор по кусочкам. Очевидно, что у тебя ошибка (мол gcc настолько кривая паделка, что ты гениальный программист сразу вляпался -- слишком сомнительно, там ошибки обычно сильно другого плана), fk0(626 знак., 09.12.2019 23:44)
        
        Языком СИ написано (см. ссыль в теле). Где там общий буфер?... POV_(222 знак., 09.12.2019 23:50, )
        
        В psu_GetField(psuNOMINAL_VOUT) буфер аргументом не передается стало быть он внутри общий про что вам и пишут. Помещайте полный исходник или его тестовый эквивалент где проявляется баг если полный нельзя. - 3m(10.12.2019 10:40)
        
        Не надо просто придумывать. Исходные данные - всё работало. Т.е. никакого одного буфера нет. Похер как оно внутри psu_GetField. - POV_(10.12.2019 12:53, )
        
        Но они вызываются последовательно. - VLLV(10.12.2019 10:48)
        
        "порядок вычисления аргументов функции в языке c/c++ строго не определен" - 3m(10.12.2019 10:57)
        
        ОК, не последовательно, пусть в инверсном порядке, но ведь не все одновременно? - VLLV(10.12.2019 11:06)
        
        Имеет место баг спрятанный под коврик. Не надо думать, что ты такой уникум со своей игрушечной программкой, что раз и баг нашёл. Мог конечно, но это примерно как выиграть в лотерею. Нужно очень много играть, проект с миллионом строк, например. Не fk0(400 знак., 09.12.2019 23:58)
        
        В проекте с миллионом строк , сотней больше ошибок сотней меньше , рабочий процесс. PlainUser(58 знак., 11.12.2019 11:44)
        
        Если ошибка завершается сегфолтом, то она смертельная для любого проекта. Вдогонку, а тут коллега такой баг интересный разгребал: выравнивание стека. Портит его одна функция и в одно время, дальше всё работает какое-то время пока не столкнётся с fk0(641 знак., 11.12.2019 12:56 - 13:01)
        
        Так это обычное дело для любой системы , 100% проверок сделать невозможно.Авторы выбирают некое разумно-достаточное с их(или заказчика , что реже) точки зрения количество проверок. - PlainUser(20.12.2019 08:00)
        
        Ты чего дурака-то включаешь? Я ж ясно тут отписался уже.. POV_(622 знак., 10.12.2019 08:56, )
        
        Дохтур, у меня в глазах постоянно темнеет... Ну что вы мне пульс меряете... Вы мне зрение проверьте!!! - il-2(10.12.2019 11:14)
        
        Дурака включаешь ты и реально не догоняешь даже. Смотри, вариант 1: fk0(1456 знак., 10.12.2019 11:10)
        
        И чего я не так сказал? - POV_(10.12.2019 12:55, )
        
        "В сишнике все переменные выносятся в начло функции где бы ты их не объявил". Что это было? О_о. Мне кажется, в твоих представлениях о сишнике имеются заблуждения. - SciFi(10.12.2019 09:47)
        
        Опция -fstack-reuse=level, с самого верху... кому-то может быть познавательно. - fk0(10.12.2019 11:13, ссылка)
        
        При оптимизации временные переменные просто в регистрах, ессно реюзаных. Стек используется меньше, вот и объяснение (одно из). - VLLV(10.12.2019 11:47)
        
        Вы все обкуренные и не лечитесь. Невозможно устроить рекурсивный вызов sprintf(). По буквам: николай, елена, владимир, олег, зинаида, михаил, ольга, жозефина, нина, оксана. Как этот простой факт ускользает от здешней публики - для меня загадка. - SciFi(09.12.2019 14:17)
        
        Пока туда не влезет оптимизатор. - Boвa(09.12.2019 17:22)
        
        Куда? В stdio? - VLLV(09.12.2019 18:17)
        
        +++ - Гудвин(09.12.2019 17:07)
        
        Мной выше говорилось только о ситуации по ссылке, не нужно обобщать. - VLLV(09.12.2019 14:50)
- попробуйте выровнять буфер на 8 байт(aligned(8)). Было что то подобное. - Mikla(06.12.2019 17:46)
- Когда я вижу без ошибок написанную нереентрантную функцию, на которую жалуются "что-то странно она себя ведет", то сразу возникает вопрос: откуда она у тебя вызывается? Если из разных потоков и обработчиков - то буратино найден :-) - il-2(06.12.2019 14:30)
- Может, не в тему. Всегда (если в библиотеке есть) вместо sprintf использую snprintf. От переполнений стека, правда, это не спасает. - Сидоргек(06.12.2019 11:26)
- sprintf может валить прогу, если 1) аргументы не соответствуют строке формата (в частности опасно использование "%n"), 2) нижележащие функции, через которые printf (без s) печатает, вызывают ошибку, 3) если это sprintf и переполняется буфер... fk0(2051 знак., 06.12.2019 10:50)
  - Зачетно , местами гениально! - PlainUser(09.12.2019 15:25)
  - +100500 за valgrind. При компиляции в режиме отладки утилита показывает стек вызовов с именами функций и номерами строк. Уйму блох отловил этим полезным инструментом. - =AlexD=(06.12.2019 11:58)
  - Варнинги проверял, snprintf пробовал, строку подставлял фиксированную без параметров. Валится всегда в одном и том же месте. Ниже я описал где... POV_(23 знак., 06.12.2019 11:41, )
  - Спасибо! Душевно. - Evgeny_CD(06.12.2019 11:06)
  - Вдогонку, в embedded ещё встречаются проблемы с распечаткой чисел с плавающей точкой -- в процессоре может не быть fpu, а в библиотеке используется, или наоборот и разный ABI (call convention), если библиотеки какие-то экзотические, то могут плохо fk0(34 знак., 06.12.2019 10:54)
    - Плавучку не использую. Валится как раз на моей функции, которая из float печатает число используя %d. - POV_(06.12.2019 11:42, )
      - ЕМНИП, в GCC при нулевой оптимизации по дефолту -fno-strict-aliasing, а при остальных - наоборот - -fstrict-aliasing - Vit(09.12.2019 21:42)
      - "Плавучку не" не противоречит "из float печатает" ? - VLLV(06.12.2019 11:48)
        
        Не использую плавучку в sprintf - POV_(06.12.2019 11:53, )
        
        я float перед sprintf всегда превращаю в целое (зная где у меня там запятая стоит). И всё нормально - Лагунов(06.12.2019 12:46)
        
        Да это-то тут причем?... POV_(740 знак., 06.12.2019 13:40, )
        
        1) заменяли только первый sprintf ? или все четыре sprintf на sprintf(this_buf, "blyat!") sprintf(this_buf, "blyat 2!") sprintf(this_buf, "blyat 3!") sprintf(this_buf, "blyat 4!"). ? Zoro(257 знак., 06.12.2019 14:06)
        
        Да, пофиг на (int)f. Я туда и чисто инт без преобразования подставлял. - POV_(06.12.2019 14:13, )
        
        Может еще в линкерном скрипте какая то лажа, наезд на неиспользуемую область и твое "blyat!" оказывается там где царство вечной неопределенности. - ASDFS(06.12.2019 13:45)
- Опытные товарищи берут в зубы отладчик и ищут косяк. - SciFi(06.12.2019 09:46)
  - Так оно уходит в никуда при пошаговой работе. Соседние строчки с тем же sprintf норм работают. - POV_(06.12.2019 09:49, )
    - Чехарда в адресной арифметике ? К примеру: Есть массив из 10 элементов, а делается запись в 11-ый. Результат: затёрта память в соседней переменой. "Чудный" результат. Был обнаружен при смене компилятора (или по другому выполнял линковку). - Zoro(06.12.2019 10:42)
      - Не, такого что нет. А вот что есть... POV_(228 знак., 06.12.2019 11:39, )
        
        default может добавить？ в Винавр помогало。 - Symbions(06.12.2019 13:24)
        
        бубен эффективнее - SciFi(06.12.2019 13:31)
        
        Нет, но не помешает попробовать Symbions(35 знак., 06.12.2019 17:47 - 17:49)
        
        Не нашёл, а спрятал. SciFi(50 знак., 06.12.2019 17:50, ссылка)
        
        В дизассемблере по шагам пройдись. Указатель стека проверь. - SciFi(06.12.2019 11:48)
        
        В общем сам "дурак", дал шанс компилятору при оптимизации повертеть меня на херу... POV_(534 знак., 06.12.2019 15:11, )
        
        Основной вопрос в этом коде - это где хранится результат внутренних sprintf после возвращения из функции psu_GetField. Ведь переменным bb присваиваются указатели на некий буфер. Если это глобальный буфер, то последовательные вызовы psu_GetField PSP(148 знак., 08.12.2019 20:28)
        
        Там всё в порядке - POV_(08.12.2019 21:40, )
        
        Проблема при вложенности функций указывает в первую очередь на проблему со стеком. - VLLV(07.12.2019 05:00)
        
        про вложенность --> - SciFi(07.12.2019 13:44, ссылка)
        
        Автор пишет черным по черному: "Внутри psu_GetField есть свой sprintf, а то и два" - VLLV(07.12.2019 14:58)
        
        Предлагаю подумать на тему "как в рамках одного потока осуществить вложенный вызов sprintf?" SciFi(35 знак., 07.12.2019 15:33)
        
        С одной стороны - торможу, земляные работы отбили разум. А с другой стороны ... ну неужели расход стека не зависит от действий программиста? - VLLV(07.12.2019 16:02)
        
        Зависит. Он и от настроек оптимизации зависит. Но поциент упорно игнорирует этот факт. Кто ж ему дохтур? - SciFi(07.12.2019 16:35)
        
        Да ничего я не игнорирую. Я ж не говорю "гцц косячит". Просто крайне редко сталкивался с зависимостью работы компилятора от космических флуктуаций. - POV_(07.12.2019 16:39, )
        
        Современные оптимизирующие компиляторы -- коварны. Они могут видеть, что ты написал какую-то лажу. Понимать это, по своему, мол код всё равно не работает, и нагенерировать в итоге что-то другое. При этом ни слова не скажут. Видеть могут глубоко, fk0(41 знак., 09.12.2019 23:52)
        
        Оптимист. Ежели -flto, то видят вообще всё. - SciFi(10.12.2019 00:09)
        
        Я сталкивался. Потом находил косяки в своём коде. Например, что-то где-то гадит в чужие переменные. Через косячную адресную арифметику или ещё как-то. Всего и не упомню. - SciFi(07.12.2019 16:41)
        
        А внутри psu_GetField, когда вызывается sprintf, он печатает случайно не в ту же статическую переменную, в которую печать происходит в той функции, где глюки были обнаружены? Тогда чего же ты хочешь? snprintf начинает читать из буфера и fk0(771 знак., 06.12.2019 20:21)
        
        есть у меня подозрения, что либа со спринтфом настолько "однопоточная", что там даже просто для sprintfa используется какая-нить static переменная, в которой, например, хранится счётчик выведенных байт. в итоге при вложении спринтфов вложеннные Mahagam(128 знак., 07.12.2019 12:36)
        
        Где там вложенность? sprintf вызывается последовательно жи. Как вообще организовать "вложенный вызов sprintf" в одном потоке? Хочу всё знать. - SciFi(07.12.2019 12:46)
        
        читайте внимательно что пишет ТС, там как раз есть вложенность - Mahagam(07.12.2019 12:58, ссылка)
        
        Прочитал. Вложенности не увидел. Если что, аргументы вычисляются не во время, а до вызова функции. И не одновременно, а по очереди. То есть тот рефакторинг по сути не изменил ничего. - SciFi(07.12.2019 13:35)
        
        Нет, там массив "строк". А именно 5 штук. И вызывается не более 3 за раз... POV_(115 знак., 07.12.2019 02:05, )
        
        Но почему при присваивании возвращаемых psu_GetField значений временным переменным эффект пропал? Хотя вопрос, откуда psu_GetField берёт буфер для sprintf, весьма уместен. - йцукен(06.12.2019 22:07)
        
        А что буфер? Выполнение последовательное, никто никому не мешает. Выдумки, короче. - SciFi(06.12.2019 22:20)
        
        Может и выдумки, но поскольку я в чудеса не верю, должно быть материальное объяснение. Вынеся вызовы psu_GetField из вызова sprintf в отдельные строчки, ТС (возможно) изменил порядок, в котором следуют эти вызовы. Поскольку внутренности йцукен(100 знак., 06.12.2019 23:31)
        
        Как можно вернуть (const char*) из функции в C? Варианты: 1) указатель на локальную переменную, 2) общий для всех static, 3) утечка памяти. Последний вариант наименее взрывоопасный. - fk0(06.12.2019 23:38)
        
        Содержимое буфера передаётся в printf не по значению, а по ссылке. В итоге когда функция печатает в тот же буфер, который является одним из аргументов -- аргумент рискует стать бесконечным. Там конечно начинаются ньюансы. Считает ли sprintf внутри fk0(394 знак., 06.12.2019 22:34 - 22:38, ссылка)
        
        Может и туплю, но как именно это объясняет глюки? - SciFi(06.12.2019 15:19)
        
        Ну он как-то наоптимизировал одинаковые куски кода... POV_(205 знак., 06.12.2019 15:28, )
        
        Приговор такой: вменяемое объяснение не найдено, багу удалось временно замести под ковёр, потом вылезет в другом месте. - SciFi(06.12.2019 15:36)
        
        Ну это да.. - POV_(06.12.2019 17:25, )
        
        Это уж в понедельник. Пройдусь по асму. - POV_(06.12.2019 13:34, )
        
        а мне тут говорили, как крут gcc, все предупреждения. Ни фига он не умеет против погроммиста) - VLLV(06.12.2019 11:55)
        
        Придется, но ассемблер егойный не знаю, читать придется. - POV_(06.12.2019 11:54, )
        
        Ассемблера испугался. Найди в тырнете чит-лист на одну страницу, повесь перед носом. Ничего особенного там нет. - SciFi(06.12.2019 12:06)
        
        Да хрен с ним, ассемблером, вначале стек. Дерево вызовов, указатель, локальные переменные... Переместить этот свич в другое место, там работает? - VLLV(06.12.2019 12:00)
      - Это частный случай "неопределённого поведения". В таких случаях gcc временами делает такое, что глаза на лоб лезут. А что? Имеет право. - SciFi(06.12.2019 10:48)
    - Такая ерунда не может остановить опытных товарищей. - SciFi(06.12.2019 09:52)
    - Стек кончился? - ASDFS(06.12.2019 09:52)
      - Параллельного ничего нет. Разве что stdlib кривая. - POV_(06.12.2019 09:54, )
        
        А зачем что-то параллельное, чтобы завалить стек? Одного sprintf и достаточно. - VLLV(06.12.2019 10:58)

Микроконтроллеры