LINUX: Tools Run Crash and Company...

[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]

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?

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?

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.

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

to:

Code: cpp

class DLLIMPORT ToolsManager : public wxEvtHandler, public Mgr<ToolsManager>

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

[moloh]

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)

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

Try this:

toolsmanager.h, line 33, from:

Code: cpp

class DLLIMPORT ToolsManager : public Mgr<ToolsManager>, public wxEvtHandler

to:

Code: cpp

class DLLIMPORT ToolsManager : public wxEvtHandler, public Mgr<ToolsManager>

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

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.

[Ceniza]

Well, since this problem makes no sense (becoming a compiler's problem), maybe the trick in toolsmanager.h line 33 could work as a patch (you said it's giving you the same value of this everywhere), but I cannot assure it'll solve everything.

[moloh]

Well, since this problem makes no sense (becoming a compiler's problem), maybe the trick in toolsmanager.h line 33 could work as a patch (you said it's giving you the same value of this everywhere), but I cannot assure it'll solve everything.

I think it won't, ie. it can cause problems with gcc-3.4. Also this is only workaround, not a true patch for pointer casts problems.
I must also say that i think gcc-4.1 behaviour is resonable. Ok then, if there would be any new info, please post it in this thread.

[Ceniza]

That fix won't cause problems with GCC 3.4.x, it'll just change the order of the base classes in memory. If you recompile the whole thing it'll work, but it'd be good if you could try it and check for those random crashes first.

A true patch wouldn't be applied to Code::Blocks but GCC itself since we'ren't the ones causing the problem. In the meanwhile, if that works for you, we could apply the workaround so it'll work with GCC 4.1.

That behaviour is completely wrong from GCC 4.1 since it's the one that fails setting this to the right value when calling that member function. It really has nothing to do with Code::Blocks.

Just in case: that cast to void ** has nothing to do with it.

[edit]
I just tried recompiling Code::Blocks with GCC 4.1.1 (MinGW) and the problem showed up here (it didn't crash, but this changed its value from one call to another).

It'd be good to report this bug, even though to know the real problem I'd need to dig deep in wxWidget's sources and find what makes GCC 4.1 go wrong.

Apart of taking some time until I get a small testcase, this bug could be already reported, but hard to find in the bug tracker.
[/edit]

[Ceniza]

I took a look at the event "construction", which is just a bunch of casts, and replaced it just as suggested in the wxWidget's manual (adding even more casts) and... voilà! The value of this is right for both calls now (good luck or fix... nobody knows).

I checked the address returned by both bunch of casts and both return the same address. It's even more confusing now because if it was the problem it should, at least, return different values.

I decided to check that 'cause I thought some evil magic there could cause it, but having the same value returned do also makes sense after all, 'cause we're playing with pointers to member functions.

At the end it could be some deep cast in wxWidget's code being generated differently by GCC 4.1, but the results of my tests just confuse me more.

For reference: sdk_events.h, line 209, from:

Code: cpp

#define EVT_PIPEDPROCESS_TERMINATED(id, fn) DECLARE_EVENT_TABLE_ENTRY( cbEVT_PIPEDPROCESS_TERMINATED, id, wxID_ANY, (wxObjectEventFunction) (wxEventFunction) (wxCommandEventFunction) & fn, (wxObject *) NULL ),

to:

Code: cpp

#define EVT_PIPEDPROCESS_TERMINATED(id, fn) DECLARE_EVENT_TABLE_ENTRY( cbEVT_PIPEDPROCESS_TERMINATED, id, wxID_ANY, (wxObjectEventFunction) (wxEventFunction) (wxCommandEventFunction) (wxNotifyEventFunction) (CodeBlocksEventFunction)&fn, (wxObject *) NULL ),

Right now, the most confusing part is why that change makes it work if it seems to change absolutely nothing at all 

[moloh]

Right now, the most confusing part is why that change makes it work if it seems to change absolutely nothing at all 

I must say, interesting... so i know why in documentation they said:

...Watch out to put in enough casts to the inherited event function...

I agree i don't understand this... but for sure it has sth to do with wxWidgets internals.

[moloh]

Could this and other event definitions could be fixed before rc3?