March 2001 - Wine-Devel - list.winehq.org

Re: OpenGL Visual Management

by lawson_whitney＠juno.com

On Mon, 26 Mar 2001, Gavriel State wrote: > This patch fixes several issues with the way OpenGL manages visuals: > > - It always uses a double-buffered visual if one is available, even when > not running Wine in --desktop mode. Previously, we just hoped that the > default visual was double buffered, which is isn't in some DRI GL drivers. > > - It ensures that all colormaps created use the double-buffered visual if > it exists. This prevents problems where DRI GL implementations fail > to work unless the colormap visual matches the window visual matches the > glX visual. > > - It gets around similar visual issue with the default GL context created for > apps that don't create their own contexts before trying to use GL functions. > > Note that we are not able to support the wgl ChoosePixelFormat/DescribePixelFormat > APIs properly. Some of the infrastructure for this exists in graphics/x11drv/opengl.c > so that it can be done when the time comes. This patch explicitly removes the wgl > code that tries to match the OpenGL visual to a requested pixel format, because > that won't work until we can dynamically remap HWNDs to new X11 Windows with > a new visual. > > -Gav > Something is not right, I think. Ordinary apps (Dmitry's About.exe, say) look as if they were using a vga16 server - unless the pointer is over the desktop: then the entire X display is black and white. Without a desktop with managed moving the pointer over the app's window radically changes the palette for the whole screen, but not to black and white. With neither managed nor desktop, the pointer has no effect on the palette. No doubt I am not well set up for DGA: grep -i dga config.cache ac_cv_header_X11_extensions_xf86dga_h=${ac_cv_header_X11_extensions_xf86dga_h=yes} ac_cv_lib_Xxf86dga_XDGAQueryExtension=${ac_cv_lib_Xxf86dga_XDGAQueryExtension=no} ac_cv_lib_Xxf86dga_XF86DGAQueryExtension=${ac_cv_lib_Xxf86dga_XF86DGAQueryExtension=yes} but I don't see why DGA support should disturb things so. I haven't really looked into it much yet...maybe you will see right off what you or I have done wrong? Regards, Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

March 29, 2001

Re: [PATCH] HOOK_CallHook

by David Elliott

Francois Jacques wrote: > Group, This patch comes from investigation of a bug that was observed in > RedHat 7.0 and not observed in RedHat 6.1. After a debugging session that > involved Stephane and I, we found out that it was a compiler issue (which > I feared from the start, but wasn't considering it seriously... > arghhh). The RedHat 6.1 installation has gcc version 2.91.66 and the > RedHat 7.0 installation has gcc version 2.96-20000731 (RedHat Linux 7.0) > with latest updates from RedHat. What's happening : 1) HOOK_CallHook is > being called (notice wParam and lParam arguments)2) Local variables > wParamOrig and lParamOrig are set to wParam and lParam values3) Mapping > function is called (MapFunc) with the *addresses* of wParam and lParam so > those get changed before we call the hook4) After MapFunc is called, > wParamOrig and lParamOrig values also changed to the new values of wParam > and lParam (!) Explanation : Down to the assembly level code, the compiler > doesn't create wParamOrig and lParamOrig on the stack. Instead, it > directly use wParam and lParam. Fix : add volatile to wParamOrig and > lParamOrig to prevent optimizations on those variables (aka. force their > presence on the stack) This kind of begs the question: how many more places in Wine should the volatile keyword be used? I find it hard to believe that this is the only spot in a large very low-level project like Wine. -Dave

March 29, 2001

Re: Nasty Wine/kernel bug, anyone?

by Ulrich Weigand

> If I were going to make more WAGs (Wild Assed guesses), > I'd hazard a guess that this was due to my Alsa sound system > (running on the AC97 codec on my Asus motherboard). > > I tried to walk the stack back, but didn't get very far > (after the first time of wrongly computing the hex offset > from a .s file, I gave off, stomped off to look > for a better disassembler and gave up). If you have the 'vmlinux' file, try objdump --disassemble vmlinux > My best guess is that we're coming through dentry_open > (xc012e7fe)/ chrdev_open (0xc012f66c) > /soundcore_open (0xc01bbf71). However, I wasn't > seeing a familiar EBP/EIP pattern, so I'm possibly just > pulling random symbols out of the air. Yes, this appears to the proper trace: c0108d7f system_call c012ea2c sys_open c012e732 filp_open c012e7fe dentry_open c012f66c chrdev_open c01bbf71 soundcore_open d0826a42 <module> d087ce3e <module> c0107aa4 __down_failed c010794f __down ........ schedule [I am assuming that you have 256MB main memory. Correct?] Now, the question is still, who is sleeping on that semaphore and why? >From the call trace, it would seem that some sound-related module is loaded, which does a down() on some semaphore in its open() routine. We even know which semaphore: cff267ac. (This does not help much, as this is would appear to be somewhere in kmalloc()ed memory ...) We can continue to track in two directions. First, we can try to locate the point within the Wine application where the open() syscall is performed. >From the trace we see that the system call instruction is located at 40303a24, and the stack pointer points to 405c6638. The system call itself is an open( 41610240, O_WRONLY|O_NDELAY ) [The stack pointer value is rather weird, I'd say ...] This particular open mode occurs in the Wine source only in dlls/winmm/wineoss/audio.c, which confirms the sound hypothesis. The next time you reproduce the bug, could you please add the output of /proc/<pid>/maps for the hanging Wine process? This way, we could further analyse these pointers to Wine user space ... The more promising way to track the problem, however, is to find out which module those d* addresses above reside in. If the modules are still loaded, the output of /proc/ksyms should at least give a hint. For a more refined symbol lookup, it is best to use the 'ksymoops' tool, which correlates the /proc/ksyms output with the ELF symbols read from the object modules themselves. To do so, write this: Call Trace: [<d0826a42>] [<d087ce3e>] to a file and pipe the file through ksymoops. In any case, this would seem to be clearly a bug in that sound module. I don't know, however, why only Wine would trigger that bug ... Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 28, 2001

