strdup и копирование строк: ловушки указателей

Логгер на даче писал в журнал на SD-карте имена сенсоров вместе с показаниями: «bme280, 21.4», «ds18b20, 19.9». Имена я доставал из документа привычным чтением — const char* name = doc["name"]; — и передавал прямо в функцию записи на карту. Месяц всё работало безупречно, потому что пакет разбирался один раз при включении и жил в глобальном документе до самого конца. Потом мне понадобилось менять список сенсоров без перепрошивки, и я добавил перечитывание пакета раз в десять минут. Через сутки в журнале началась абракадабра: вместо bme280 — обрывки нового ответа, куски ключей, иногда пустые строки на месте имён.

Данные в документе были верные, показания тоже — врвало только имя. Вскрытие заняло вечер: const char* из документа — это не копия строки, а адрес внутри неё. Перечитывание перезаписало пул документа, старые байты ушли под новые данные, а мои указатели продолжали показывать на то же место — где теперь лежало что-то другое. Библиотека не могла меня предупредить: с её точки зрения всё честно, строка принадлежит документу, а не мне.

В этом уроке разберём, где физически живут строки после разбора, какие три события их убивают, как снять копию тремя способами — String, фиксированный буфер, strdup — и сколько каждый стоит в байтах. Механику чтения со страховками мы уже проходили в уроке про оператор | и containsKey — там я вскользь упомянул висящий указатель; здесь добираемся до дна, потому что на живом узле эта тема стоит не часов отладки, а поездок на дачу.

ArduinoJson не хранит строки там, где их нашёл в исходном тексте пакета. При разборе библиотека копирует текст в свой пул — ту же область памяти, где лежат слоты ключей и чисел, мы разбирали её устройство в уроке про JsonDocument. Чтение doc["name"] возвращает const char* — адрес внутри этого пула. Пока документ жив и не переписан, адрес честный: строку можно печатать, сравнивать, передавать в функции. Но владелец — документ, а не ваша переменная: указатель даёт доступ, но не гарантию.

Строку убивают три события, и все три в обычном скетче случаются регулярно. Первое — doc.clear(): пул освобождён целиком, адреса умерли все сразу. Второе — повторный deserializeJson в тот же документ: перед разбором библиотека сбрасывает пул сама, мы это проверяли вживую в уроке про первый deserializeJson — и это самый коварный случай, потому что выглядит безобидно: «ну я же просто новый пакет разобрал». Третье — выход локального документа из области видимости: JsonDocument doc; объявленный внутри функции, умирает на закрывающей скобке, и все адреса, которые вы из него вынесли, повисают в воздухе.

Отсюда правило владения, которое я теперь пишу даже в комментариях к коду: строка из документа живёт ровно до следующего события в жизни документа. Нужна дольше — снимайте копию в момент разбора, не откладывая на потом. Отложите — получите мой дачный журнал с обрывками вместо имён, причём через сутки после того, как вы уехали.

strdup(s) делает ровно две вещи: выделяет в куче strlen(s) + 1 байт — под текст и терминатор — и копирует строку туда. Возвращает указатель на копию, которая больше никак не связана с документом: чистите doc, переразбирайте, выходите из функции — копия стоит на месте. Это функция из стандартной библиотеки Си, на Arduino она доступна из коробки вместе с free(), которой копию положено возвращать куче, когда она стала не нужна.

Цена измеряется байтами и дисциплиной. Строка «meteo1» стоит 7 байт — шесть символов и терминатор; ничего, пока free() не забыт. Забытый strdup — утечка по расписанию: узел, который strdup-ит имя города раз в минуту без освобождения, съедает 1440 строк в сутки по 10–15 байт — около 19 КБ в сутки. На Uno с её 2 КБ SRAM куча умирает за пару часов, и я однажды собрал именно такой скетч — историю свежести имен в логе он рассказывал два часа, потом молчал навсегда. На ESP32 с сотнями килобайт кучи те же 19 КБ в сутки приведут к перезапуску через пару недель непрерывной работы — дольше, но так же гарантированно.

Моё мнение с условием: strdup я пишу, когда строк может быть много и они разной длины — списки имён, история сообщений. Для одного-двух полей конфига выгоднее фиксированный буфер: место известно на компиляции, куча не участвует вовсе, утечать нечему. А String(city) — путь короткий и удобный, но каждый повторный присвоение String перевыделяет память в куче; в уроке про сравнение String-склейки мы считали, чем это кончается на Uno при жизни скетча месяцами. Для единственного присвоения при старте — нормально, для цикла раз в минуту — нет.

Как поймать утечку до того, как она поймает вас. На ESP32 печатайте ESP.getFreeHeap() раз в минуту в лог: падение с 300 тысяч байт на старте до 280 тысяч к вечеру рисует траекторию, по которой утечка видна за день, а не за месяц. На Uno счётчика кучи нет, зато есть характерное поведение: скетч, отработавший два часа и начавший молчать без причины, почти всегда кончил в куче — фрагментация или полное опустошение выглядят снаружи одинаково. Второй приём — дисциплина пары: каждый strdup в коде получает свой free() до выхода из той же ветки, а пар в скетче должно быть так мало, чтобы проверить их глазами за минуту. Пять пар — проверяемо, двадцать — уже миграция на буферы.

Всё сказанное сворачивается в один вопрос, который я задаю себе у каждого чтения строки из документа: сколько эта строка проживёт? Если она нужна внутри той же ветки кода — напечатали, сравнили, отдали на экран — указатель легален и копировать нечего. Если она переживёт паузу между пакетами — журнал, экран после перерисовки, имя узла в MQTT-топике — копия обязательна, и снимать её надо в момент разбора, пока документ ещё держит оригинал.

Компромиссный вариант для конфигов, которые читаются один раз при включении: глобальный документ плюс глобальные указатели, как в самом первом скетче этого раздела. Это работает ровно до тех пор, пока документ никто не трогает; я ставлю рядом комментарий «doc дальше не переразбирать» — и в моём опыте нарушают его дважды: сам автор через полгода и коллега через месяц. Копия дешевле поездки на дачу.

В симуляторе ниже механика показана честно, с одной оговоркой: в движке книги любая строка — копия, поэтому подвисание указателя не показать, он всегда честно напечатает старое значение. Зато разница «ключ исчез из документа, копия осталась» видна вживую: смотрите, как doc.city меняется на новый город, doc.temp обнуляется вместе с исчезнувшим ключом, а kopiya_city держит первоначальное значение сколько угодно пакетов.

И одно предупреждение про симулятор и плату сразу: копия в моём примере — String, а не char-массив, потому что в симе строковые методы и присвоения работают одинаково. Перенося скетч на Uno, вы можете оставить String — для копии, снятой один раз при старте, это безопасно, — но последний эксперимент из четвёрки ниже предлагает заменить её на буфер: разница между двумя способами останется только на настоящей плате, где куча видна по поведению, а не по учебнику.

Домашнее задание с платой: возьмите любой свой скетч, где строки из документа переживают цикл loop, найдите их честным вопросом «сколько проживёт?» и переведите на буфер или strdup с free(). Проверьте себя удвоением пакета: разберите в тот же doc второй JSON и убедитесь, что копии напечатались без изменений. А где строки приходят не готовой пачкой, а по одному символу из порта — следующая тема: соберём JSON из потока Serial и сделаем разбор, который не боится медленного соседа, — JSON через UART.