Народ помогите решить проблему:
Есть DLL скомпилированная в релиз (исходников нет).
В процессе работы в результате ошибки с динамической памятью возникает прерывание INT 3.
При этом ошибка не влияет на общую работоспособность библиотеки.
Возможно как либо заблокировать данное прерывание для продолжения
работы приложения использующее данную библиотеку.
Подойдет любой самый грязный хак.

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

OD>Народ помогите решить проблему:
OD>Есть DLL скомпилированная в релиз (исходников нет).
OD>В процессе работы в результате ошибки с динамической памятью возникает прерывание INT 3.
OD>При этом ошибка не влияет на общую работоспособность библиотеки.
OD>Возможно как либо заблокировать данное прерывание для продолжения
OD>работы приложения использующее данную библиотеку.
OD>Подойдет любой самый грязный хак.

Очень похоже на работу assert'a внутри CRT при разрушении внутренней структуры кучи.
Боюсь, что просто продолжением работы после этого можно сделать ещё хуже.
Нужно смотреть на выходы за границы выделенной памяти, двойное освобождение участков памяти, использование памяти после освобождения.
Возможно, нужно посмотреть на соответствие рантаймов своего приложения и этой сторонней DLL'ки.

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

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

OD>>Народ помогите решить проблему:
OD>>Есть DLL скомпилированная в релиз (исходников нет).
OD>>В процессе работы в результате ошибки с динамической памятью возникает прерывание INT 3.
OD>>При этом ошибка не влияет на общую работоспособность библиотеки.
OD>>Возможно как либо заблокировать данное прерывание для продолжения
OD>>работы приложения использующее данную библиотеку.
OD>>Подойдет любой самый грязный хак.

MQ>Очень похоже на работу assert'a внутри CRT при разрушении внутренней структуры кучи.
assert() в релизе? или имеется в виду "что-то типа assert" ?

Здравствуйте, McQwerty, Вы писали:
MQ>Очень похоже на работу assert'a внутри CRT при разрушении внутренней структуры кучи.
Возможно,если учесть что DLL писалась на С++.
MQ>Боюсь, что просто продолжением работы после этого можно сделать ещё хуже.
Как не странно, этого не происходит.При возникновении прерывания выводится окошко Windows с выбором действия
(завершить, отладить) и отладчик без проблем дает сигнал на продолжение работы.
MQ>Нужно смотреть на выходы за границы выделенной памяти, двойное освобождение участков памяти, использование памяти после освобождения.
Исходников DLL нет в природе.

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

OD>Здравствуйте, McQwerty, Вы писали:
MQ>>Очень похоже на работу assert'a внутри CRT при разрушении внутренней структуры кучи.
OD>Возможно,если учесть что DLL писалась на С++.
MQ>>Боюсь, что просто продолжением работы после этого можно сделать ещё хуже.
OD>Как не странно, этого не происходит.При возникновении прерывания выводится окошко Windows с выбором действия
OD>(завершить, отладить) и отладчик без проблем дает сигнал на продолжение работы.
MQ>>Нужно смотреть на выходы за границы выделенной памяти, двойное освобождение участков памяти, использование памяти после освобождения.
OD>Исходников DLL нет в природе.

Тогда попробовать что-то типа такого (инструкцию "int 3" таким образом можно обойти):

#include "stdafx.h"

void dll_func ()
{
    printf ("--- f.1 ---\n");
    RaiseException (EXCEPTION_BREAKPOINT, 0, 0, 0);
    printf ("--- f.2---\n");
} // dll_func

int main(int argc, char* argv[])
{
    printf ("--- 1 ---\n");

    __try
    {
        printf ("--- 2 ---\n");
        dll_func ();
        printf ("--- 3 ---\n");
    }
    __except
    (
        GetExceptionCode () == EXCEPTION_BREAKPOINT ?
            (
                (GetExceptionInformation ()) -> ContextRecord -> Eip ++,
                EXCEPTION_CONTINUE_EXECUTION
            ) :
            EXCEPTION_CONTINUE_SEARCH
    )
    {
        printf ("--- 4 ---\n");
    }

    printf ("--- 5 ---\n");

    return 0;
}

Выхлоп:

--- 1 ---
--- 2 ---
--- f.1 ---
--- f.2---
--- 3 ---
--- 5 ---

