QSqlQuery+QThread = bad_alloc

[cdsmika]

Привет!
Выбираю из MSSQL через QODBC данных на 248 Мб (как показывает Management Studio) в память для обработки и пересыла по фтп.
Все замечательно, пока код в основном потоке. Стоит перенести в отдельный поток - валится bad_alloc.
Собственно интересно почему?

Написал тест:

Код:

void Thread::run()
{
    QSqlDatabase udb;
    udb = QSqlDatabase::addDatabase( "QODBC", "conn" );
    udb.setDatabaseName( "Driver={SQL Server Native Client 10.0};Server=(local);Database=ks;UID=sa;PWD=1;" );
    udb.open();

    QStringList l;

    QSqlQuery query( udb );
    query.setForwardOnly(true);
    query.prepare("EXEC dbo.get_initial_data '56FEB471-37A7-494E-AF87-8FC03174C74F'");
    query.exec();

    while (query.next())
    {
        l.append(query.value(1).toString());
    }
}

[cdsmika]

Даже вот так уже bad_alloc:

Код:

void Thread::run()
{
    QString l;

    while (l.length() < 200000000)
    {
        l.append("1111111111111");
    }
}

[cdsmika]

Win 7 x64 + Qt 4.8.4

[Hellraiser]

А ~400 Мб не многовато для стековой переменной?

[OKTA]

Тут больше интересно, почему валится, а не то, что многовато 
Кода бы увидеть побольше!

[cdsmika]

А ~400 Мб не многовато для стековой переменной?

как узнать многовато или нет?

[cdsmika]

Тут больше интересно, почему валится, а не то, что многовато 
Кода бы увидеть побольше!

а это собственно весь код)

[Bepec]

Ничего не вылетает. Спокойно завершается поток, потолок потребления памяти примерно 550 мб. Видимо у вас где-то что-то ещё.

[m_ax]

А ~400 Мб не многовато для стековой переменной?

как узнать многовато или нет?

Это не имеет отношения к делу..

QString - это фактически контейнер, который при расширении (из-за ваших постоянных append ов) пытается аллоцировать себе новый блок памяти.. Видимо вы уже до того её дефрагментировали, что такого цельного куска просто нет, вот он кидает bad_alloc.  

[cdsmika]

А ~400 Мб не многовато для стековой переменной?

как узнать многовато или нет?

Это не имеет отношения к делу..

QString - это фактически контейнер, который при расширении (из-за ваших постоянных append ов) пытается аллоцировать себе новый блок памяти.. Видимо вы уже до того её дефрагментировали, что такого цельного куска просто нет, вот он кидает bad_alloc.  

Я пробовал аллоцировать и цельный кусок ) Результат тот же. Как понять тогда влезет кусок или нет?

[OKTA]

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

[m_ax]

Как понять тогда влезет кусок или нет?

Ну как-как.. Если исключение не кинет, значит влезет, а ели кинет, то значит нет)

Ловите исключения и решайте сами, как на это реагировать..

[cdsmika]

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

По нынешним меркам разве огромные? Да для среднего сервака это ж пшик)

[OKTA]

Для сервака, сколько бы "планок" в нем не стояло, требования к производительности и маленькому потреблению памяти еще выше и жестче.
И дело не в нынешних мерках, а в хороших программах. Если руководствоваться при программировании мнением, что "ну на всех нынешних компах памяти больше гига, так что можно смело отхватить пару сотен метров", то это приведет к тому в итоге, что программа будет работать криво, а зачастую вообще не будет работать, если по каким-то причинам памяти ей не хватит свободной. Надо работать с тем, что дает система, а не с тем, что "да все компы мощные уже, везде уверен будет работать" 

[Bepec]

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

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