Made ENTER_GL() - LEAVE_GL() free X11 lock on exception inside opengl, code

[Louis. Lenders]

> And as was shown, Wine correctly returns NULL when its called without a context, so there is >something else making it crash. It may be a buggy driver. It may be memory corruption Wine is >causing.. who knows.

i don't think it's buggy driver,  this  happens as far  as i know for various people, so i'd guess various cards/drivers.

Is there a way to track down what AutoCAD returns in this call to glGetString on Windows?

Btw, the installer even finishes fine with native opengl32.dll ( no, this is not a joke!), so somehow i have the feeling that an exception handler is the right way anyway, but i lack knowledge of opengl, so i'll shut up for now ;) )

__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

Possible issue with win.c and help

[Chris Ahrendt]

Ok in my ever increasing search to figure out why EQ2 is getting a 
unhandled exception and also a no ipixel error. (I am convinced this is 
two separate bugs now)

Bug One :

This is the unhandled exception:
If I have EQ2 run in anything but win98 mode (which I don't think is 
supported anymore by EQ2) wine dies with a unhandled exception. If I set 
to win98 it ends with a no ipixel format error message box (the second 
bug) after it begins to draw the window. The other thing is the msg box 
is not a typical msg box saying that something isn't supported but looks 
to be an exception in  ClientApp.cpp which means they are getting some 
unhandled exception while drawing the window.

What I think might be going on based on this :

trace:win:WIN_SetWindowLong 0x2002c 0 0 W
trace:win:WIN_SetWindowLong Fell Through
trace:win:WIN_SetWindowLong Release Ptr
trace:win:WIN_DestroyWindow 0x2002c
trace:win:WIN_DestroyWindow 0x1002e
trace:win:WIN_DestroyWindow 0x10030
trace:win:WIN_DestroyWindow 0x10032
trace:win:WIN_DestroyWindow 0x10034
trace:win:WIN_DestroyWindow 0x10036
trace:win:WIN_DestroyWindow 0x10038
trace:win:WIN_DestroyWindow 0x1003a
trace:win:WIN_DestroyWindow 0x1003c
trace:win:WIN_DestroyWindow 0x1003e
trace:win:WIN_DestroyWindow 0x10040
trace:win:WIN_DestroyWindow 0x10042
trace:win:WIN_DestroyWindow 0x10044
trace:win:WIN_SetWindowLong 0x2002c 0 0 W

====================================================================
These are my trace additions  in SetWindowLong to help me follow the 
execution of the code

trace:win:WIN_SetWindowLong Fell Through
trace:win:WIN_SetWindowLong Release Ptr
trace:win:WIN_SetWindowLong 0x2002c 12 0 W
trace:win:WIN_SetWindowLong Fell Through
trace:win:WIN_SetWindowLong Server Start Request
trace:win:WIN_SetWindowLong Default
trace:win:WIN_SetWindowLong no call Err
trace:win:WIN_SetWindowLong Default get and Set Win Data
trace:win:WIN_SetWindowLong Release Ptr
trace:win:WIN_SetWindowLong Returning 1871960

CRASH! Unhandled Exception

I think the window is being destroyed in reverse for some reason. Thats 
just my gut first feeling based on the above trace and the exception 
output. This is where my knowledge on Windows behavior ends. Does 98 
destroy the windows chain differently than XP? This would explain why 
the exception doesn't occur in 98 but does in XP.

Second Bug:
This is the ipixel problem which I haven't figured out
how to debug whats going on there, but think it might  be related to 
this  error:

libGL error: drmMap of framebuffer failed (Cannot allocate memory)
libGL error: reverting to (slow) indirect rendering
libGL error: drmMap of framebuffer failed (Cannot allocate memory)
libGL error: reverting to (slow) indirect rendering

Which I am not sure why this is occurring yet but one bug at a time. 
Where would someone look to trace along the window draw chain to see 
where it dies. Some of the debug flags cause my machine to lock up which 
I know is a driver issue and other lockups could be caused by the above 
exception messing something up in X as the disk still runs when that 
lockup occurs but X is DOA.

Thoughts????? Ideas???? Suggestions??????

