Здравствуйте
Столкнулся с такой проблемой: В ARM ядре из-под Linux пишу текстовый файл CSV формата на внешнюю SDHC карту, отформатированной в FAT32. Как только размер файла на диске становится примерно 39МБайт программа аварийно завершается и в файле вместо последних нескольких записей мусор. Проверял, на утечки памяти, не обнаружил, не может ли это быть связано с каким-то кэшированием?
Запись в файл идет на фоне обмена с DSP ядром через DSPLINK

Файл открываю так
resultFile = open(name, O_RDWR | O_CREAT | O_APPEND, 0640);
Записываю
test_a = write(resultFile, rec_buf, strlen(rec_buf));


Не сталкивался кто-нибудь с такой ситуацией?

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

широкополосно:
- отключите на время обмен с DSP, если перестанет валиться, то копаете в том направление
- в линуксе из под того же пользователя командой dd сгенерите запись файла допустим 100МБ на тот носитель (SDHC)
- в своей софтине добавьте отладочный блок с записью в отдельный файл транзакций рабочих записей, хотя бы rec_buf, strlen(rec_buf) и объем свободной системной памяти
- как вариант, ошибка в исходниках, например, открываете файл, пишете и не закрываете, банальная утечка..

Проверил, сделал простой тест
rec_len =2800;
char rec_buf[4096];

resultFile = open(name, O_RDWR | O_CREAT | O_APPEND, 0640);

while(dsp_message_count<30000)
{
test_a = write(resultFile, rec_buf, rec_len);
printf("Write to file = %d,%d,%d\n",test_a, resultFile, dsp_message_count);
//usleep(100000);
dsp_message_count +=1;
}

close(resultFile);


Посмотрел расход памяти, пока файл пишется свободная память уменьшается, но когда приложение перестает работать, т.е. отрабатывает close(resultFile); и приложение закрывается, объем свободной памяти не восстанавливается, это правильная работа?

Расход памяти смотрел через вторую консоль free -b

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

Просто мне кажется странным, что памяти расходуется примерно половина объема.
Нет ли по этой причине наползания на память другой программы?
А функция close не предполагает очистку буферов?

Чем больше памяти отдается на кэширование, тем легче живется системе.


Только в случае неправильной конфигурации памяти: в какой-то момент расширяющийся кэш перекрывается
с памятью DSP. До этого момента все как бы в порядке.


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

Конфигурацию памяти я взял из документации, собственно там сказано, что linux эти адреса не использует. И в примерах SDK конфигурируется именно это адресное пространство. А если как-то принудительно очищать кэш или ограничить его размер?
Просто судя по статистике расхода памяти память в примере, описанном выше расходуется с 108 МБ до 21МБ.

Надо сопоставить, что передается ядру в mem=, и что прописано в конфигурации DSP/BIOS.

Посмотрю, но все-таки по поводу расхода памяти. Просто мне надо писать несколько суток непрерывно, и крутится еще несколько программ, вот до какого момента будет кэшироваться?

Дисковый кэш - это не есть прямой расход памяти. Как только она понадобится "для дела", то освободится.

Это скорее очистка буфера не предполагает отдачу его памяти в системный пул. Может отдавать, а может и нет. В зависимости от реализации.

Посмотрел - длины и начальные адреса совпадают

Извиняюсь, невнимательно посчитал адреса, действительно в конфинурации DSPLINK зарезервирован диапазон адресов 0xC3E00000-0xC4000000, а в DSP 0xC3E00000-0xC4001000, видимо в этом причина

Так резервировать надо в одном файле. Например - командном файле линкёра. Чтобы не было подобных чудес.