Ошибка access violation no rtti data

We are running Inventor 2023, all updates/drivers are current for all software, Anti virus security has been setup with allowable permissions and so on . It is vary clear that Inventor is the problem. This seems to be Autodesks go to for fixing issues just blame other software products. 

Basically you have a rather large multi body , the customer decides they want to change the design. So when you start altering the geometry you get a lot of broken features in the feature tree that needs to be repaired. You roll back the EOF and start repairing features . Some features you don’t need so you delete them up till the RTTI error pops up.

It happens quite regularly so yes the error can be reproduced consistently. 

The work around is, once the error pops up,  is to save the file, shut down Inventor, restart Inventor, open the file and then you are able to keep rolling down the EOF fixing the broken features.

If en.cppreference.com’s explanation of The Standard can be trusted, I think this is an error in MSVC:

1. When dynamic_cast is used in a constructor or a destructor (directly or indirectly), and expression refers to the object that’s currently under construction/destruction, the object is considered to be the most derived object. If new-type is not a pointer or reference to the constructor’s/destructor’s own class or one of its bases, the behavior is undefined.

As far as I can tell, the problematic cases are being called from the constructors of classes that the dynamic_cast is trying to cast newComposite into. This should be perfectly acceptable, unless I’m misunderstanding something.

But supposing this is an MSVC problem that we need to accommodate, the only solution I can think of is to refactor every constructor (or at least the constructors that are problematic) to make them private/protected and replace them with an equivalent T::create(...) function that constructs the class and then adds the aspects after construction is complete. That should be a guaranteed way to fix this problem, but it does break the API.

Working with VS 2019, Python 3.7 64bit on Windows 10 and pybind11 2.4.3 I have run into the following problem:

When I create an object with a pybind11 py::class_ on the Python side and pass it directly to a method on the C++ side storing it in a std::vector, an attempt to read out the object later from Python results in an Access violation - no RTTI data. If the Python code stores the created object first in a Python variable to then pass it to C++ the subsequent access from Python works as intended.

I don’t have much experience in using pybind11 and C++ so I am probably making a simple mistake, would appreciate any help on how to set up the C++ and pybind11 usage so that the Python workaround to use a variable is not needed and I don’t get any access violation.

Here are some code details, the C++ code is

#include <iostream>

#include <vector>

#include <pybind11/pybind11.h>

using namespace std;


class XdmItem;

class XdmValue {

public:

    virtual XdmItem* itemAt(int n);

    virtual int size();

    void addXdmItem(XdmItem* val);


protected:
    std::vector<XdmItem*> values;
};

void XdmValue::addXdmItem(XdmItem* val) {
    values.push_back(val);
}

XdmItem* XdmValue::itemAt(int n) {
    if (n >= 0 && (unsigned int)n < values.size()) {
        return values[n];
    }
    return NULL;
}

int XdmValue::size() {
    return values.size();
}

class XdmItem : public XdmValue {

public:

    int size();

};

int XdmItem::size() {
    return 1;
}


namespace py = pybind11;

PYBIND11_MODULE(UseClassHierarchyAsPythonModule, m) {


    py::class_<XdmValue>(m, "PyXdmValue")
        .def(py::init<>())
        .def("size", &XdmValue::size)
        .def("item_at", &XdmValue::itemAt)
        .def("add_item", &XdmValue::addXdmItem);

    py::class_<XdmItem, XdmValue>(m, "PyXdmItem")
        .def(py::init<>())
        .def("size", &XdmItem::size);



#ifdef VERSION_INFO
    m.attr("__version__") = VERSION_INFO;
#else
    m.attr("__version__") = "dev";
#endif
}

the Python code that works flawlessly is

import UseClassHierarchyAsPythonModule

value = UseClassHierarchyAsPythonModule.PyXdmValue()

print(value, type(value))

print(value.size())

item = UseClassHierarchyAsPythonModule.PyXdmItem()

value.add_item(item)

print(value.size())

item0 = value.item_at(0)

print(item, type(item))

while the following code causes the Access violation - no RTTI data!:

import UseClassHierarchyAsPythonModule

value = UseClassHierarchyAsPythonModule.PyXdmValue()

print(value, type(value))

print(value.size())

value.add_item(UseClassHierarchyAsPythonModule.PyXdmItem())

print(value.size())

item0 = value.item_at(0)

print(item, type(item))

It gives

  Message=Access violation - no RTTI data!
  Source=C:SomePathAccessViolation.py
  StackTrace:
  File "C:SomePathAccessViolation.py", line 13, in <module>
    item0 = value.item_at(0)

