[Fixed] Perhaps a gcc bug

[mnk]

Rev. 4064 doesn't work for me.
Having said what I did in the other thread, I must admit, that I didn't run vavoom
in quite a while, so I can't really tell when this happened for the first time.
As such I decided to go a few revisions back (to r4045) and got the same problem.

I'm not sure, what exactly fails. Perhaps it's a compiler bug (I'm using 4.4.1)
or a result of a compiler fix (as perhaps something has began to work properly
- if you read Gentoo bug 276146, you'll see what I mean).

Anyway, the bug is that for any of doom2/strife/hexen, when I run Vavoom,
after initial block of messages, it goes right up to 'Selected SDL ... rasteriser' (software and opengl)
and right then it goes into termination and exits with 'Division by 0'.

Should I go further back with revisions ?

[Firebrand]

How about going a few revisions back? or maybe using an older GCC version?

[mnk]

I'll see about the revisions, but for some reason, older versions of gcc
refuse to work with cmake linked with the recent libstdc++ version.

Just a question: what gcc version are you using ?
Cause, if I read you correctly, you're saying it should work.

PS.: OK, it's checked back to r4037 (over six weeks ago) and still no go. I think
I ran it at least once since. Perhaps a hint of where should I point gdb at,
cause the way vavoom is written, it's hard to tell anything about program flow
without it.

PPS.: even r4019 is not enough, so it's either a compiler bug, or that other case.
Strange - for firefox, it works just fine. So I think it will be the other case,
though I still could use that debugging hint.

[Firebrand]

I'm using GCC 3.4.5 (old version, but it works fine). As for where to point gdb... I'm not very sure, I don't compile code for linux, so I wouldn't know, sorry . Why don't you try using an older GCC? You have gone back in revisions and it still doesn't works, so it's maybe a problem with the compiler...

[mnk]

Well, I woldn't mind, but cmake does:

Code: Select all

/usr/bin/cmake: /usr/lib/gcc/i686-pc-linux-gnu/4.3.3/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/bin/cmake)


but I'm building 4.3.4, if cmake accepts it, I post the results, if it doesn't (I expect it won't), it'll be bit hard to do anything.

Unless I'll get decent debugging tips here.

PS.: as I expected that didn't help. I do wonder what the problem could be, firefox does work, as does doomsday
(if only it had Strife module).

X

[mnk]

Anyway, this is what '-debug' gives me:

Code: Select all

Sys_Error: OPC_FDivide: Division by 0
- (uibase.FinaleScreen.OnCreate)
- VObject::ExecuteFunction
- (uibase.FinaleScreen.OnCreate)
- VWidget::Init
- VWidget::CreateNewWidget
- (FinaleScreen)
- VObject::ExecuteFunction
- (cgame.ClientGame.RootWindowCreated)
- Host_Init


...

Code: Select all

STACK TRACE:

stack 0 0x82e0685 frame 0 0xbf838698
stack 1 0xb795ea66 frame 1 0xbf8386d8
stack 2 0x80bd281 frame 2 0xbf838748


'OPC_FDivide:' part comes from my own tests - original message without it
appears in a few other places, so I made those strings more distinct.
It's source/pr_exec.cpp, line 1450.

[mnk]

Maybe it's not a bug after all.
Among the changes of gcc 4.4 there's this:

Code: Select all

... now properly implements value-initialization,  so objects with an initializer of () and an implicitly defined default constructor will be zero-initialized before the default constructor is called.


It seems the problem comes from here, cause if I add NO_DEFAULT_CONSTRUCTOR(VWidget) to class VWidget in
source/ui_widget.h, it seems to fix the problem. Though, this may mean, that similar "fix" may be needed in
other places too.

BTW, forum insists on being dumb, for some reason, I can't put G + + (without spaces) in front of the above code block.
I had this answer ready over a day ago, but only now I've found that this was what prevented me from posting
(I kept getting "this web resource is forbidden" after pressing "submit").

[Janis Legzdinsh]

Yes, that's a proper fix for this.