Chris

Possible issue with win.c and help

[Lei Zhang]

On Mon, Jun 30, 2008 at 9:05 PM, Chris Ahrendt  wrote:
> Ok in my ever increasing search to figure out why EQ2 is getting a
> unhandled exception and also a no ipixel error. (I am convinced this is
> two separate bugs now)
>
> Bug One :
>
> This is the unhandled exception:
> If I have EQ2 run in anything but win98 mode (which I don't think is
> supported anymore by EQ2) wine dies with a unhandled exception. If I set
> to win98 it ends with a no ipixel format error message box (the second
> bug) after it begins to draw the window. The other thing is the msg box
> is not a typical msg box saying that something isn't supported but looks
> to be an exception in  ClientApp.cpp which means they are getting some
> unhandled exception while drawing the window.
>
> What I think might be going on based on this :
>
> trace:win:WIN_SetWindowLong 0x2002c 0 0 W
> trace:win:WIN_SetWindowLong Fell Through
> trace:win:WIN_SetWindowLong Release Ptr
> trace:win:WIN_DestroyWindow 0x2002c
> trace:win:WIN_DestroyWindow 0x1002e
> trace:win:WIN_DestroyWindow 0x10030
> trace:win:WIN_DestroyWindow 0x10032
> trace:win:WIN_DestroyWindow 0x10034
> trace:win:WIN_DestroyWindow 0x10036
> trace:win:WIN_DestroyWindow 0x10038
> trace:win:WIN_DestroyWindow 0x1003a
> trace:win:WIN_DestroyWindow 0x1003c
> trace:win:WIN_DestroyWindow 0x1003e
> trace:win:WIN_DestroyWindow 0x10040
> trace:win:WIN_DestroyWindow 0x10042
> trace:win:WIN_DestroyWindow 0x10044
> trace:win:WIN_SetWindowLong 0x2002c 0 0 W
>
> ====================================================================
> These are my trace additions  in SetWindowLong to help me follow the
> execution of the code
>
> trace:win:WIN_SetWindowLong Fell Through
> trace:win:WIN_SetWindowLong Release Ptr
> trace:win:WIN_SetWindowLong 0x2002c 12 0 W
> trace:win:WIN_SetWindowLong Fell Through
> trace:win:WIN_SetWindowLong Server Start Request
> trace:win:WIN_SetWindowLong Default
> trace:win:WIN_SetWindowLong no call Err
> trace:win:WIN_SetWindowLong Default get and Set Win Data
> trace:win:WIN_SetWindowLong Release Ptr
> trace:win:WIN_SetWindowLong Returning 1871960
>
> CRASH! Unhandled Exception
>
> I think the window is being destroyed in reverse for some reason. Thats
> just my gut first feeling based on the above trace and the exception
> output. This is where my knowledge on Windows behavior ends. Does 98
> destroy the windows chain differently than XP? This would explain why
> the exception doesn't occur in 98 but does in XP.
>
> Second Bug:
> This is the ipixel problem which I haven't figured out
> how to debug whats going on there, but think it might  be related to
> this  error:
>
> libGL error: drmMap of framebuffer failed (Cannot allocate memory)
> libGL error: reverting to (slow) indirect rendering
> libGL error: drmMap of framebuffer failed (Cannot allocate memory)
> libGL error: reverting to (slow) indirect rendering
>
> Which I am not sure why this is occurring yet but one bug at a time.
> Where would someone look to trace along the window draw chain to see
> where it dies. Some of the debug flags cause my machine to lock up which
> I know is a driver issue and other lockups could be caused by the above
> exception messing something up in X as the disk still runs when that
> lockup occurs but X is DOA.
>
> Thoughts????? Ideas???? Suggestions??????
>
> Chris

Hi,

Please file bug reports on the Wine Bugzilla - http://bugs.winehq.org/
The second issue looks like 3d graphics are not set up correctly on
your computer. You should ask your favorite Linux forum about that.

Possible issue with win.c and help

-----Original Message-----
From: Lei Zhang 
To: [e-mail]
Cc: [e-mail]
Sent: Tue, 1 Jul 2008 11:34 am
Subject: Re: Possible issue with win.c and help