If I enable native code debugging the stack trace include the pybind C++ code and is

>   UseClassHierarchyAsPythonModule.pyd!pybind11::polymorphic_type_hook<XdmItem,void>::get(const XdmItem * src, const type_info * & type) Line 818  C++
    UseClassHierarchyAsPythonModule.pyd!pybind11::detail::type_caster_base<XdmItem>::src_and_type(const XdmItem * src) Line 851 C++
    UseClassHierarchyAsPythonModule.pyd!pybind11::detail::type_caster_base<XdmItem>::cast(const XdmItem * src, pybind11::return_value_policy policy, pybind11::handle parent) Line 871  C++
    UseClassHierarchyAsPythonModule.pyd!pybind11::cpp_function::initialize::__l2::<lambda>(pybind11::detail::function_call & call) Line 163 C++
    UseClassHierarchyAsPythonModule.pyd!pybind11::handle <lambda>(pybind11::detail::function_call &)::<lambda_invoker_cdecl>(pybind11::detail::function_call & call) Line 100   C++
    UseClassHierarchyAsPythonModule.pyd!pybind11::cpp_function::dispatcher(_object * self, _object * args_in, _object * kwargs_in) Line 624 C++
    [External Code] 
    AccessViolation.py!<module> Line 13 Python

Any idea what is wrong in my C++/pybind11 use?

• 

  Junior Member

  • Регистрация: 11 2011
  • Сообщений: 69

  ---

  При инжектировании своего кода посредством новой dll возникает проблема c RTTI. Исполнение прерывается на определенном адресе, вылетает по RTTI exception. То же самое происходит, если запускать этот ехе в Олли дебагере, даже при отсутствии инжектированного кода. В VS 2010 все запускается нормально (exception все еще возникает, но правильно обрабатывается VS). Как это обойти, ибо в таком варианте программа с инжектированным кодом не работает. Перекомпиляция инжектированной dll с включенной RTTI не помогает.

• 

  retired

  • Регистрация: 04 2005
  • Сообщений: 7496

  ---

  Например, взять и разобраться, откуда оно вылетает и почему, не?
  Или хотя бы выложить хоть что-нибудь.

  Комментарий

• 

  born to be evil

  • Регистрация: 01 2007
  • Сообщений: 1016

  ---

  Dim77
  кг/ам. вариант — привести код инжекта, минимум

  От многой мудрости много скорби, и умножающий знание умножает печаль

  Комментарий

• 

  Тот самый

  • Регистрация: 02 2007
  • Сообщений: 895

  ---

  Сообщение от ajax

  привести код инжекта, минимум

  нет смысла. У него там exe файл кидается исключениями, а он еще туда чего-то инжектить пытается. Сначала надо отдельно выяснить чего исключения летят, а потом инжектить.

  Реверсивная инженерия — написание кода идентичного натуральному

  Комментарий

• 

  Junior Member

  • Регистрация: 11 2011
  • Сообщений: 69

  ---

  Сообщение от Hexxx

  нет смысла. У него там exe файл кидается исключениями

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

  Сообщение от Hexxx

  Сначала надо отдельно выяснить чего исключения летят

  Как это сделать? Я знаю адреса по которым вылетают исключения, по крайней мере в одном случае ругается на RTTI: Access violation — no RTTI data.

  Вот адрес с которого программа соскакивает на exception:

  Код:

  .text:004021E6                 push    offset g_aInterfaceText_ ; "  Interface text..."
  .text:004021EB                 call    sub_61A06F
  .text:004021F0                 cmp     [ebp+var_D], 0
  .text:004021F4                 jz      short loc_40221A
  .text:004021F6                 mov     eax, [ebx+8]
  .text:004021F9                 mov     esi, [eax+3Ch]
  .text:004021FC                 mov     ecx, esi
  .text:004021FE                 call    sub_61B715
  .text:00402203                 push    eax             ; int
  .text:00402204                 mov     ecx, esi
  .text:00402206                 call    sub_61B65C
  .text:0040220B                 push    eax             ; Dir
  .text:0040220C                 push    off_78E954      ; __int16
  .text:00402212                 call    sub_61C2EB
  .text:00402217                 mov     [ebp+var_D], al

  Вылетает при вызове sub_61C2EB с аргументами — имя директории и имя файла. Файл — TApp.dbf. Все это происходит при инициализации текста интерфейса. Подобные инициализации для других компонентов типа фонтов например проходят нормально.

  Короче говоря, exception возникает от того, что этот файл не может быть открыт. Это странно, ибо скомпилированная программа прекрасно его открывает. Почему он под Олли не может быть открыт — непонятно. Никаких специальных привилегий на этот файл, Everyone — Full access. Причем другие файлы программа открывает нормально.

  Комментарий

