Применение буферов больше 256 байт глючит sprintf, Камень stm32L476 Опции

[Димон Безпарольн...]

Почему при использовании буферов (у меня их 4) в разных местах размером больше 256 (ставил 400) начинает рассыпаться sprintf - выводит глюки.

В чем может быть проблема?

[x893]

Это ЧУДО !

[Димон Безпарольн...]

Чисто поржать - мне не до смеха. Есть какая специфика использования таких буферов?

[Lagman]

а буфер наверно объявлен как char с размером [0xff] и подаете вы туда utf8

[Димон Безпарольн...]

а буфер наверно объявлен как char с размером [0xff] и подаете вы туда utf8

Вовсе нет.

Буфер char buf[400]; и подаю я туда байты.

[aaarrr]

Есть какая специфика использования таких буферов?

Никакой. Накладываются, наверно, буферы на стек - и привет.

[jcxz]

Чисто поржать - мне не до смеха. Есть какая специфика использования таких буферов?

Вероятных причин может быть целая туча. А реальная вряд-ли связана со sprintf. Скорее баг у вас в другом месте.
Например: каков размера стека задачи, вызывающей sprintf?

PS: Не использую sprintf ни в одном из последних проектов....

[Димон Безпарольн...]

Например: каков размера стека задачи, вызывающей sprintf?

Как это узнать?

[aaarrr]

Как это узнать?

Традиционный способ такой:
1. Заполняем выделенную под стек память каким-нибудь паттерном (хоть бы и однобайтовым)
2. Вызываем интересующую процедуру
3. Смотрим, сколько памяти было "затерто"

[jcxz]

Как это узнать?

Это надо не узнавать. А задавать. У себя в исходниках. Если конечно писали их Вы....

3. Смотрим, сколько памяти было "затерто"

В некоторых случаях наблюдал как ..printf из IAR-овской библиотеки использовал до немного больше 256 байт стека.
Но это не при каждом вызове. Обычно - намного меньше. Так что "просто вызвать и посмотреть сколько потрёт" - тут не всегда сработает как надо.

[Димон Безпарольн...]

Традиционный способ такой:
1. Заполняем выделенную под стек память каким-нибудь паттерном (хоть бы и однобайтовым)
2. Вызываем интересующую процедуру
3. Смотрим, сколько памяти было "затерто"

Слишком сложно.

Даже если смогу, как изменить размер?

[aaarrr]

В некоторых случаях наблюдал как ..printf из IAR-овской библиотеки использовал до немного больше 256 байт стека.
Но это не при каждом вызове. Обычно - намного меньше. Так что "просто вызвать и посмотреть сколько потрёт" - тут не всегда сработает как надо.

Да форматированный ввод-вывод очень прожорлив. Смотреть, естественно, наиболее навороченные вызовы.

Слишком сложно.

Несколько строк кода.

Даже если смогу, как изменить размер?

Этот момент лучше выяснять задолго до введения нескольких буферов по 400 байт.

Кстати,

Буфер char buf[400]; и подаю я туда байты.

buf - не локальный часом?

[Димон Безпарольн...]

buf - не локальный часом?

Локальный. А что?

[jcxz]

Буфер char buf[400]; и подаю я туда байты.

buf - не локальный часом?

Это надо уже заносить в faq для чайников.

[Димон Безпарольн...]

Полагаю есть ограничение? Уж не 255 ли?

[aaarrr]

Полагаю есть ограничение? Уж не 255 ли?

Локальный буфер выделяется на стеке, еще здоровый кусок от него может откусить sprintf.
Ограничение определяется размером стека и только.

[Димон Безпарольн...]

Локальный буфер выделяется на стеке, еще здоровый кусок от него может откусить sprintf.
Ограничение определяется размером стека и только.

Похоже. У меня в sprintf строка в 290байт. Как это ограничение обойти?

Сообщение отредактировал Димон Безпарольный - Aug 22 2017, 21:44

[aaarrr]