On Mon, Jun 30, 2008 at 9:05 PM, Chris Ahrendt  wrote:
> Ok in my ever increasing search to figure out why EQ2 is getting a
> unhandled exception and also a no ipixel error. (I am convinced this is
> two separate bugs now)
>
> Bug One :
>
> This is the unhandled exception:
> If I have EQ2 run in anything but win98 mode (which I don't think is
> supported anymore by EQ2) wine dies with a unhandled exception. If I set
> to win98 it ends with a no ipixel format error message box (the second
> bug) after it begins to draw the window. The other thing is the msg box
> is not a typical msg box saying that something isn't supported but looks
> to be an exception in  ClientApp.cpp which means they are getting some
> unhandled exception while drawing the window.
>
> What I think might be going on based on this :
>
> trace:win:WIN_SetWindowLong 0x2002c 0 0 W
> trace:win:WIN_SetWindowLong Fell Through
> trace:win:WIN_SetWindowLong Release Ptr
> trace:win:WIN_DestroyWindow 0x2002c
> trace:win:WIN_DestroyWindow 0x1002e
> trace:win:WIN_DestroyWindow 0x10030
> trace:win:WIN_DestroyWindow 0x10032
> trace:win:WIN_DestroyWindow 0x10034
> trace:win:WIN_DestroyWindow 0x10036
> trace:win:WIN_DestroyWindow 0x10038
> trace:win:WIN_DestroyWindow 0x1003a
> trace:win:WIN_DestroyWindow 0x1003c
> trace:win:WIN_DestroyWindow 0x1003e
> trace:win:WIN_DestroyWindow 0x10040
> trace:win:WIN_DestroyWindow 0x10042
> trace:win:WIN_DestroyWindow 0x10044
> trace:win:WIN_SetWindowLong 0x2002c 0 0 W
>
> ====================================================================
> These are my trace additions  in SetWindowLong to help me follow the
> execution of the code
>
> trace:win:WIN_SetWindowLong Fell Through
> trace:win:WIN_SetWindowLong Release Ptr
> trace:win:WIN_SetWindowLong 0x2002c 12 0 W
> trace:win:WIN_SetWindowLong Fell Through
> trace:win:WIN_SetWindowLong Server Start Request
> trace:win:WIN_SetWindowLong Default
> trace:win:WIN_SetWindowLong no call Err
> trace:win:WIN_SetWindowLong Default get and Set Win Data
> trace:win:WIN_SetWindowLong Release Ptr
> trace:win:WIN_SetWindowLong Returning 1871960
>
> CRASH! Unhandled Exception
>
> I think the window is being destroyed in reverse for some reason. Thats
> just my gut first feeling based on the above trace and the exception
> output. This is where my knowledge on Windows behavior ends. Does 98
> destroy the windows chain differently than XP? This would explain why
> the exception doesn't occur in 98 but does in XP.
>
> Second Bug:
> This is the ipixel problem which I haven't figured out
> how to debug whats going on there, but think it might  be related to
> this  error:
>
> libGL error: drmMap of framebuffer failed (Cannot allocate memory)
> libGL error: reverting to (slow) indirect rendering
> libGL error: drmMap of framebuffer failed (Cannot allocate memory)
> libGL error: reverting to (slow) indirect rendering
>
> Which I am not sure why this is occurring yet but one bug at a time.
> Where would someone look to trace along the window draw chain to see
> where it dies. Some of the debug flags cause my machine to lock up which
> I know is a driver issue and other lockups could be caused by the above
> exception messing something up in X as the disk still runs when that
> lockup occurs but X is DOA.
>
> Thoughts????? Ideas???? Suggestions??????
>
> Chris

Hi,

Please file bug reports on the Wine Bugzilla - http://bugs.winehq.org/
The second issue looks like 3d graphics are not set up correctly on
your computer. You should ask your favorite Linux forum about that.

Oh this is already reported as a bug... as to the second I know.. was just looking for some pointers...

Need help actually understanding the way windows are handled in 98 vs XP  .

The graphic are set up correctly though...

Chris