PS: Винда, интел, 32 бит.

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

OD>>>Есть DLL скомпилированная в релиз (исходников нет).
OD>>>В процессе работы в результате ошибки с динамической памятью возникает прерывание INT 3.
MQ>>Очень похоже на работу assert'a внутри CRT при разрушении внутренней структуры кучи.
B>assert() в релизе? или имеется в виду "что-то типа assert" ?
Да, "что-то типа". Исключение при повреждении управляющих структур кучи.
Хотя на линуксе у меня были случаи именно assert'a. Потом какой-то патч glibc'a это исправил.

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

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

OD>>>>Есть DLL скомпилированная в релиз (исходников нет).
OD>>>>В процессе работы в результате ошибки с динамической памятью возникает прерывание INT 3.
MQ>>>Очень похоже на работу assert'a внутри CRT при разрушении внутренней структуры кучи.
B>>assert() в релизе? или имеется в виду "что-то типа assert" ?
MQ>Да, "что-то типа". Исключение при повреждении управляющих структур кучи.
MQ>Хотя на линуксе у меня были случаи именно assert'a. Потом какой-то патч glibc'a это исправил.

ИМХО, автору нужно запустить какой-то профайлер и посмотреть не расстреливает ли он сам память.
Если не расстреливает и проблема в библиотеке — тогда уже извращаться.

Не прокатит приложение использующее библиотеку чисто С.Так что возможности MFC тут не сильно помогут.

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

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

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

OD>>>>>Есть DLL скомпилированная в релиз (исходников нет).
OD>>>>>В процессе работы в результате ошибки с динамической памятью возникает прерывание INT 3.
MQ>>>>Очень похоже на работу assert'a внутри CRT при разрушении внутренней структуры кучи.
B>>>assert() в релизе? или имеется в виду "что-то типа assert" ?
MQ>>Да, "что-то типа". Исключение при повреждении управляющих структур кучи.
MQ>>Хотя на линуксе у меня были случаи именно assert'a. Потом какой-то патч glibc'a это исправил.

B>ИМХО, автору нужно запустить какой-то профайлер и посмотреть не расстреливает ли он сам память.
B>Если не расстреливает и проблема в библиотеке — тогда уже извращаться.
Расстрел идет точно в библиотеке и как я выяснил расстреливается объект уничтожаемый в штатном режиме после оного.

Здравствуйте, Аноним, Вы писали:

А>Не прокатит приложение использующее библиотеку чисто С.Так что возможности MFC тут не сильно помогут.

Ну вот "грязный хак" может быть сведён к написанию промежуточной библиотеки на C++.

Здравствуйте, Аноним, Вы писали:

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

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

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

OD>>>>>>Есть DLL скомпилированная в релиз (исходников нет).
OD>>>>>>В процессе работы в результате ошибки с динамической памятью возникает прерывание INT 3.
MQ>>>>>Очень похоже на работу assert'a внутри CRT при разрушении внутренней структуры кучи.
B>>>>assert() в релизе? или имеется в виду "что-то типа assert" ?
MQ>>>Да, "что-то типа". Исключение при повреждении управляющих структур кучи.
MQ>>>Хотя на линуксе у меня были случаи именно assert'a. Потом какой-то патч glibc'a это исправил.

B>>ИМХО, автору нужно запустить какой-то профайлер и посмотреть не расстреливает ли он сам память.
B>>Если не расстреливает и проблема в библиотеке — тогда уже извращаться.
А>Расстрел идет точно в библиотеке и как я выяснил расстреливается объект уничтожаемый в штатном режиме после оного.

а можно попроще рассказать?
вы уверены, что при удалени какого-то объекта портится память другого и в этом виновата именно библиотека?

Здравствуйте, Аноним, Вы писали:

А>Не прокатит приложение использующее библиотеку чисто С.Так что возможности MFC тут не сильно помогут.

Эм... А где там MFC?

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

Попробуй так:

LONG WINAPI ExceptionFilter(PEXCEPTION_POINTERS info) {

  EXCEPTION_RECORD SavedExceptRec=*info->ExceptionRecord;
  CONTEXT cnt=*info->ContextRecord;

  switch(SavedExceptRec.ExceptionCode) {
  case EXCEPTION_ACCESS_VIOLATION:
    // ...
    break;
  case EXCEPTION_BREAKPOINT:
    // ваш int 3 прилетит сюда
    break;
  }
  // говорим дескать все ништяк сопаем дальше
  return EXCEPTION_CONTINUE_EXECUTION;
}