[CHECKER] Stanford enhanced gcc found 741 errors in wine source

by Dan Kegel

... just kidding. Has anyone else been watching the success of the Stanford MC team in finding linux kernel bugs using an enhanced version of gcc? See http://www.lwn.net/2001/0322/kernel.php3 and scroll down to 'Global Kernel Analysis'. They've done a fabulous job. This and the Kernel Janitor project promise to help keep the linux kernel stable even in those funny corner cases that don't get exercised enough to make the bugs easy to track down. Would Wine be another possible application of the MC work? - Dan

March 27, 2001

Re: Nasty Wine/kernel bug, anyone?

by Ulrich Weigand

> Process 1503 found at c2cd8000, esp c2cd9e04 > Call Trace: [<c010794f>] [<c2cd8000>] Hmpf, this is not quite what I expected :-/ (Maybe the kernel is compiled with -fomit-frame-pointer?) Could you try using a modified version of dump that will at least dump out the complete kernel stack so that we can analyse it manually? --- dump/dump.c Mon Mar 26 23:47:18 2001 +++ dump.new/dump.c Tue Mar 27 21:55:11 2001 @@ -95,6 +95,18 @@ printf( " [<%08x>]", eip ); } printf( "\n" ); + +{ + unsigned int stack[2048]; + unsigned int start = esp & -16; + unsigned int i, len = addr + 8192 - start; + read_kernel( stack, start, len ); + + printf( "Stack Dump:\n" ); + for ( i = 0; i < len/16; i++ ) + printf( "0x%08x: %08x %08x %08x %08x\n", + start + 16*i, stack[4*i], stack[4*i + 1], stack[4*i + 2], stack[4*i + 3] ); +} } int main( int argc, char *argv[] ) Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 27, 2001

Re: Nasty Wine/kernel bug, anyone?

by Jeremy White

Just spent 30 minutes trying to reproduce with Outlook, and now, of course, I can't. I may well have pressed ^C at some point; I'm learning that Outlook does, eventually (2-3 minutes) come up (but promptly crashes). However, whilst trying something else, I had another winelib program crash. So, I grabbed what info from it I could in the attached file. Jer Stuck Process: jwhite 1503 0.5 2.6 32956 6684 pts/2 D 20:07 0:02 testapp -debugmsg +relay ps -p 1503 -o pid,wchan PID WCHAN 1503 down dump 1503 Process 1503 found at c2cd8000, esp c2cd9e04 Call Trace: [<c010794f>] [<c2cd8000>] /usr/src/linux-2.4.0/System.map fragment: c01078f8 T __down c0107994 T __down_interruptible c0107a60 T __down_trylock c0107a9c T __down_failed . . . c02f6c14 A _end I have the feeling there is something more I could have gotten you here, but I'm not sure what. Last 21 lines or so of a relay log: ebp=405b679c esp=405b6788 ds=002b es=002b gs=0000 flags=00000202 Ret kernel32.4: VxDCall3() retval=00000002 ret=bfe819e3 fs=008f eax=00000002 ebx=417c4188 ecx=00000001 edx=405b67cc esi=0000006c edi=405b67cc ebp=405b679c esp=405b6794 ds=002b es=002b gs=0000 flags=00000202 Call kernel32.455: GetPrivateProfileStringA(417bb8e7 "mci",00000000,417bb80a "",403d5b48,00000800,417bc626 "SYSTEM.INI") ret=4178b025 fs=008f Ret kernel32.455: GetPrivateProfileStringA() retval=00000051 ret=4178b025 fs=008f Call kernel32.2: VxDCall1(00010013) ret=bfe8165f fs=008f eax=00000001 ebx=417c4188 ecx=fffffffe edx=417c20e4 esi=0000006c edi=403d5b9a ebp=405b67d4 esp=405b67a0 ds=002b es=002b gs=0000 flags=00000202 Ret kernel32.2: VxDCall1() retval=00000000 ret=bfe8165f fs=008f eax=00000000 ebx=417c4188 ecx=fffffffe edx=417c20e4 esi=0000006c edi=403d5b9a ebp=405b67d4 esp=405b67a4 ds=002b es=002b gs=0000 flags=00000202 Call kernel32.947: lstrcpynA(405b668c,417bb4a7 "wineoss.drv",00000080) ret=4177f8db fs=008f Ret kernel32.947: lstrcpynA() retval=405b668c ret=4177f8db fs=008f Call kernel32.553: HeapAlloc(40360000,00000000,0000001c) ret=4177f666 fs=008f Ret kernel32.553: HeapAlloc() retval=403d8774 ret=4177f666 fs=008f Call kernel32.601: LoadLibraryA(405b668c "wineoss.drv") ret=4177f680 fs=008f Ret kernel32.601: LoadLibraryA() retval=417c8000 ret=4177f680 fs=008f Call kernel32.459: GetProcAddress(417c8000,417ba14b "DriverProc") ret=4177f6a0 fs=008f Ret kernel32.459: GetProcAddress() retval=417d8e90 ret=4177f6a0 fs=008f Call wineoss.1: DriverProc(00000000,403d8774,00000001,00000000,00000000) ret=4177f3e2 fs=008f