• 

  Тот самый

  • Регистрация: 02 2007
  • Сообщений: 895

  ---

  Сообщение от Dim77

  Access violation — no RTTI data

  Соответственно в коде экзешника используется dynamic_cast, но в настройках компилятора отключено RTTI. Это ваш бинарь?

  Реверсивная инженерия — написание кода идентичного натуральному

  Комментарий

• 

  Junior Member

  • Регистрация: 11 2011
  • Сообщений: 69

  ---

  Нет, оригинальный бинарь не мой. У меня его исходников нет, отсюда необходимость в инжекте.

  Сообщение от Hexxx

  Соответственно в коде экзешника используется dynamic_cast, но в настройках компилятора отключено RTTI.

  Это не очень понятно. Т.е. про dynamic_cast мне известно, но ехе уже скомпилировано, так что о каких настройках идет речь? Настройках Олли в случае с дебагером — ибо даже дебаг под Олли оригинального экзешника вызывает это исключение?

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

  В таком случае все мои файлы для инжекта тоже должны быть скомпилированы используя RTTI?

  У меня 3 файла для инжекта: ехе — очень простой, вызывающий DetourCreateProcessWithDll.
  Dll для инжекта.
  А также detoured.dll

  Первые два я перекомпилил с включенным RTTI — не помогло.
  Последний — нужно найти исходники и тоже скомпилить, я его подцепил в инете.

  Комментарий

• 

  Тот самый

  • Регистрация: 02 2007
  • Сообщений: 895

  ---

  Сообщение от Dim77

  Нет, оригинальный бинарь не мой

  Ну раз так, значит в программе изначально баг. Приложение само кидает исключение и само же его обрабатывает. VS знает что конкретно такие исключения нужно отдать программе на обработку. Olly видимо про это не знает поэтому останавливает работу приложения. Т.е. это вопрос к настройкам Ollydbg. Я без понятия как там это делается, потому что не пользуюсь. В IDA например есть настройки для исключений, можно указать какой код нужно обработать отладчику, а какой отдать приложению.

  Но это только по вопросу «почему в олли не работает». Про инжектирование нужны подробности как именно оно глючит.

  Реверсивная инженерия — написание кода идентичного натуральному

  Комментарий

• 

  Junior Member

  • Регистрация: 11 2011
  • Сообщений: 69

  ---

  Сообщение от Hexxx

  Про инжектирование нужны подробности как именно оно глючит.

  Программа вылетает, при подсоединении дебагера видно, что вылет происходит по адресу: 61B028, т.е. при попытке выйти из очень длинной процедуры инициализации различных параметров программы. Ниже код последних шагов.
  Вылетает на Leave с ошибкой Unhandled Exception at address 0x0061B028: 0x00000005. Access Violation reading location 0x00000000.

  Регистры:
  EAX = 00383480 EBX = 00383034 ECX = 0038304D EDX = 00008000 ESI = 0022F844 EDI = 006F3534 EIP = 0061B028 ESP = 0022F838 EBP = 00000000 EFL = 00010246

  Есть подозрение, что EBP должно содержать адрес вызывающей функции, но это значение почему-то оказывается равным 0. Как понять, что там на самом деле должно быть не очень ясно, разве что VS присоединиться к оригинальному процессу… Но, даже если это будет понятно, важнее понять, почему там этого адреса не оказывается, если вообще мое предположение верно.

  Код:

  .text:0061B017 loc_61B017:                             ; CODE XREF: .text:0061AFF0j
  .text:0061B017                 mov     ecx, [esp+1Ch]
  .text:0061B01B                 mov     eax, esi
  .text:0061B01D                 pop     edi
  .text:0061B01E                 pop     esi
  .text:0061B01F                 pop     ebp
  .text:0061B020                 mov     large fs:0, ecx
  .text:0061B027                 pop     ebx
  .text:0061B028                 leave
  .text:0061B029                 retn    4

  Полный код функции приаттачен.

  98dd_26.05.2012_EXELAB.rU.tgz — SubError.txt

  Комментарий

• 

  Junior Member

  • Регистрация: 02 2008
  • Сообщений: 4815

  ---

  сам екзе не хученый работает? значит варианты
  — в проге защите от дебагера(1%)
  — кривая хук функция(90%)
  — хз(9%)

  выкладывай наверное екзе+хук
  что бы не гадать на ромашках

  Комментарий

