VPF::непонятки с памятью. - Форум программистов

wils0n

Дата 15.2.2006, 13:03 (ссылка)

(нет голосов)

Загрузка ...

Новичок

Профиль
Группа: Участник
Сообщений: 12
Регистрация: 15.2.2006

Репутация: нет
Всего: 1

не понятно, что происходит с памятью. Помогите, пожалуйста, разобраться.
Есть след. код:

Код


#include<iostream>
#include<list>
#include<windows.h>

using namespace std;

void memavail()
{
    MEMORYSTATUS lpBuffer;
    GlobalMemoryStatus(&lpBuffer);
    cout << lpBuffer.dwAvailPhys << endl;
}

struct Cell {
    long prim;
    long order;
    Cell() : prim(), order() {};
    Cell(long p, long ord) : prim(p), order(ord) {};
    ~Cell() {}
    Cell operator = (const Cell &cell) {return Cell(cell.prim, cell.order);}
};

int main()
{
        time_t t1,t2;
        time(&t1);
    memavail();
    typedef list<Cell*> List;
    List* t = new List();
    for (long i=0;i<15000000;i++) {
        try {
            Cell* cell = new Cell();
            t->push_back(cell);
            if (i % 100 == 0) memavail();
        } catch(...) {
            cout << "Out of memory" << endl;
            throw;
        }
    }
    memavail();
    for (long i=0;i<15000000;i++) {
        List::iterator node = t->begin();
        delete(*node);
        t->erase(node);
    }
    memavail();
    delete t,
    memavail();
    time(&t2);
    t2 = t2 - t1;
    std::cout << "Time : " << t2 << std::endl;            
    return 0;
}

Программа вылетает при количестве свободной памяти около 140мб. При запуске программы было свобоно около 550 мб.
Вылетает, не замечая try...catch с сообщением

Цитата

6 [main] a 2368 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
1365 [main] a 2368 open_stackdumpfile: Dumping stack trace to a.exe.stackdump

Почему?

Цитата("stackdump")

Exception: STATUS_ACCESS_VIOLATION at eip=610C4914
eax=00000000 ebx=00040000 ecx=00010000 edx=00000000 esi=611A38A0 edi=00000000
ebp=0022EA58 esp=0022EA4C program=D:\pitt\eclipse\testing\a.exe, pid 2368, thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
0022EA58 610C4914 (00000000, 611A38A0, 00040000, 2AF10000)
0022EA98 6100275E (00000000, 00000000, 00000000, 00000000)
0022EAC8 61050C8E (61155E78, FFFFFFFF, 00004A48, 00000001)
0022EBD8 610516E4 (00000000, 00001000, 00000001, 00000022)
0022EC08 61051F79 (00000000, 00001000, 00000003, 00000022)
0022ECA8 610AB36C (00000003, 0022ECF8, 0022ECD8, 0040F9C1)
0022ECD8 6104ED0A (0000000C, FFFFFFFF, 7C809F8A, 6109B4FE)
0022ED38 610844FF (0000000C, 0022ED94, 0022ED68, 004311F9)
0022ED48 0041109E (006A20D0, 00000001, 00000000, 0022EE84)
0022ED68 004311F9 (006A20D0, DF0DF047, 00000000, 00000000)
0022EDD8 0043AEAB (006A20D0, 0022EEB8, 0022EE18, 610A49B5)
0022EDF8 0043B014 (006A20D0, 006A20D0, 0022EEB8, 00000004)
0022EE18 0043B059 (006A20D0, 0022EEB8, 00000000, 004011BD)
0022EEF8 0040130D (00000001, 006A0168, 006A0090, 6111E673)
0022EFD8 61004DD2 (0022EFF0, 002402D8, 00000080, 0022F020)
0022FF88 6100594F (00000000, 00000000, 00000000, 00000000)
End of stack trace (more stack frames may be present)

Компилятор: g++ 3.4.4
Среда: ВинХР (cygwin)

SergeanTSID

Дата 19.2.2006, 00:56 (ссылка)

(нет голосов)

Загрузка ...

Новичок

Профиль
Группа: Участник
Сообщений: 5
Регистрация: 12.1.2006
Где: Беларусь, Брест

Репутация: нет
Всего: нет

У меня на Microsoft Visual C++ 6.0, после незначительных поправок (под компиллер), все откомпилилось, запустилось... потом доматало до 4038656 и после этого "Out of memory". Т.е. твой try ...catch успешно сработал.

Так что, в компиляторе своем можешь искать причину...

Mayk

Дата 19.2.2006, 08:02 (ссылка)

(нет голосов)

Загрузка ...

^аВаТаР^ сообщение>>

Профиль
Группа: Участник
Сообщений: 2616
Регистрация: 22.5.2005
Где: за границей разум а

Репутация: 45
Всего: 134

не знаю как там память выделяется в [cyg]win'е, в lnx по схожему поводу сказано

Цитата

BUGS
By default, Linux follows an optimistic memory allocation strategy. This means that when malloc()
returns non-NULL there is no guarantee that the memory really is available. This is a really bad bug.
In case it turns out that the system is out of memory, one or more processes will be killed by the
infamous OOM killer.

Цитата(SergeanTSID @ 19.2.2006, 04:56

)

Так что, в компиляторе своем можешь искать причину...

У меня нет gcc 3.4/cygwin,
но вот gcc 3.3/lnx и gcc 4.0/lnx вполне успешно либо ловят исключение(если отключить эту optimistic memory allocation strategy) либо убиваются (захватив с собой на тот свет еще пару приложений, бугага) отнюдь не по вине компилера
(правда для того, чтобы программа вылетала, пришлось размер cell'а увеличить на 10000 char'ов)

Это сообщение отредактировал(а) Mayk - 19.2.2006, 08:04

--------------------

Здесь был кролик. Но его убили.
Человеки < кроликов, йа считаю.

0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема \| C/C++: Общие вопросы \| Следующая тема »