From: Brian P. <bri...@tu...> - 2004-04-21 16:16:29
|
Andreas Stenglein wrote: > Am 2004.04.21 00:26:41 +0200 schrieb(en) Brian Paul: > [...] > >>Do you mean glXCreateContext()? Are the function parameters the same >>for both calls? >> > > yes its called twice, no with different parameters. > > I tried to see what happens with the Mesa-Software-Renderer libGL with DEBUG on > and it doesnt work, too. But different error/location. > Its only working with indirect GLX. > > best regards, > Andreas > > > Maybe thats helpful: > > >>wine cryonics_are_we.exe > > Fake_glXQueryExtension > Fake_glXChooseVisual: dpy=0x12a830, screen=(nil), list=0x4065fa10 > xmvis=0x130640, xmvis->vishandle=0x1304a8 > Fake_glXCreateContext: dpy=0x12a830, visinfo=0x145898, share_list=0, direct=1 > glxCtx=0x145a30 > Fake_glXMakeContextCurrent: dpy=0x12a830, draw=0x48, read=0x48, ctx=0x145a30 > glGetString(0x1f03); > glGetString(0x1f02); > Fake_glXCreateContext: dpy=0x12a830, visinfo=0x2ea1b0, share_list=0, direct=1 > glxCtx=0x2ea348 > Fake_glXMakeContextCurrent: dpy=0x12a830, draw=0x180001d, read=0x180001d, ctx=0x2ea348 > glViewport(0, 0, 640, 480); > glMatrixMode(0x1701); > glLoadIdentity(); > glMultMatrixd(0x4065fc24); > glMatrixMode(0x1700); > glLoadIdentity(); > fixme:dsound:IDirectSoundImpl_SetCooperativeLevel level=DSSCL_PRIORITY not fully supported > glPushAttrib(0x40000); > fixme:msvcrt:_XcptFilter (-1073741819,0x4065f634)semi-stub > wine: Unhandled exception (thread 0009), starting debugger... > > [now winedbg tries to load symbols...] > > Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x400bd587). > In 32-bit mode. > 0x400bd587 (memcpy+0x27 in libc.so.6): repe movsl (%esi),%es:(%edi) > Wine-dbg>back > Backtrace: > =>0 0x400bd587 (memcpy+0x27 in libc.so.6) (ebp=4065fa54) > 1 0x40b78cd7 (_mesa_memcpy+0x27 in libGL.so.1) (ebp=4065fa84) > 2 0x40b0fed3 (_mesa_PushAttrib+0xa73 in libGL.so.1) (ebp=4065fb84) > 3 0x40b1f474 (glPushAttrib+0x44 in libGL.so.1) (ebp=4065fbc4) > 4 0x40f00b70 (wine_glPushAttrib+0x50(mask=0x40000) [opengl_norm.c:2441] in OPENGL32.DLL) (ebp=4065fbd8) > 5 0x0040442b (cryonics_are_we.exe.UPX0+0x342b in cryonics_are_we.exe) (ebp=4065fcc0) > 6 0x00404a1a (cryonics_are_we.exe.UPX0+0x3a1a in cryonics_are_we.exe) (ebp=4065fdfc) > 7 0x00404664 (cryonics_are_we.exe.UPX0+0x3664 in cryonics_are_we.exe) (ebp=4065fe90) > 8 0x00425c13 (cryonics_are_we.exe.UPX1+0x3c13 in cryonics_are_we.exe) (ebp=4065ff2c) > 9 0x404d3842 (start_process+0x92(arg=0x0) [process.c:785] in KERNEL32.DLL) (ebp=4065fff4) > 10 0x4001ad1d (wine_switch_to_stack+0x11 in libwine.so.1) (ebp=00000000) It would help if a stack trace were available. Otherwise, all I can tell is that glPushAtrrib(GL_TEXTURE_BIT) is the last GL call made. Can you recompile Mesa with the -g (and no -O) flag and use a debugger to get a stack grace? Or, if you're on Linux, valgrind would help identify any memory-related issues. I added checks of the return value for _tnl_CreateContext(), etc. in the x11 and osmesa drivers. It would be easy to add them to the DRI drivers, but my suspicion is that the real problem is elsewhere. -Brian |