Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

LINUX: Tools Run Crash and Company...

<< < (7/9) > >>

Ceniza:
This in Execute: 141134688 <-- address of an instance of ToolsManager.
This in Execute (c cast): 141134692 <-- here's an offset adjustment so it points to base (wxEvtHandler).
This in Execute (static cast): 141134693 <-- idem
This in Execute (reinterpret cast): 141134688 <-- cast without offset adjustment (dangerous). You must really know what you're doing.
This in Execute (dynamic cast): 141134692 <-- cast solved at run-time. It'll adjust the offset too.
This in OnToolTerminated: 141134692 <-- Compiler bug? this of the wxEvtHandler for a call to a ToolsManager member function.

If you're using GCC 4.x, could you try the same code with 3.4.x?

Setting to 0 m_Pid and m_pProcess with a displacement of 4 bytes...

Since those are the last two variables of ToolsManager, and considering a typical 32 bits architecture they both would be the same size, m_pProcess = 0 would be setting m_Pid to 0, and m_Pid = 0 would be setting something out of ToolsManager space to 0 (it'd explain a possible crash and a possible attemp to access memory that doesn't belong to the object in no way).

If PipedProcess didn't modify m_pProcess thru that void **, m_pProcess would keep its old value :shock:

Those are my guesses.

moloh:

--- Quote from: Ceniza on June 02, 2006, 09:29:51 am ---This in Execute: 141134688 <-- address of an instance of ToolsManager.
This in Execute (c cast): 141134692 <-- here's an offset adjustment so it points to base (wxEvtHandler).
This in Execute (static cast): 141134692 <-- idem
This in Execute (reinterpret cast): 141134688 <-- cast without offset adjustment (dangerous). You must really know what you're doing.
This in Execute (dynamic cast): 141134692 <-- cast solved at run-time. It'll adjust the offset too.
This in OnToolTerminated: 141134692 <-- Compiler bug? this of the wxEvtHandler for a call to a ToolsManager member function.

If you're using GCC 4.x, could you try the same code with 3.4.x?

--- End quote ---

I use 4.1, You mean recompilation on Gentoo with 3.4? I must be crazy to do that. There are incompatibilities in ABI. I want to have working system.
But as far i know there was no problem with gcc-3.4 earlier so *problably* it works correctly.

I see that problem could be lack o vtables, why? How do compiler (program on run-time) can know that parent pointer (wxEvtHandler) in PipedProcess is sth different and make a shift back? Maybe between gcc version they changed layout of multiple derived classes. And here is a problem, but i don't know. I am only average c programmer and raport problem here.
Also There wouldn't be any problem if there were no multiple inheritance? Am i right?


--- Quote from: Ceniza on June 02, 2006, 09:29:51 am ---Setting to 0 m_Pid and m_pProcess with a displacement of 4 bytes...

Since those are the last two variables of ToolsManager, and considering a typical 32 bits architecture they both would be the same size, m_pProcess = 0 would be setting m_Pid to 0, and m_Pid = 0 would be setting something out of ToolsManager space to 0 (it'd explain a possible crash and a possible attemp to access memory that doesn't belong to the object in no way).

If PipedProcess didn't modify m_pProcess thru that void **, m_pProcess would keep its old value :shock:

Those are my guesses.

--- End quote ---
Ow, good! Now You see problem...
Now it works ok (i mean Code::Blocks does not crash, memory access if "safe" as it is close to real *this* pointer), problem was before with wxTimer (i mean Code::Block crash on Tool Termintion).

Ceniza:
If there was no multiple inheritance, or if at least the inheritance order was swapped, it should work, but who knows... it's the GCC 4.1 world and crazy things could happen (that just shouldn't) :)

Try this:

toolsmanager.h, line 33, from:

--- Code: (cpp) ---class DLLIMPORT ToolsManager : public Mgr<ToolsManager>, public wxEvtHandler
--- End code ---
to:

--- Code: (cpp) ---class DLLIMPORT ToolsManager : public wxEvtHandler, public Mgr<ToolsManager>
--- End code ---

That should give you the same output for all casts and hopefully for the one in OnTerminate :)

moloh:

--- Quote from: Ceniza on June 02, 2006, 10:04:53 am ---If there was no multiple inheritance, or if at least the inheritance order was swapped, it should work, but who knows... it's the GCC 4.1 world and crazy things could happen (that just shouldn't) :)

--- End quote ---

For me this is still depending on undefined behaviour ;-).
To fix this there have to be made some serious inheritance rearangment in source.


--- Quote from: Ceniza on June 02, 2006, 10:04:53 am ---Try this:

toolsmanager.h, line 33, from:

--- Code: (cpp) ---class DLLIMPORT ToolsManager : public Mgr<ToolsManager>, public wxEvtHandler
--- End code ---
to:

--- Code: (cpp) ---class DLLIMPORT ToolsManager : public wxEvtHandler, public Mgr<ToolsManager>
--- End code ---

That should give you the same output for all casts and hopefully for the one in OnTerminate :)

--- End quote ---
Yes, all are same now.
See You going sleep now, already 2AM here...

moloh:
I would like to know if now, as You know what is the problem, there would be some patch to this problem.
I would appreciate any information.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version