Похоже. У меня в sprintf строка в 290байт. Как это ограничение обойти?

1. Увеличить размер стека

И еще постараться:
2. Не держать локальные буферы по полкилобайта
3. Не формировать sprintf'ом строки по 290 байт

Это весьма расточительно, если всей памяти десятки килобайт.

[Димон Безпарольн...]

1. Буду благодарен если намекнете как.

2,3 Что делать если надо сформировать строку:

{ "d" : {"deviceid":"<deviceid>","param5":"<dw>","param6":"<fullw> ",”param7”:”<kk>”,”param8”:”<diff>”,”param9”:”<maxt>” ,”param11”:”<mint>”,”param12”:”<msisdn>”,”param13”:”<imei>”,”param14”:”<mac>”,”param15”:”<ccid>”,”param16”:”<rmod>”,”param17”:”<ssid>”,”param18”:”<lin>”,,”param19”:”<uptime>”}}

Бред конечно - но не я диктую моду...

[aaarrr]

1. Буду благодарен если намекнете как.

Даже намекнуть не могу, так как это зависит от используемого инструментария,
структуры проекта и т.п., и по-хорошему должно быть известно только вам.

Посмотрите документацию на компилятор, там наверняка описан некий традиционный
способ установки размера стека. Сравните с тем, что имеете в своем проекте и
внесите коррективы.

Димон, складывается впечатление, что вы пытаетесь собрать что-то монструозное,
но при этом стараетесь обходить стороной фундаментальные основы. Не получится так

2,3 Что делать если надо сформировать строку:

Разделить её на кучу мелких по числу param.

[jcxz]

2,3 Что делать если надо сформировать строку:

Надо начать с вопроса: "А зачем её формировать в этом буфере"? И можно ли без этого обойтись?
Я вот тоже сейчас например в текущем проекте распарсиваю и формирую "модные" JSON-сообщения в несколько кБ (а возможно вырастут до сотен кБ), обходясь буферами в десятки-сотни байт. Без каких-либо проблем.

[Димон Безпарольн...]

Надо начать с вопроса: "А зачем её формировать в этом буфере"? И можно ли без этого обойтись?
Я вот тоже сейчас например в текущем проекте распарсиваю и формирую "модные" JSON-сообщения в несколько кБ (а возможно вырастут до сотен кБ), обходясь буферами в десятки-сотни байт. Без каких-либо проблем.

Парсить можно разбивая строку. Но это отправляемая строка. Она целиком должна быть запихнута в сериализатор и далее на отправку. Представить не могу как частями это сделать.

Заказчик очень хочет чтобы эта кишка не разбивалась.

[aaarrr]

Заполнять буфер тоже можно частями. Посмотрите, что возвращает функция sprintf.

[Димон Безпарольн...]

Заполнять буфер тоже можно частями. Посмотрите, что возвращает функция sprintf.

Согласен. Но буфер должен быть единым. Т.е. больше 256 байт. И локальным его не удается пока сделать. Сделал в лоб - объявил глобальным. Работает. Но не нравится нагрузка на память.

[aaarrr]

...локальным его не удается пока сделать. Сделал в лоб - объявил глобальным. Работает. Но не нравится нагрузка на память.

Есть такая вещь, как динамическое выделение памяти. Но применять его пока не советую, нужно сначала со стеками разобраться.

[jcxz]

Парсить можно разбивая строку. Но это отправляемая строка. Она целиком должна быть запихнута в сериализатор и далее на отправку. Представить не могу как частями это сделать.

Вот точно так же можно и отправляемую строку по частям напечатать. Я именно так и делаю. Писал выше. У меня строки размером до десятка кБ (а будут много больше). И печатают они в Ethernet-кадры, размер которых 576 байт

Согласен. Но буфер должен быть единым. Т.е. больше 256 байт.

Нет. Если включить голову, то печатать можно окнами через тот же ..printf.
И кучу тоже не использую - печать сразу в Ethernet-кадры.

