Почему вектор c ++ вызывает oom-killer?

Код должен находить и обрабатывать файлы, которые еще не были обработаны во встроенном Linux.
getDir используется для возврата отсортированного содержимого каталога.
Приведенный ниже код отлично работает после обработки нескольких десятков или, возможно, более 100 файлов, но затем умирает с помощью oom-killer.
Это плохой способ использовать векторы c ++ (вектор цикла внутри вектора цикла)?
Может ли этот метод быть причиной убийцы?
Есть ли другой подход, который может работать, не взорвавшись?
Разве каждый вектор не должен быть уничтожен, поскольку он выходит за рамки?
Нужно ли использовать new / delete?
Также: valgrind для обнаружения утечек памяти не интегрирован в SDK для этого процессора (TI DM368), но код очень короткий и нет новых операторов. Примечание: фактический код проверяет базу данных sql на наличие файлов, которые уже были обработаны, но этот код все еще вызывает oom-killer с закомментированным кодом sql, поэтому он был оставлен для простоты. Формат пути к файлу /YYYYmmdd/HH/MMSS.SS.ext.

void getDir (string dir, vector<string> &files) {
...
while ((dirp = readdir(dp)) != NULL) {
files.push_back(string(dirp->d_name));
closedir(dp);
sort(files.begin(), files.end());

while (true) {
vector<string> days;
getDir(database_location, days);
for (uint d=0; d<days.size(); d++) {
vector<string> hours;
getDir(database_location+days[d], hours);
for (uint h=0; h<hours.size(); h++) {
vector<string> files;
string dir = database_location+days[d]+"/"+hours[h];
getDir(dir, files);
for (uint f=0; f<files.size(); f++) process(dir, files[f]);

0

Решение

  1. Linux OOM killer общеизвестно тупой. По умолчанию не начинайте обвинять свой собственный код.
  2. У вас есть только три вектора, разумных размеров. (Если размер вектора неоправдан, это может быть связано с тем, что количество файлов в одном каталоге также неоправданно).
  3. Вам не нужно new/delete,

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

2

Другие решения

Чтобы сэкономить память, вы можете попробовать использовать строка :: shrink_to_fit () а также вектор :: shrink_to_fit когда каждая строка или вектор достигают своего окончательного размера (но, конечно, не перед этим).

Другое дело может быть, не собираюсь hours сначала к вектору, если это очень длинный вектор, вместо этого обрабатывайте каждую запись каталога, когда вы ее читаете, и сортируйте все позже как-нибудь.

0

По вопросам рекламы [email protected]