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:
- 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?
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:
- 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.
Access violation — no RTTI data!
Quick Fields
Version 10
Updated July 28, 2017
asked on July 28, 2017
Has anyone seen this error before in Quick Fields?
The Quick Fields session is configured to immediately store documents to Laserfiche. If their is an error, then it sits in the Revision Pane. As the QF Session was still running, I updated one of the documents to remove the red flag and attempted to store the document. Right after I tried storing the document, I received the following error, «Access violation — no RTTI data!»
I am trying to serialize set of classes (where every class which has virtual destructor) using boost serialization. Test for all classes are passing except 1 which give above error.
I even tried setting enabling RTTI in VS 2012 but no use.. still the error exists.
I saw a link with similar type of issue but no help.
Boost Serialization of simple class with RTTI turned Off (-fno-rtti)
complete error message is — unknown location(0): fatal error in «mychecktest»: std::bad_typeid: Access violation — no RTTI data!
There is another link on similar problem but no solution
http://lists.boost.org/boost-testing/2005/05/1014.php
really don’t know what could go wrong… really need help on this.
Thanks,
asked Apr 30, 2014 at 11:30
1
in my case, i was also getting same issue and it was due to 1 of member variables was not serializing properly and hence this issue occured.
You can also do the same check at and give it a try.
answered May 7, 2014 at 11:15
user1291401user1291401
2541 gold badge6 silver badges18 bronze badges
1
I was working on a model i made in Freecad when i got this error.
Anybody knows what’s going on?
Thank you.
17:11:59 Unhandled Base::Exception caught in GUIApplication::notify.
The error message is: Sketch::checkGeoId. GeoId index out range.
17:12:07 TempoVis.restore: failed to restore detail (‘SDVProperty’, ‘tekening_Ster_v5_almost’, ‘Sketch.Visibility’): Unknown document ‘tekening_Ster_v5_almost’
17:12:07 TempoVis.restore: failed to restore detail (‘SDVProperty’, ‘tekening_Ster_v5_almost’, ‘Sketch.LinkVisibility’): Unknown document ‘tekening_Ster_v5_almost’
17:12:10 0 Selection.cpp(157): Unhandled std::exception caught in selection observer: Access violation — no RTTI data!
17:12:10 6.3483e-05 Selection.cpp(157): Unhandled std::exception caught in selection observer: Access violation — no RTTI data!
17:12:25 Traceback (most recent call last):
File «<string>», line 1, in <module>
<class ‘NameError’>: Unknown document »
17:12:25 Unhandled Base::Exception caught in GUIApplication::notify.
The error message is: Unknown document »
17:12:27 Traceback (most recent call last):
File «<string>», line 1, in <module>
<class ‘NameError’>: Unknown document »
17:12:27 Unhandled Base::Exception caught in GUIApplication::notify.
The error message is: Unknown document »
17:12:32 22.6109 Selection.cpp(157): Unhandled std::exception caught in selection observer: Access violation — no RTTI data!
17:12:32 22.6109 Selection.cpp(157): Unhandled std::exception caught in selection observer: Access violation — no RTTI data!
17:12:34 Traceback (most recent call last):
File «<string>», line 1, in <module>
<class ‘NameError’>: Unknown document »
17:12:34 Unhandled Base::Exception caught in GUIApplication::notify.
The error message is: Unknown document »
17:12:40 30.5793 Selection.cpp(157): Unhandled std::exception caught in selection observer: Access violation — no RTTI data!
17:12:40 30.5794 Selection.cpp(157): Unhandled std::exception caught in selection observer: Access violation — no RTTI data!
17:12:43 Traceback (most recent call last):
File «<string>», line 1, in <module>
<class ‘NameError’>: Unknown document »
17:12:43 Unhandled Base::Exception caught in GUIApplication::notify.
The error message is: Unknown document »
17:12:46 36.8209 Selection.cpp(157): Unhandled std::exception caught in selection observer: Access violation — no RTTI data!
17:12:46 36.8209 Selection.cpp(157): Unhandled std::exception caught in selection observer: Access violation — no RTTI data!
17:12:47 37.0261 Selection.cpp(157): Unhandled std::exception caught in selection observer: Access violation — no RTTI data!
17:12:47 37.0261 Selection.cpp(157): Unhandled std::exception caught in selection observer: Access violation — no RTTI data!
17:12:48 38.0718 Selection.cpp(157): Unhandled std::exception caught in selection observer: Access violation — no RTTI data!
17:12:48 38.0718 Selection.cpp(157): Unhandled std::exception caught in selection observer: Access violation — no RTTI data!
17:12:52 Traceback (most recent call last):
File «<string>», line 1, in <module>
<class ‘NameError’>: Unknown document »
17:13:00 49.996 Selection.cpp(157): Unhandled std::exception caught in selection observer: Access violation — no RTTI data!
17:13:00 49.9961 Selection.cpp(157): Unhandled std::exception caught in selection observer: Access violation — no RTTI data!
-
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 — это была «проба пера»
Дожили, перья жрут…
Реверсивная инженерия — написание кода идентичного натуральному
Комментарий