Made ENTER_GL() - LEAVE_GL() free X11 lock on exception inside opengl, code
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
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
On Mon, Jun 30, 2008 at 9:05 PM, Chris Ahrendt <celticht32(a)aol.com> 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.
-----Original Message----- From: Lei Zhang <thestig(a)google.com> To: celticht32(a)aol.com Cc: wine-devel(a)winehq.org 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 <celticht32(a)aol.com> 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
participants (4)
-
celticht32＠aol.com -
Chris Ahrendt
-
Lei Zhang -
Louis. Lenders