Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#544 closed bug (invalid)

BScreen* has corrupt data

Reported by: johndrinkwater Owned by: axeld
Priority: normal Milestone: R1
Component: - General Version:
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


Picked this error up from GLQuake, it uses a BScreen*, but doesnt call a constructor before using it. Rather cryptic description, but attached is a test in case I dont make myself clear

obj->Frame() returns a corrupted BRect, so Quake tries to init a GL screen of -2147483647 x 1!

Related: width + height also are corrupt; they arent 0 like the application assumes (norty), See URL for code

Filed incorrectly under interface kit; really not sure where to put it, sorry. It's more a "class members have trashed (non blank) data if they arent set."

Attachments (1) (7.3 KB) - added by johndrinkwater 13 years ago.
src + bin of a little BScreen test

Download all attachments as: .zip

Change History (8)

Changed 13 years ago by johndrinkwater

Attachment: added

src + bin of a little BScreen test

comment:1 Changed 13 years ago by axeld

Status: newclosed

comment:2 Changed 13 years ago by axeld

When you access a non initialized object, how do you think this should work? This is just a bug in the application, and must be fixed there.

comment:3 Changed 13 years ago by axeld

Resolution: invalid

comment:4 Changed 13 years ago by johndrinkwater

Why? Because it works this way on BeOS. The test app and GLQuake show it. How can the developer access SetMode() if the object isnt initialized?

I understand its poor coding; I have a patch to fix this problem, but that doesnt fix the fact that the BeOS binary wont work.

comment:5 Changed 13 years ago by korli

John, if you don't init correctly your class members, the behaviour is undefined. Seems you're out of luck on Haiku ...

comment:6 Changed 13 years ago by axeld

Well, I think we just can live with that - and will so in similar situations (especially when the source is available and all). But don't get me wrong: thanks for your effort, it's very much appreciated!

comment:7 Changed 13 years ago by mmlr

I suppose this works on BeOS since it only has one static BScreen backend object whereas the Haiku implementation has a BObjectList of at least two PrivateScreens. In Haiku the PrivateScreen has to be referenced to be useable as done in the constructor, in BeOS the members are probably just statics. It still is just a bug to use an unitialized pointer. Interesting that it doesn't segfault.

Note: See TracTickets for help on using tickets.