MSVC 6 SP6/ PharLap

Такая засада: оператор new возвращает NULL Чтобы это могло быть?
До конструктора не доходит, HeapAlloc выдает NULL
Интересно то, что, если прога идет по другой ветке, то все ок.

интересно

насчет HeapAlloc -а это debug-ом выяснялось или пробовал сам HeapAlloc вызывать???

можно задать параметр HEAP_GENERATE_EXCEPTIONS, и посмотреть...вместо возвращения NULL он выдаст exception...

Может, немного кода ?
Ну очень трудно догадаться. Здесь new тоже NULL

Это сообщение отредактировал(а) threef - 30.1.2006, 18:51

Более 4-х лет боевого опыта. Не бывает такого
Добавлено @ 00:57
bel_nikita, а ты не массив пытаешься создать?

Бывает оказывается возвращает нуль У меня, как-то был похожий трабл, реально памяти нехватало, но тут свободной 250 МБ. Но самое непонятное, то что по одной ветке программы все работает, по-другой нет.
А код совершенно безобидный:

Минимальный код воспроизодящий ошибку сделать нереально насколько я понимаю.

operator new переопределен?

Попробуй полный ребилд, может дебугер нсовсем то отображает

А какое вообще право имеет new возвращать NULL???

Если я не ошибаюсь, по стандарту он ОБЯЗАН вызывать исключение. Или я чего-то недопонял?

Насчет самой проблемы - не бывало.

Возвращать NULL - это фича MSVC

Как насчёт того, чтобы переопределить new самому таким образом, чтобы он кидал исключения?

new...


Возвращать NULL- это фича new.
Честно говоря, если у тебя new для CObject не переопределен, то неясно, как он возвращает NULL. У меня не получилось

это вовсе не фича new, это фича new(nothrow).
Стандарт 2003. Параграф 5.3.4. Пункт 13.

Иными словами - обычный new либо возвращает не null, либо кидает исключение.

Это сообщение отредактировал(а) Mayk - 31.1.2006, 16:50

Где то читал , что это настраивается компилятором, что делать, или нулл возвращать или исключение кидать.

Стандарт - это, конечно, хорошо, но не в идеальном мире живем...
Насколько я помню, в 6й студии была такая опция - NULL возвращать или исключение кидать.
Вот как и где она включается - не помню - то ли что-то вызвать надо, то ли просто опция в проекте или слово волшебное для препроцессора... Короче, попробуй поискать в MSDN (именно том, что для этой студии) по словам new, set_new_handler и т.д. (просто чтобы понять - что же у тебя включено).

Тем не менее, очень странно, что возвращает NULL (не 256 mb твой объект ведь)... Попробуй сходить внутрь отладчиком.

Кажется, new может вернуть NULL, если просят 0 байтов... Чудно, конечно, но надо бы проверить, чего там в той ветке компилятор накомпилировал...

Что за ветки ты имеешь ввиду?

Сваливается событие в глобальную очередь, потом парсится:

Происходит инициализация диспетчера:
А вот, соббственно и проблемная "зона":

Покопался в дебаге. NULL вылает метод HeapAlloc.

Это сообщение отредактировал(а) bel_nikita - 31.1.2006, 18:44

Почитай в MSDN насчет HeapAlloc. Она может возвращать 0 в двух случаях: если нет памяти, или если хип поврежден. Полагаю, дело во-втором.
Как я поняла, один и тот же код (ParseCreationXMLFile) у тебя то работает, то нет, в зависимости от того, по какой ветви идет выполнение? Так проверь как следует ветку, в которой рушится. Посмотри функции HeapValidate, HeapQueryInformation, HeapWalk.

А может скобки убрать при объявлении?

Скобки там, конечно, не нужны, но вряд ли это они производят такой разрушительный эффект на хип

А хто знает? шестая ведь...

многопоточность используется?

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


Да, используется. до 15 потоков.

bel_nikita, Здесь обсуждается похожая проблема. Я честно пытался понять до конца, так как самому интересно стало, но ... Быть может, так как ты занимаешься своей проблемой уже определённое время, то приведённые советы будут яснее :
http://groups.google.ru/group/microsoft.pu...892c08b35aac700

Добавлено @ 22:39
Попробуй, что бы было ясно что дело не в outofmemory.
Добавлено @ 22:40
А класс CXMLRead самописный? Может трабла в его конструкторе?

у HeapCreate есть один флажок: HEAP_NO_SERIALIZE
возможно, по каким-то причинам он устанавливается
правда, не знаю, как это проверить - никогда не сталкивался с необходимостью узнать параметры кучи
если все-таки это так (может, где-то по умолчанию стояло однопоточное приложение), то я вижу три варианта:
1. для каждого потока сделать свою кучу (ну мало ли)
2. найти способ убрать флаг HEAP_NO_SERIALIZE, еслине ошибаюсь, этим занимается CRT...
3. использовать HeapLock и HeapUnlock

Попробуй HeapValidate. Во-первых, вызови его перез самым new. Если он скажет, что хип порушен, начинай искать, где, с помощью тех же вызовов HeapValidate.

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

Никак не удается найти

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

Вот, такой дефайн пробывал вставлять, чтоб отловить куски, где хип "бью".

Но сейчас "покапался" в линкере и нашел переменную stack. Увеличил до 32768 и ... Ура! Работает!... Вроде

У тебя там что, рекурсивные вызовы есть, что стека не хватает? Или такие прикольные локальные переменные?
Интересно, а stack общий для всех потоков, или каждому свой?

А мне бы как раз такой необычный new не помешал. Из приведенной цитаты стандарта понятно, что вроде можно это сделать, но не понятно, как... Мож, подскажете?

, одно не понятно: стек и хип разные вещи, как это могло сработать...???

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

, тогда словил бы exception о том, что стек переполнен, так причем тут куча?

И правда...
А может, он не смог это исключение кинуть, поскольку оно создается в стеке, а он переполнен?
Или сам new использует локальные переменные зачем-то, и в этом проблема? Тоже сильно сомнительно...

Стандарт гарантирует что в стеке всегда будет место для этого исключения.