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
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
