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