проблемы с new delete

А как она умирает-то? Симптомы какие?

прогу прибивает сам линукс. Виртуальный менеджер памяти (если я правильно понял :) ) выводит сообщение что все, каюк проге, и делает ей kill.

И что заставляет тебя думать что нет memory leak'ов?

утечек нет. проверялось всякими программами и т.д. top тоже не показывает что течет. прога падает в разное время при остальных равных условиях. Если вместо new delete использовать malloc free то все ОК. где грабли?

Чудес, к сожалению, не бывает, так что грабли наверное все-таки в коде. Лики по топу найти не всегда просто -- понятно, что они могут идти не постоянно, а при наступлении какого-либо события. Можно вот что попробовать: замени в OOM killer'е посылку SIGKILL на SIGABORT, после чего разглядывай кору.

2liom: btw, компилятор какой? и это, не может так случайно получиться, что памяти new не хватает? попробуй ловить bad_alloc? и еще, можно попробовать выделять malloc'om а потом использовать new с синтаксисом размещения :)

2asd: а как сие сделать?

2asd: а как сие сделать?


Это сделать легко: в /usr/src/linux/mm/oom_kill.c:oom_kill_task()
заменить force_sig(SIGKILL, p) на force_sig(SIGABORT, p).
Только толку от этого не будет никакого, така как core-file будет
размером, примерно, RAM+swap :))

Виноват, сразу смайлики ставить надо было...

2asd: щютник мля :) хотя что в наше время 1GB файл :) другое дело, что 2GB близко, btw, как в линухе ворочать файлами >=2GB ? :)

PS. интересно, сколько gdb будет такой файл переваривать?!? :)))

Понимаешь в чем дело, gdb на той же машине этот файл не переварит -- так-как памяти не хватит. А если про файлы больше 2Gb -- посмотри, какой размер у тебя у off_t и все станет ясно.
А потом попробуй:

char c = '!';
int fd = open("/tmp/big.file", O_CREAT|O_TRUNC|O_WRONLY);
lseek(fd, 2030*1024*1024, SEEK_SET);
write(fd, &c, 1);
close(fd);

Если программа не шибко много движений делает (вызовов), то попробуй strace -f имя программы > porgram.log

2saper:

И что? Вызовы brk() потом считать?

2asd: Нет, смотреть хотя бы на каком вызове завалился...

Интервал падения одинаков?

После определенного количества вызовов падает или как?

И еще: если у вас RedHat(RPM система или свое ядро) попробуйте (это просто совет, no flame wars) взять готовое ядро от slackware(ну или вашего дистрибутива, на крайний, если используете не его же) с базовыми функциями для вашего железа - чтобы грузилось и работал хотя бы один процессор, потом проверьте упадет ли на нем.

> 2asd: Нет, смотреть хотя бы на каком вызове завалился...

2saper: Если посмотреть в начало треда, то становится понятно,
что процесс прибивается OOM killer'ом. OOM killer вызывается при исчерпании памяти. В данной ситуации налицо memory leak'и, которые проявляются быстрее, при использовании new/delete чем mallic/free.

А ядро тут совершенно не причем :))

падает всегда через разные промежутки времени. Когда через день а когда через трое суток. Ядро на падучесть не влияет. Библиотеки С/С++ тоже. Компилятор тоже. Тем не менне если переопределить операторы new и delete на malloc free то работает все стабильно! Уже месяц как крутится. В сказки сам не верю! :)

Ты бы поганял бы прогу на другой машине без OOM килера.

Скажи пожалуйста версию ядра/linux. А то у нас есть тоже более-менее похожая проблема: машина: 2PIII-800, 1.5 GB OS: RH 6.2, ядро 2.2.14, glibc 2.1.3

Есть много малосвязанных программ. Все юзают stl, iostreams и все ПАДАЮТ через некоторое время при интенсивной работе с памятью причем чуем, что clash где-то между stl и iostream НА многопроцессорной машине(большое подозрение что с strstream). Никто не сталкивался с данной проблемой ?

Еще: 1. Где можно найти самые свежие update для glibc для rh 6.2 ? 2. Что лучше с т.з. стабильности : rh 6.2 или 7.2 (и вообще - если сравнивать разные клоны linux) ?

Машина Aтлон 1200, 256 мозгов, Линукс Мандрейк 8.0, ядра пробовал разные всякие от 2.2.10 до 2.4.13. libc не помню, компиляторы разные пробовал.