• 

  оптимист

  • Регистрация: 07 2008
  • Сообщений: 2405

  ---

  Сообщение от Dim77

  Есть подозрение, что EBP должно содержать адрес вызывающей функции

  Сообщение от Dim77

  .text:0061B028    leave

  Из EBP в ЕSP копирутся то значение которое было до вызова процедуры(выравнивается стек),

  Сообщение от Dim77

  text:0061B01F   pop     ebp

  вот здесь и дёт ошибка,в стеке нарушина последовательность и в EBP ложится хрен знает что,но нето что нужно

  Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

  Комментарий

• 

  Junior Member

  • Регистрация: 11 2011
  • Сообщений: 69

  ---

  Сообщение от reversecode

  выкладывай наверное екзе+хук
  что бы не гадать на ромашках

  Выложил:

  1.

  —>Оригинальный Ехе + ini <—

  2.

  —>Hook — exe (инжектор) + моя dll + detored.dll <—

  Эти файлы должны быть там же где и оригинальный ехе
  3.

  —> Файлы инициализации <—

  Возможно и без них можно дойти до того места, где происходит ошибка…

  Сообщение от ClockMan

  ,в стеке нарушина последовательность и в EBP ложится хрен знает что

  Как это происходит пока не вижу.

  На всякий случай код хука:

  Код:

  // noCD2.cpp : Defines the exported functions for the DLL application.
  //
  #include "stdafx.h"
  #include 
  #include 
  #include 
  #include 
  
  typedef void (WINAPI *pFunc)(DWORD);
  
  HINSTANCE hInstance;
  #define BUF_LEN 128
  
  #pragma comment(lib, "detours.lib")
  
  extern "C" __declspec(dllexport) bool proc_51F36F(char *Str2, char *driveletter)
  {
    static CHAR FileSystemNameBuffer;
    static CHAR Str1;
    static DWORD FileSystemFlags;
    static DWORD VolumeSerialNumber;
   
    static DWORD MaximumComponentLength;
    static char RootPathName[4];
    static char FileName[MAX_PATH];
   
  GetModuleFileNameA(0, FileName, sizeof(FileName));
  _splitpath(FileName,RootPathName,NULL,NULL,NULL);
  
  strcat(RootPathName, "");
  
  *driveletter=RootPathName[0];
  
  if ( !(GetVolumeInformationA(RootPathName,&Str1,BUF_LEN,&VolumeSerialNumber,&MaximumComponentLength,&FileSystemFlags,&FileSystemNameBuffer,BUF_LEN)))
  {
           DWORD LError = GetLastError();
  }
  return (*driveletter != '');
  }
  
  
  pFunc FuncToDetour = (pFunc)(0x0051F36F); //Set it at address to detour in
                      //the process
  INT APIENTRY DllMain(HMODULE hDLL, DWORD Reason, LPVOID Reserved)
  {
      switch(Reason)
      {
      case DLL_PROCESS_ATTACH:
          {
              DisableThreadLibraryCalls(hDLL);
              DetourTransactionBegin();
              DetourUpdateThread(GetCurrentThread());
              DetourAttach(&(PVOID&)FuncToDetour, proc_51F36F);
              DetourTransactionCommit();
          }
          break;
      case DLL_PROCESS_DETACH:
          DetourTransactionBegin();
          DetourUpdateThread(GetCurrentThread());
          DetourDetach(&(PVOID&)FuncToDetour,  proc_51F36F);
          DetourTransactionCommit();
          break;
      case DLL_THREAD_ATTACH:
      case DLL_THREAD_DETACH:
          break;
      }
      return TRUE;
  }

  Комментарий

• 

  Junior Member

  • Регистрация: 02 2008
  • Сообщений: 4815

  ---

  ясное дело
  в оригинальном exe stdcall конвершинал
  а в вашей хученой cdecl
  вот стек и ломается

  Комментарий

• 

  Junior Member

  • Регистрация: 11 2011
  • Сообщений: 69

  ---

  Сообщение от reversecode

  в оригинальном exe stdcall конвершинал
  а в вашей хученой cdecl
  вот стек и ломается

  Заработало. Спасибо. Это было круто Это мой первый NoCD. Чувствую прилив эндорфинов

  ЗЫ С исключениями в Олли еще предстоит разобраться ибо цель была добавить еще свой код к этому ехе. No CD — это была «проба пера»…

  Комментарий

• 

  Тот самый

  • Регистрация: 02 2007
  • Сообщений: 895

  ---

  Сообщение от Dim77

  No CD — это была «проба пера»

  Дожили, перья жрут…

  Реверсивная инженерия — написание кода идентичного натуральному

  Комментарий