WINEDEBUG=+trace doesn't really do anything. using WINEDEBUG=trace+all (or just +all) will enable *lots* of debug output.
However, what you want to do is to add something like this to your cuda wrapper:
At the beginning of the file, after the includes:
WINE_DEFAULT_DEBUG_CHANNEL(cuda);
Then in each function:
void cudaSomething(int a, const char *b) {
TRACE("(%d, %s)\n", a, b);
}
Then run your app with WINEDEBUG=+cuda
That will give you some information how far the app gets in talking to your wrapper and the native lib
From: wine-devel-bounces@winehq.org [mailto:wine-devel-bounces@winehq.org] On Behalf Of Seth Shelnutt Sent: Monday, July 14, 2008 9:31 PM To: Michael Karcher; wine-devel@winehq.org Subject: Re: CUDA wrapper
We have tried to get the trace, many different ways, but to no avail. I've read through everything on running a trace of it and I've tried it with different files and it works fine but when we try it with the folding client we don't get any trace. The cudart.dll.so which is placed in the /usr/local/lib/wine folder is being recognized by wine as we are not longer getting the not implemented error but now it is just a matter of determining what function it isn't liking. I've double check all the functions and they all seem to be fine minus the 4 direct3d functions and 6 functions which contain c++ coding. The 6 functions though involve copying memory, symbol size, and channel format. They don't involve anything that would be needed to start the folding client, they are all things that would cause a fault after the GPU has started calculations, or so I am lead to believe.
As always the latest code is available at http://shelnutt.twomurs.com/patches/cuda/ and a 7z of it all at http://shelnutt.twomurs.com/patches/cuda.7z
zerix01@DeepThought:~/.wine/drive_c/Program Files/Folding@home/Folding@home-gpu$ WINEDEBUG=+trace winedbg Folding@home.exe WineDbg starting on pid 0016 start_process () at /media/md0/wine/wine/dlls/kernel32/process.c:904 0x7b877d02 start_process+0xc2 [/media/md0/wine/wine/dlls/kernel32/process.c:904] in kernel32: movl %esi,0x0(%esp) Unable to open file '' Wine-dbg>n fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers fixme:win:EnumDisplayDevicesW ((null),0,0x33f40c,0x00000000), stub! err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0xf7f80aaf Invalid address (0x7b877d07 start_process+0xc7) for breakpoint 0, disabling it Process of pid=0016 has terminated Wine-dbg>quit zerix01@DeepThought:~/.wine/drive_c/Program Files/Folding@home/Folding@home-gpu$ WINEDEBUG=+trace wine Folding@home.exe fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and32 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers fixme:win:EnumDisplayDevicesW ((null),0,0x32f40c,0x00000000), stub! err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0xf7fddaaf zerix01@DeepThought:~/.wine/drive_c/Program Files/Folding@home/Folding@home-gpu$
Thanks,
Seth Shelnutt
On Sun, Jul 13, 2008 at 5:26 AM, Michael Karcher wine@mkarcher.dialup.fu-berlin.de wrote:
No, thats boring. Your program crahsed at address 0xf7fcaaf. IIRC code 0xc0000005 is a general protection fault. After your program has crashed, the breakpoint wine automatically sets to catch program startup is not valid anymore (there is no program to break anymore), that causes the message you quoted.
Whats strange is that the debugger does not catch the exception. While the first-chance event can be disabled, you should get a last-chance exception catch right before the program dies. See http://www.winehq.org/site/docs/winedev-guide/dbg-config for more info about configuring the debugger.
Have you tried a relay trace yet?
Regards, Michael Karcher