On Tue, May 4, 2010 at 6:54 AM, The Wanderer <[email protected]> wrote: > I actually did this yesterday, shortly before leaving for work. Attached > please find the result of > > xtrace /tmp/wow &> /tmp/wow-winedebug-try3
Thanks, that's a start. It's hard to tell exactly what's going on though, because apparently there are five different X connections involved, and probably several processes. Maybe asking xtrace for timestamps would help. Still, it looks like these messages go together: 004:<:0008: 12: ATIFGLEXTENSION-Request(140,7): UNKNOWN ... 004:>:0008:1232: unexpected Reply: data1=0x01 data2=0x00 unparsed-data=... 004:<:0009: 12: ATIFGLEXTENSION-Request(140,0): UNKNOWN ... 004:>:0009:228: unexpected Reply: data1=0x01 data2=0x00 unparsed-data=... ../../src/xcb_io.c:445: _XReply: Assertion `!dpy->xcb->reply_data' failed. err:module:attach_process_dlls "opengl32.dll" failed to initialize, aborting This is the only connection that issued a minor-opcode 0 request, which apparently is FGLGetDriverData, but another connection issued several minor-opcode 7 requests, and continued processing responses fine afterwards. I can't find any public information on ATIFGLEXTENSION minor opcodes higher than 6, so I can't decode that or guess what it means. I'm wondering if there are two (or more) different functions in FGLRX's libGL that all issue this minor opcode 7, and maybe one of them does it wrong. By the way, the connection that issued the above requests does not seem to have respected your WINEDEBUG="+synchronous" setting. Dunno what that means, though it might just be it died before it could sync the first time. > I'm familiar with doing that (well, 'gdb foo' and 'run -v quux'), but I > could have sworn that last time I tried it on a failed assertion, the > 'bt full' returned no information, because the running program had > already exited because of the failed assertion. No, assert calls abort(), which kills the current process with SIGABRT, which GDB traps before the process actually exits. Of course if this application is forking, it can be quite tricky to get gdb attached to the process that actually dies. It may be easier to run `ulimit -c unlimited` to enable core dumps, then let the application die, then use `gdb -c` to inspect the coredump. When you have the failed process in GDB, it would also help to go to the _XReply stack frame and print dpy->request and dpy->last_request_read. I'm guessing those will be 9 and 8, respectively. A stack trace would be useful for confirming my hypothesis that the failure is being detected while looking for the FGLGetDriverData reply. If nothing else I can disassemble _XReply's caller and maybe spot a problem that way (ugh, hate binary-only drivers). Of course a minimal test case would help a lot here, and knowing what function is running when this fails may help you find simpler application that fails the same way. Hey, does `glxinfo` assert-fail for you? Jamey -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
