Добрый день!

Достался по наследству проект ActiveX написанный на C++ (Visual Studio 6.0 sp5) с использованием ATL и библиотеки Object Grid 8.01.
ActiveX представляет собой grid, используемый на web страницах. Данные в grid передаются в виде xml. Он данные обрабатывает и соответствующим образом заполняет/конфигурирует grid.
Столкнулся с проблемой: после определенного порогового объема данных ActiveX обрушивает Internet Explorer. При этом никаких сообщений пользователю не выдается, окно браузера тихо закрывается.

Отладка показала две ситуации при которых падает браузер:
1. в определенной ситуации оператор new поднимает исключение CMemoryException. При этом объем памяти процесса iexplorer.exe составляет порядка 100М (т.е. физической памяти предостаточно). Написал обработчик этого исключения. Это исправило данную ситуацию, но появилась другая.
2. в определенной ситуации возникает SEH исключение Access Violation. Перехватить данное исключение никак не удается: Visual Studia говорит Unhandled Exception. (перехватить его при помощи catch(...) не получается)

Ситуация осложняется еще те, что есть подозрения на то что ошибка в библиотеке Object Grid и исправить ее не удастся. Поэтому, хотелось хотя бы обойти ошибку.

Сам я новичок в c++ поэтому прошу отнестись снисходительно.
Подскажите:
1. Есть ли в IE какие-либо ограничения на потребляемую ActiveX кучу и стек? Можно ли каким то образом подсказать IE, что для моего ActiveX нужно больше кучи и больше стек?
2. Каким образом перехватывать SEH исключение Access Violation? .

И, знатоки C++, будьте добры, подскажите, куда в подобной ситуации копать.

Здравствуйте, vladgolovkov, Вы писали:

V>1. в определенной ситуации оператор new поднимает исключение CMemoryException.

Это исключение бросается не из самого оператора new, а из недр конструктора. Надо смотреть, что там происходит.

V> При этом объем памяти процесса iexplorer.exe составляет порядка 100М (т.е. физической памяти предостаточно).

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

V> Написал обработчик этого исключения. Это исправило данную ситуацию, но появилась другая.

Надо не обрабатывать исключение, а поймать за руку, откуда оно вылетает. Для этого нужно в Студии Debug -> Exceptions, и у С++ных исключений включить Break Always.

V>2. в определенной ситуации возникает SEH исключение Access Violation.

Природа может быть та же самая: попытка прочесть строку (или что-то ещё) по мусорному указателю. Только в этот раз не повезло, залезли на защищённую страницу памяти.


V> Перехватить данное исключение никак не удается: Visual Studia говорит Unhandled Exception. (перехватить его при помощи catch(...) не получается)

Это совершенно другой механизм, пенпердикулярный С++ным исключениям.
Для его обработки нужно или писать __try-__finally / __try-__except, или транслировать в обычное С++ное исключение (см. _set_se_translator).


V>Ситуация осложняется еще те, что есть подозрения на то что ошибка в библиотеке Object Grid и исправить ее не удастся. Поэтому, хотелось хотя бы обойти ошибку.

Может сработать принцип Garbage In — Garbage Out.
Убедись, что ты не подсовываешь в Грид мусорные значения; не разрушаешь переданные туда собственные объекты (event sink'и); не деинициализируешь COM (CoUninitialize) и т.д.


V>И, знатоки C++, будьте добры, подскажите, куда в подобной ситуации копать.

Поставить Bounds Checker или подобные ему мегаотладчики, и поискать, где у тебя в программе происходят криминальные вещи: неинициализированные переменные и всё такое.
Хотя его параноидальные сообщения — это испытание для нервов. Узнаешь много нового про недра MFC, ATL и даже WinAPI.