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

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

Это ЧУДО !

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

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

Вовсе нет.

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

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

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

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

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

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

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


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

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

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

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


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


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

Кстати,

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

Keil 5

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

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



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

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

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

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



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

startup_stm32l476xx.s

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

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