March 27, 2001

TransGaming & SourceForge

by Gavriel State

Hi everyone, Just wanted to let everyone know that the TransGaming DirectX development is now being hosted at SourceForge. You can get updates from our live CVS tree, discuss DirectX specific issues on the 'WineX-devel' mailing list, etc. The SourceForge project page is at: http://sourceforge.net/project/winex The CVSROOT for CVS is: :pserver:anonymous(a)cvs.winex.sourceforge.net:/cvsroot/winex We're doing WineHQ merge-ins every week or two, so things should stay relatively up to date. Currently, we're undertaking a rearchitecture of the Direct3D work, along the lines of the DDraw HAL work we've been contributing to the WineHQ tree. Basically, we're seperating the glX code into the x11drv for device independance. We're also redoing the front end interfaces to start supporting D3D APIs both older and newer than D3D 7. On the OpenGL front, we've done some work on the visual management code that solves some problems we were seeing where you couldn't get a double-buffered visual on some cards without using -desktop mode. I should be posting a patch for this back to wine-patches very soon. There are still some kinks to be worked out... -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

March 26, 2001

Re: WineX-Transgaming

by Gavriel State

"Gottfried F. Zojer" wrote: > > Hi, > > I m new to this list.So I hope that a little bit of feedback is coming > to my > first posting.Is somebody on this list who is working on DirectX APi s > into WINE.I heart from the WineX Api from Transgaming Tech. > It s hosted on SourgeForge.Unfortuntely this server must be a very slow > because it was impossible for me to get access to the CVS-Tree. > Thanks in advance If you have technical questions specific to the new DirectX code, you're best off directing them to the new WineX-devel list we've created on SourceForge. If you can't reach SourceForge at all, give it another go later in the day, it occasionally has load issues. If you are having persistant problems with SourceForge CVS, you can apply one of the earlier patches from the TransGaming website to the WineHQ tree. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

March 26, 2001

Re: Nasty Wine/kernel bug, anyone?

by Ulrich Weigand

Hi Jeremy, > > Great :-( Now the interesting thing would be to know *which* > > semaphore this is waiting on ... > > > > I'd really like to see a kernel stack backtrace on this. However, > > there doesn't appear to be an easy way to do so ... > > I was pretty sure this was going to be a fun one... OK, I've hacked together a silly tool that generates a kernel stack backtrace from userspace. Note that this doesn't do much error checking; please compile against kernel sources that match the running kernel, and don't try to use the tool for *running* processes ... To generate the dump, just run 'dump <pid>'. The result is suitable for piping through 'ksymoops' for symbol lookup. Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 26, 2001

Re: Nasty Wine/kernel bug, anyone?

by Jeremy White

> > > > PID WCHAN > > 2531 down > > Great :-( Now the interesting thing would be to know *which* > semaphore this is waiting on ... > > I'd really like to see a kernel stack backtrace on this. However, > there doesn't appear to be an easy way to do so ... I was pretty sure this was going to be a fun one... > > > > Hmm. Could you try getting a Wine trace (especially the server/ > > > client interaction)? > > > > ftp://wine.codeweavers.com/pub/other/outlook-server.out.gz > > (about 160K). > > Is this from the same run as above? I.e. is the process > with pid 2531 part of this trace? Yes. > > B.t.w. the trace appears to show that you pressed ^C to > terminate the process. Does the symptom (processes in state D) > show *before* you press ^C or only afterwards? > I'm nearly certain that I see the process show up as run state 'D' prior to pressing ^C, but I may be wrong. I tend to notice this problem, of course, only after pressing ^C and trying to do a killall. I'll poke around a bit more (sorry for not reproducing this more quickly; since it tends to cost me a reboot and a lengthy fsck to repair, I'm a little slow to iterate the test cycles <g>). Jer

March 26, 2001