[scifi]

Я правильно понял, что ТС не выяснил, сколько у него стека, и сколько его расходуется? И не планирует этим заниматься? Если так, помочь тут нечем, сушите вёсла.

[Димон Безпарольн...]

Я правильно понял, что ТС не выяснил, сколько у него стека, и сколько его расходуется? И не планирует этим заниматься? Если так, помочь тут нечем, сушите вёсла.

Ковырялся. Пока не получилось. Методику ищу, изучаю. Не факт что осилю.

й

И кучу тоже не использую - печать сразу в Ethernet-кадры.

Она сериализатором по частям не обрабатывается. Т.е. можно и свой сериализатор написать. Но боюсь времени не хватит.

[Михась]

Есть полезная штука по крайней мере у Кейла:
При компиляции опасные функции обрамляются ватермарком и при его повреждении - вызывается специальная функция.

http://www.keil.com/support/man/docs/armcc...59124940593.htm

[Aleksandr Barano...]

Если компилятор - IAR, то там есть встроенная функция контроля переполнения стека.

[Димон Безпарольн...]

Keil 5

[Димон Безпарольн...]

Пытаюсь работать с ключом --protect_stack

Вставил функцию:

Код

void *__stack_chk_guard;


void __stack_chk_fail(void)
{
    
}

Но виснет при обращении к массивам.

Сообщение отредактировал Димон Безпарольный - Aug 23 2017, 17:45

[jcxz]

При компиляции опасные функции обрамляются ватермарком и при его повреждении - вызывается специальная функция.

Малоэффективно. Вот пример перед глазами - случай автора топика: выставили ватермарк на 200 ниже SP перед входом в функцию, а автор взял и выделил в функции 400, (т.е. - начало этого массива оказалось на 200 байт ниже ватермарка) и напечатал в этот буфер скажем 150 байт - ватермарк остался нетронутым, а стек переполнился и затёр соседние данные (или они его).
Да и куда ставить этот ватермарк, если автор даже не знает размера своего стека??

[Михась]

Малоэффективно. Вот пример перед глазами - случай автора топика: выставили ватермарк на 200 ниже SP перед входом в функцию, а автор взял и выделил в функции 400, (т.е. - начало этого массива оказалось на 200 байт ниже ватермарка) и напечатал в этот буфер скажем 150 байт - ватермарк остался нетронутым, а стек переполнился и затёр соседние данные (или они его).

Эффективно как раз. У автора действительно тяжелый случай, но он явно выпаливается по внешним признакам. А --protect_stack как раз хорошо помогает, когда выделили для разных задач много маленьких буферов и потом в результате ошибки (не хватило пару байт потому что пролюбили пробел например) при печати в буфер портится соседнее значение, причем не каждый раз. И вот тут такое исключение чрезвычайно полезно. У меня раз такая ошибка в релизное ПО ушла. Одного чара в буфере не хватило.

[Михась]

Пытаюсь работать с ключом --protect_stack

Вставил функцию:

Код

void *__stack_chk_guard;


void __stack_chk_fail(void)
{
    
}

Но виснет при обращении к массивам.

Применяю так:

void * __stack_chk_guard = (void *)(0xDEADBEEF);

void __stack_chk_fail(void)
{
bitset(global_error, 10);
}

http://infocenter.arm.com/help/index.jsp?t...qs/ka16747.html



Сообщение отредактировал Михась - Aug 24 2017, 05:59

[alag57]

1. Буду благодарен если намекнете как.

startup_stm32l476xx.s

Stack_Size EQU 0x400;

[x893]

Можно включить автоматическое пошаговое выполнение и отслеживать значение SP.
Не быстро конечно, но можно отследить всё что происходит.
Можно взять Traseanalyzer или SystemView и им красивые картинки посмотреть как стэк.
Но пошаговый - это железобетонный способ.

[Димон Безпарольн...]

startup_stm32l476xx.s

Точно. Спасибо.