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

LINUX: Tools Run Crash and Company...

<< < (8/9) > >>

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:

--- Quote from: Ceniza on June 04, 2006, 03:39:22 am ---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.

--- End quote ---

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 ),
--- End code ---
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 ),
--- End code ---

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

moloh:

--- Quote from: Ceniza on June 04, 2006, 06:29:48 am ---Right now, the most confusing part is why that change makes it work if it seems to change absolutely nothing at all  :(

--- End quote ---

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

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

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page