// Желательно ставить это дело только на время
// И в последствии восстанавливать оригинал
::SetUnhandledExceptionFilter(ExceptionFilter);

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

_>Попробуй так:
_>

_>LONG WINAPI ExceptionFilter(PEXCEPTION_POINTERS info) {
_>  switch(SavedExceptRec.ExceptionCode) {
_>  case EXCEPTION_BREAKPOINT:
_>    // ваш int 3 прилетит сюда
_>    break;
_>  }
_>  // говорим дескать все ништяк сопаем дальше
_>  return EXCEPTION_CONTINUE_EXECUTION;
_>}

_>// Желательно ставить это дело только на время
_>// И в последствии восстанавливать оригинал
_>::SetUnhandledExceptionFilter(ExceptionFilter);

Этого недостаточно. После EXCEPTION_CONTINUE_EXECUTION управление вернётся на всё тот же "int 3". Соответственно будет возбуждено ещё одно исключение. И так по кругу. Для того, чтобы избежать этого в фильтре нужно поправить контекст так, чтобы следующей исполняемой инструкцией стала не "int 3". Сама эта инструкция для intel'a занимает 1 байт, на который и нужно поправить регистр eip.

On 16.02.2011 13:33, blackhearted wrote:

> MQ>Очень похоже на работу assert'a внутри CRT при разрушении внутренней
> структуры кучи.
> assert() в релизе? или имеется в виду "что-то типа assert" ?

А откуда вы знаете что он в релизе ?
Может и не в релизе. Автор всё равно исходников не имеет, а CRL может
быть влинкована внутрь.

А может это VERIFY.

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

MZ>On 16.02.2011 13:33, blackhearted wrote:

>> MQ>Очень похоже на работу assert'a внутри CRT при разрушении внутренней
>> структуры кучи.
>> assert() в релизе? или имеется в виду "что-то типа assert" ?

MZ>А откуда вы знаете что он в релизе ?
MZ>Может и не в релизе. Автор всё равно исходников не имеет, а CRL может
MZ>быть влинкована внутрь.

MZ>А может это VERIFY.

я вижу это из сообщения автора.

Есть DLL скомпилированная в релиз (исходников нет).

хм...

Автор: OmegaDelta
Дата: 16.02.11

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

Q>Здравствуйте, Аноним, Вы писали:

А>>Не прокатит приложение использующее библиотеку чисто С.Так что возможности MFC тут не сильно помогут.

Q>Эм... А где там MFC?
Блин попутал.Там идет "stdafx.h", а это "use this precompiled header".

Здравствуйте, blackhearted, Вы писали:
B>а можно попроще рассказать?
B>вы уверены, что при удалени какого-то объекта портится память другого и в этом виновата именно библиотека?
Абсолютно,для тестирования было создано приложение в котором просто нечему испортить память,и к нему была подключена эта библиотека , прерывание ждало на том же самом месте после нескольких часов работы программы.

Здравствуйте, OmegaDelta, Вы писали:
OD>Народ помогите решить проблему:
OD>Есть DLL скомпилированная в релиз (исходников нет).
OD>В процессе работы в результате ошибки с динамической памятью возникает прерывание INT 3.

Не загружайте библиотеку в своё приложение, а используйте отдельный дочерний процесс, который и загрузит её. В случае ошибки погибнет не главное приложение, а служебный процесс, который потом можно будет при необходимости создать снова.

Извините, что это не грязный хак.

OD>Как не странно, этого не происходит.При возникновении прерывания выводится окошко Windows с выбором действия
OD>(завершить, отладить) и отладчик без проблем дает сигнал на продолжение работы.
Если вы "работу продолжите" — то еще через некоторое время вы скорее всего схлопочете еще AV, а то и какой нить хитро-логический глюк и будете думать-гадать откуда оно взялось, а уже поздняк дампиться/дебажиться.
Фиксите работу с памятью и/или длл. К примеру, если вы юзаете эту длл из разных потоков — имеет смысл проверить является ли она потокобезопасной и если нет — синхронизировать все обращения к ней.