Re: Debugging and steam
On 11 February 2013 01:55, Gediminas Jakutis gedimi...@varciai.lt wrote: I tried every idea I could muster on how to get a pure log of the game. Not a single one turned out to be effective. I am all out of ideas now. So if anyone had to deal with this and found a satisfactory solution, please enlighten me. Thank You in advance! There are some tricks you can do to limit what executables you turn debugging on for, or to e.g. dump the output to separate files. You'll mostly want to look at debug_init() in libs/wine/debug.c. If this is a simple crash though, perhaps just passing -nobreakpad to the application is enough to get a good backtrace.
Re: Debugging wine/windows applications
On Sat, Jul 07, 2012 at 12:17:00AM +0300, John Yani wrote: I tried to run wine under gdb and failed. Using multiprocess gdb I endup with weird trace: 0xf7ffd430 0x7bc846f9 0x7bc8480f 0x7bc84855 0x7bc42a94 0x7bc433b1 0x7b8772f7 0x7ebab89b 0x7bc80014 0x7bc8005d Where 0x7** addresses are not connected to any module. And 0xf** addresses are from /lib/ld-linux.so.2, debug symbols for which I can't find. Can somebody explain what's hapenning? Running wine with winedbg under gdb fails with message err:module:LdrInitializeThunk Main exe initialization for LC:\\windows\\system32\\notepad.exe failed, status c022 Is there any tutorial on how to run wine with applications under gdb? winedbg can hook gdb into itself, which will make this work better I think. winedbg --gdb notepad.exe Ciao, Marcus
Re: Debugging wine/windows applications
Did you mean './wine winedbg --gdb notepad'? Because I can't find winedbg binary.
Re: Debugging wine/windows applications
On Sat, Jul 07, 2012 at 01:11:42PM +0300, John Yani wrote: Did you mean './wine winedbg --gdb notepad'? Because I can't find winedbg binary. This would be the same. There usually is a winedbg wrapper installed that does the same, but for all purposes its the same thing. Ciao, Marcus
Re: Debugging wine/windows applications
Unfortunately, it doesn't work: ./wine winedbg --gdb notepad.exe err:module:LdrInitializeThunk Main exe initialization for LC:\\windows\\system32\\notepad.exe failed, status c022 0023:0024: create process ''/0x1106c0 @0x7ebe233c (00) fixme:dbghelp:EnumerateLoadedModulesW64 If this happens, bump the number in mod 0023:0024: create thread I @0x7ebe233c Maybe winedbg wrapper is not exactly the same? How do I tell winedbg wrapper to use wine from the specific folder? On 7 July 2012 13:17, Marcus Meissner mar...@jet.franken.de wrote: On Sat, Jul 07, 2012 at 01:11:42PM +0300, John Yani wrote: Did you mean './wine winedbg --gdb notepad'? Because I can't find winedbg binary. This would be the same. There usually is a winedbg wrapper installed that does the same, but for all purposes its the same thing. Ciao, Marcus
Re: Debugging wine/windows applications
I tried WINELOADER=./wine winedbg --gdb notepad And its output is the same as ./wine winedbg --gdb notepad
Re: Debugging wine/windows applications
Maybe it's because I'm building on chrooted Ubuntu x32 and run on Ubuntu x64?
Re: Debugging wine/windows applications
On Sat, Jul 07, 2012 at 01:25:12PM +0300, John Yani wrote: I tried WINELOADER=./wine winedbg --gdb notepad And its output is the same as ./wine winedbg --gdb notepad Well, i have a installed wine... but doing this there: wine winedbg.exe --gdb notepad.exe 0042:0043: create process 'C:\Windows\System\notepad.exe'/0x1106f8 @0x7ee012b0 (00) fixme:dbghelp_dwarf:dwarf2_parse_line_numbers Unsupported extended opcode 0 fixme:dbghelp_dwarf:dwarf2_parse_line_numbers Unsupported extended opcode 0 fixme:dbghelp_dwarf:dwarf2_parse_line_numbers Unsupported extended opcode 0 fixme:dbghelp_dwarf:compute_location Only supporting one breg (edi/24 - esi/23) 0042:0043: create thread I @0x7ee012b0 GNU gdb (GDB) SUSE (7.2-3.3) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-suse-linux. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. 0042:0043: loads DLL C:\Windows\System\KERNEL32.dll @0x7b81 (00) 0042:0043: loads DLL C:\Windows\System\ntdll.dll @0x7bc1 (00) 0042:0043: loads DLL C:\Windows\System\advapi32.dll @0x7e7e (00) 0042:0043: loads DLL C:\Windows\System\gdi32.dll @0x7e85 (00) start_process (peb=0x7ffdf000) at /home/marcus/projects/wine/dlls/kernel32/process.c:1083 1083return call_process_entry( peb, entry ); trace: 98 = 80 Wine-gdb bt #0 start_process (peb=0x7ffdf000) at /home/marcus/projects/wine/dlls/kernel32/process.c:1083 #1 0x7bc75670 in call_thread_func_wrapper () from /home/marcus/projects/32wine/dlls/ntdll/ntdll.dll.so #2 0x7bc7794d in call_thread_func (entry=0x7b85e1c0 start_process, arg=0x7ffdf000, frame=0x33ffc8) at /home/marcus/projects/wine/dlls/ntdll/signal_i386.c:2522 #3 0x7bc7564e in call_thread_entry_point () from /home/marcus/projects/32wine/dlls/ntdll/ntdll.dll.so #4 0x7bc4d7de in start_process (kernel_start=0x7b85e1c0) at /home/marcus/projects/wine/dlls/ntdll/loader.c:2653 #5 0xf75c4bad in wine_call_on_stack () from /home/marcus/projects/32wine/libs/wine/libwine.so.1 #6 0xf75c4c6b in wine_switch_to_stack (func=0x7bc4d7c0 start_process, arg=0x7b85e1c0, stack=0x34) at /home/marcus/projects/wine/libs/wine/port.c:59 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Wine-gdb c Continuing. ^C Program received signal SIGTRAP, Trace/breakpoint trap. 0xe423 in ?? () Wine-gdb bt #0 0xe423 in ?? () #1 0x7bcb6ff4 in ?? () from /home/marcus/projects/32wine/dlls/ntdll/ntdll.dll.so Backtrace stopped: previous frame inner to this frame (corrupt stack?) Wine-gdb Its not having the correct symbols there, but basically works. Or I also tried: $ wine notepad.exe ... wait until window shows ... $ ps auxw|grep notepad marcus 26694 0.4 0.1 1785696 10084 pts/6 t12:27 0:00 notepad.exe $ gdb /usr/bin/wine (gdb) attach 26694 0xe425 in __kernel_vsyscall () (gdb) bt #0 0xe425 in __kernel_vsyscall () #1 0xf764e0e3 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:82 #2 0x7bc796c8 in wait_reply (cookie=0x32f3bc) at /home/marcus/projects/wine/dlls/ntdll/sync.c:807 #3 0x7bc7bb03 in NTDLL_wait_for_multiple_objects (count=1, handles=0x32f438, flags=4, timeout=0x0, signal_object=value optimized out) at /home/marcus/projects/wine/dlls/ntdll/sync.c:1122 #4 0x7bc7bbf5 in NtWaitForMultipleObjects (count=1, handles=0x32f438, wait_all=0 '\000', alertable=0 '\000', timeout=0x0) at /home/marcus/projects/wine/dlls/ntdll/sync.c:1160 #5 0x7b86fe3f in WaitForMultipleObjectsEx (count=1, handles=0x32f61c, wait_all=0, timeout=4294967295, alertable=0) at /home/marcus/projects/wine/dlls/kernel32/sync.c:190 #6 0x7e4c3bc5 in WaitForMultipleObjectsEx_ichk (count=1, handles=0x32f61c, timeout=4294967295, mask=1279, flags=0) at /home/marcus/projects/wine/include/winbase.h:2600 #7 X11DRV_MsgWaitForMultipleObjectsEx (count=1, handles=0x32f61c, timeout=4294967295, mask=1279, flags=0) at /home/marcus/projects/wine/dlls/winex11.drv/event.c:472 ... Ciao, Marcus
Re: Debugging wine/windows applications
So, you didn't try to build wine? Installed wine also works for me.
Re: Debugging wine/windows applications
Attach works. Thanks!
Re: Debugging wine/windows applications
Actually, to enable attach, I had to make ptrace more permissive: https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection by doing echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope To run it under eclipse I had to choose Traditional Attach to process instead of DSF. On 7 July 2012 13:53, John Yani van...@gmail.com wrote: Attach works. Thanks!
Re: Debugging Wine with Lightroom 3.5
OK, thanks for your help. I'll try this when I'll be back to home. RB - Mail original - De: Frédéric Delanoy frederic.dela...@gmail.com À: rolan...@free.fr Cc: Juan Lang juan.l...@gmail.com, wine-devel@winehq.org Envoyé: Mardi 20 Décembre 2011 12:28:57 Objet: Re: Debugging Wine with Lightroom 3.5 On Tue, Dec 20, 2011 at 10:04, rolan...@free.fr wrote: Yes, I'm that kind of person (I'm the developer of Xfe and TexMaths) but I've seen the +relay logs logs and they are indeed very huge, even for me! RB What you can do to reduce/manage the log size: 1. Launch any application (without logging), e.g. notepad, so the wine startup doesn't produce (much) output 2. Run your app with the wine debugger to help with debug output control http://www.winehq.org/docs/winedev-guide/dbg-commands#WINEDBG-DBG-CHAN http://www.winehq.org/docs/winedev-guide/dbg-control I think those links might help. Frédéric
Re: Debugging Wine with Lightroom 3.5
Yes, I'm that kind of person (I'm the developer of Xfe and TexMaths) but I've seen the +relay logs logs and they are indeed very huge, even for me! RB - Mail original - De: Juan Lang juan.l...@gmail.com À: Roland Baudin rolan...@free.fr Cc: Wine Devel wine-devel@winehq.org Envoyé: Dimanche 18 Décembre 2011 16:15:49 Objet: Re: Debugging Wine with Lightroom 3.5 Hi Roland, On Sun, Dec 18, 2011 at 6:46 AM, Roland Baudin rolan...@free.fr wrote: Yes, I suspected such a mechanism. Now if I understand well I have to find which one is the builtin mechanism and which one is the fallback mechanism. Is there some documentation around about the differences between Vista and XP? That list would be large, too large to be conveniently listed in one place. What one could do, which is unfortunately often equally tedious, is to compare +relay logs from running the app in Wine under both modes. If looking through multi-GB log files is your idea of fun, you have the makings of a Wine developer ;) --Juan
Re: Debugging Wine with Lightroom 3.5
On Tue, Dec 20, 2011 at 10:04, rolan...@free.fr wrote: Yes, I'm that kind of person (I'm the developer of Xfe and TexMaths) but I've seen the +relay logs logs and they are indeed very huge, even for me! RB What you can do to reduce/manage the log size: 1. Launch any application (without logging), e.g. notepad, so the wine startup doesn't produce (much) output 2. Run your app with the wine debugger to help with debug output control http://www.winehq.org/docs/winedev-guide/dbg-commands#WINEDBG-DBG-CHAN http://www.winehq.org/docs/winedev-guide/dbg-control I think those links might help. Frédéric
Re: Debugging Wine with Lightroom 3.5
Replying, also including the wine-devel list, On 12/17/2011 05:15 PM, Roland Baudin wrote: Hi, thanks for the answer. What do you mean by a different execution path? RB The application might decide to execute different code given the Vista settings. It may have a preferred execution path using certain functionality only available for Vista/Windows 7, and a fallback path for XP. Pseudocode: if (system is Vista+) use_builtin_functionality(); else /* XP */ use_fallback_mechanism(); HTH, Joris
Re: Debugging Wine with Lightroom 3.5
Yes, I suspected such a mechanism. Now if I understand well I have to find which one is the builtin mechanism and which one is the fallback mechanism. Is there some documentation around about the differences between Vista and XP? Anyway, thanks for your help... RB Le 18/12/2011 13:40, Joris Huizer a écrit : Replying, also including the wine-devel list, On 12/17/2011 05:15 PM, Roland Baudin wrote: Hi, thanks for the answer. What do you mean by a different execution path? RB The application might decide to execute different code given the Vista settings. It may have a preferred execution path using certain functionality only available for Vista/Windows 7, and a fallback path for XP. Pseudocode: if (system is Vista+) use_builtin_functionality(); else /* XP */ use_fallback_mechanism(); HTH, Joris -- X File Explorer http://roland65.free.fr/xfe Toutes Choses http://roland65.free.fr/ttc
Re: Debugging Wine with Lightroom 3.5
Hi Roland, On Sun, Dec 18, 2011 at 6:46 AM, Roland Baudin rolan...@free.fr wrote: Yes, I suspected such a mechanism. Now if I understand well I have to find which one is the builtin mechanism and which one is the fallback mechanism. Is there some documentation around about the differences between Vista and XP? That list would be large, too large to be conveniently listed in one place. What one could do, which is unfortunately often equally tedious, is to compare +relay logs from running the app in Wine under both modes. If looking through multi-GB log files is your idea of fun, you have the makings of a Wine developer ;) --Juan
Re: Debugging Wine with Lightroom 3.5
It's possible the application is choosing a different execution path, using Vista-specific features. This could be an explanation for the differences you are seeing. HTH, Joris
Re: debugging wine itself with GDB
Le 12/04/2011 22:50, joed...@winedev1.nospam.homeip.net a écrit : I was taking a look at http://wiki.jswindle.com/index.php/Debugging_Wine to see how to debug wine with gdb, and there was reference to starting up gdb using wine-pthread, but I see no such executable now. I can attach gdb after it starts to run, but then do not get all the symbol information. There is wine-preloader but it seems to want an ELF file as an argument. there several ways to do it (assuming you've compiled yourself the sourcing and running from the source tree) 1/ using the gdb proxy from winedbg. you'll the a gdb front end, using winedbg's builtin gdb proxy wine winedbg --gdb winemine 2/ attach to a running process from shell prompt wine winemine /// get unix pid of wine, says 1234 (ps) from shell prompt gdb loader/wine from gdb prompt attach 1234 (some latest unix distro forbids attaching to a running process unless you're root or you've turned off this feature. refer to your distro doc if this happens) 3/ start process from gdb from shell prompt gdb loader/wine /// you may want here to set up some breakpoints first (gdb doesn't break at program startup routine, which winedbg does) /// don't use main as the break address target, you'll get the loader's one, not wine's exec which is bad /// WinMain is fine (unless your apps is CUI) from gdb prompt run winemine from gdb prompt exec-file loader/wine (say yes) from gdb prompt sharedlibrary /// you should be all set which method to use ? up to you g method 2 doesn't allow to debug program startup, but is a bit easier than 3/ to use method 2 or 3 gives you full gdb features, but you have to also understand some wine's internal (shared lib vs DLL) method 1/ allows you to get access to some of the wine internals (see docs) from gdb A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Debugging 64-bit Wine Apps with winedbg
Le 24/09/2010 05:12, Peter Urbanec a écrit :
On 24/09/10 06:43, Eric Pouech wrote:
sure send me the .exe+pdb (+source) I'll have a look at it
Source and binaries sent to Eric in private, so that the list isn't
polluted with megabytes of binaries. If anyone else is interested in
having a copy, please let me know and I'll forward it in private.
Cheers,
Peter Urbanec
with the patchset I've just sent, I get something like:
Thread 0x0021 sleeping 200ms
Thread 0x0022 sleeping 200ms
Thread 0x0020 sleeping 240ms
Thread 0x0023 sleeping 200ms
Thread 0x0021 *** C R A S H I N G ***
wine: Unhandled page fault on write access to 0x at address
0x1400010b3 (thread 0021), starting debugger...
Thread 0x0022 *** C R A S H I N G ***
Thread 0x0023 *** C R A S H I N G ***
WineDbg starting on pid 001f
Thread 0x0020 *** C R A S H I N G ***
First chance exception: page fault on write access to 0x in
64-bit code (0x0001400010b3).
Register dump:
rip:0001400010b3 rsp:7feb8997fbb0 rbp:000140001a20
eflags:00010202 ( R- -- I - - - )
rax: rbx:7feb8bb55000 rcx:000140084478
rdx:000140084480
rsi:7feb8b937401 rdi:7feb8997fbe0 r8:0001
r9:0010d640 r10:7feb8997e850
r11:7feb8997e820 r12: r13:7b86f590
r14:000140d8 r15:7feb8bb5
Stack dump:
0x7feb8997fbb0: 00014006ed20 0020
0x7feb8997fbc0: 7feb8997fa60 0028
0x7feb8997fbd0: 7feb8997fc30 0020
0x7feb8997fbe0: 7feb8997fce0 000140001223
0x7feb8997fbf0: 7feb8997fc30 0010
0x7feb8997fc00: 000140001014
0x7feb8997fc10: 0004 7feb8997fc84
0x7feb8997fc20:
0x7feb8997fc30: 00f0cc01
0x7feb8997fc40: 00c8cc01
0x7feb8997fc50: 00c8cc01
0x7feb8997fc60: 00c8cc01
Backtrace:
=0 0x0001400010b3 Boom::crash_func+0x83(void_ptr=0x7feb8997fc30,
arg_ref=0x7feb8997fc30, tid=32)
[z:\eyeon\u_drive\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:29]
in multiplethreads (0x000140001a20)
1 0x000140001223 main+0x142(argc=1, argv=0x7feb89771130,
thisThread=0xfffe, threadHandle={0x1c, 0x20, 0x24},
threadID=35, oldpri=0, a={{cause_crash=true, delay=240,
pointer=0x0(nil)}, {cause_crash=true, delay=200, pointer=0x0(nil)},
{cause_crash=true, delay=200, pointer=0x0(nil)}, {cause_crash=true,
delay=200, pointer=0x0(nil)}})
[z:\eyeon\u_drive\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:63]
in multiplethreads (0x000140001a20)
2 0x000140001c5c __tmainCRTStartup+0x21b(winver=1281, mainret=0,
osver=2600, winminor=1, posvi=0x7feb8ba24070, osplatform=2,
managedapp=0, initret=0, winmajor=5)
[f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crt0.c:327] in
multiplethreads (0x000140001a20)
3 0x000140001a2e mainCRTStartup+0xd()
[f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crt0.c:195] in
multiplethreads (0x000140001a20)
4 0x7b86f64f start_process+0xbe(peb=0x7feb8bb55000)
[/home/eric/work/wine/dlls/kernel32/process.c:963] in kernel32
(0x000140001a20)
5 0x7feb8abfe43e call_thread_func+0x6d(entry=is not available,
arg=is not available, frame=is not available)
[/home/eric/work/wine/dlls/ntdll/signal_x86_64.c:3036] in ntdll
(0x000140001a20)
6 0x7feb8abfd73e call_thread_entry_point+0x29() in ntdll
(0x000140001a20)
7 0x7feb8abd0da6 start_process+0x15(kernel_start=0x7feb8997fec8)
[/home/eric/work/wine/dlls/ntdll/loader.c:2610] in ntdll
(0x000140001a20)
8 0x7feb8b611ea3 wine_call_on_stack+0x12() in libwine.so.1
(0x000140001a20)
9 0x7feb8b611eb9 wine_switch_to_stack+0x8(func=0x7feb8997fec8,
arg=0x0(nil), stack=0x140084480)
[/home/eric/work/wine/libs/wine/port.c:83] in libwine.so.1
(0x000140001a20)
10 0x7feb8abd5294
LdrInitializeThunk+0x3d3(kernel_start=0x7b86f590, unknown2=is not
available, unknown3=is not available, unknown4=is not available)
[/home/eric/work/wine/dlls/ntdll/loader.c:2666] in ntdll
(0x000140001a20)
11 0x7b874185 __wine_kernel_init+0x914()
[/home/eric/work/wine/dlls/kernel32/process.c:1163] in kernel32
(0x000140001a20)
12 0x7feb8abd5824 __wine_process_init+0x253()
[/home/eric/work/wine/dlls/ntdll/loader.c:2876] in ntdll
(0x000140001a20)
13 0x7feb8b610a0f wine_init+0x28e(argc=is not available,
argv=0x7fff9949d238, error=, error_size=is not available)
[/home/eric/work/wine/libs/wine/loader.c:711] in libwine.so.1
(0x000140001a20)
14 0x7bf00cf1 main+0x80(argc=2, argv=0x7fff9949d238)
[/home/eric/work/wine/loader/main.c:218] in wine-loader
(0x000140001a20)
15 0x7feb8b087c4d __libc_start_main+0xfc(main=is not
available, argc=is not available,
Re: Debugging 64-bit Wine Apps with winedbg
Hi, I'm not a winedbg expert but I think your mis-using it. As it's your software, you can compile it from source and add debug info. I know Visual Studio can create .pdb files but I don't know if winedbg can use it. Personally, I'm using gcc mingw with -g and that perfectly works. The easiest way is to install the linux package (e.g. mingw-w64 for the 64 bits version or mingw32 what I'm using) Then compile your software : (depends on your arch and the 32/64 bits version) $ i586-mingw32msvc-gcc test.c -g -o test.exe and run it through the debugger : $ /home/alex/Projects/wine-git/wine /home/alex/Projects/wine-git/programs/winedbg/winedbg.exe.so test.exe type break main or break WinMain on the console then return (you may have to select the proper main() ) (or break aFunctionName) cont to continue until your breakpoint is reached list to see the next lines of the code step to step in next to step over bt to have the backtrace quit to detach the process from the debugger and exit you can also type break followed by a line number to add a breakpoint on the specified line of the current debugged source file If you need more commands, G**gle is your friend. I hope that that will help you. --- If you have a page fault on create_alpha_bitmap, just type set $BreakOnFirstChance=0 first
Re: Debugging 64-bit Wine Apps with winedbg
On 23/09/10 06:51, Tom Grubbe wrote: problem seems to be getting any kind of stack trace information from the 64-bit winedbg. This used to work with the 32-bit version of winedbg. I can confirm that wine64 winedbg can not produce valid backtraces for multi-threaded programs (.exe + .pdb) generated by the VS2005 64-bit compiler. I get something like the following: Backtracing for thread 001a in process 0008 (Z:\amd64\MultipleThreads.exe): Backtrace: =0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0 (0x7f68ceb3c7a0) Backtracing for thread 0019 in process 0008 (Z:\amd64\MultipleThreads.exe): Backtrace: =0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0 (0x7f68cec4c7a0) Backtracing for thread 0018 in process 0008 (Z:\amd64\MultipleThreads.exe): Backtrace: =0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0 (0x7f68ced5c320) Backtracing for thread 0009 in process 0008 (Z:\amd64\MultipleThreads.exe): Backtrace: =0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0 (0x7f68cef7deb0) 0x7f0d2737b5ab __libc_read+0x2b in libpthread.so.0: syscall Testing on Gentoo x86_64, with wine 1.3.2. Identical source code compiled with VS2005 32-bit compiler running under wine32 produces valid backtraces, although they suffer from bug #20617 * Setting WINEDEBUG to several debug channels has helped some but is difficult to sift through all the noise I don't get much joy from WINEDEBUG output because the crash I encounter appears to be in a DLL initialisation routine called / calling code from Microsoft.VC80.CRT redist code. I can't use the wine msvcrt/msvcp implementations because they are missing implementations for several functions. So any info on strategies to debug 64-bit Wine applications is welcome I would also like to hear any tips for debugging under wine64. I'm finding that even the minidump files produced by wine64 are not much use in VS2005 or VS2008. At least the minidumps from wine32 can provide a little bit of info when loaded into VS2008 debugger. I'm happy to provide test source code, 64-bit and 32-bit binaries and matching PDB files, if anyone is interested in looking at the issue. Cheers, Peter Urbanec
RE: Debugging 64-bit Wine Apps with winedbg
It's good to know someone else is also seeing these problems. In fact here's
my tiny test app that should produce a backtrace but does not with winedbg
64-bit:
% cat Crash.cpp
#include stdio.h
extern C void crash_func()
{
char* p = 0;
*p = 'x';
}
extern C int main()
{
crash_func();
return 0;
}
% wine64 /hex1/test/Crash/x64/Debug/Crash.exe
fixme:heap:HeapSetInformation 0x2ad17069 0 0x2ad17068fcb0 4
wine: Unhandled page fault on write access to 0x at address 0x140001046
(thread 0009), starting debugger...
Unhandled exception: page fault on write access to 0x in 64-bit code
(0x000140001046).
Register dump:
rip:000140001046 rsp:2ad17068fca0 rbp:000140001220 eflags:00010206
( R- -- I - -P- )
rax: rbx:2ad16cab9000 rcx:
rdx:2ad170691230
rsi: rdi:2ad17068fcb0 r8:2ad1706919f0
r9:0004 r10:2ad170691290
r11:10341ff0 r12: r13:2ad16cc72860
r14:000140f0 r15:2ad16cabc000
Stack dump:
0x2ad17068fca0:
0x2ad17068fcb0: 2ad17068fce0 00014000107f
0x2ad17068fcc0:
0x2ad17068fcd0:
0x2ad17068fce0: 2ad16cfa5320 0001400013d2
0x2ad17068fcf0: 00010001 000140006220
0x2ad17068fd00: 2ad16cab9000 0001400018f5
0x2ad17068fd10:
0x2ad17068fd20: 2ad17069
0x2ad17068fd30: 5b5ac005
0x2ad17068fd40: 2ad17068e9e8
0x2ad17068fd50: 00014000122e
Backtrace:
0x000140001046: movb$0x78,(%rax)
Modules:
Module Address Debug info Name (14
modules)
PE 1020-1034f000 Deferredmsvcr90d
PE 4000-4000e000 Deferredcrash
ELF 7be0-7c102000 Deferredwine-loader
ELF 3bdc20- 3bdc41d000 Deferred
ld-linux-x86-64.so.2
ELF 3bdc60- 3bdc957000 Deferredlibc.so.6
ELF 3bdca0- 3bdcc83000 Deferredlibm.so.6
ELF 3bdce0- 3bdd004000 Deferredlibdl.so.2
ELF 3bdd20- 3bdd41b000 Deferredlibpthread.so.0
ELF 3be120- 3be140e000 Deferredlibgcc_s.so.1
ELF 2ad16c07d000-2ad16c3ad000 Deferredlibwine.so.1
ELF 2ad16c3d4000-2ad16c6b9000 Deferredntdllelf
\-PE 2ad16c3f-2ad16c6b9000 \ ntdll
ELF 2ad16cc05000-2ad16cfa6000 Deferredkernel32elf
\-PE 2ad16cc2-2ad16cfa6000 \ kernel32
Threads:
process tid prio (all id:s are in hex)
0008 (D) Z:\hex1\test\Crash\x64\Debug\Crash.exe
00090 ==
000e services.exe
00160
00150
00140
00100
000f0
0011 winedevice.exe
00170
00130
00120
0018 explorer.exe
00190
Backtrace:
err:seh:setup_exception nested exception on signal stack in thread 0009 eip
003bdd20bc05 esp 2ad16cabef68 stack 0x2ad170592000-0x2ad17069
--Tom Grubbe x2609
-Original Message-
From: Peter Urbanec [mailto:winehq@urbanec.net]
Sent: Thursday, September 23, 2010 10:05 AM
To: wine-devel@winehq.org
Subject: Re: Debugging 64-bit Wine Apps with winedbg
On 23/09/10 06:51, Tom Grubbe wrote:
problem seems to be getting any kind of stack trace information from
the 64-bit winedbg. This used to work with the 32-bit version of winedbg.
I can confirm that wine64 winedbg can not produce valid backtraces for
multi-threaded programs (.exe + .pdb) generated by the VS2005 64-bit
compiler.
I get something like the following:
Backtracing for thread 001a in process 0008 (Z:\amd64\MultipleThreads.exe):
Backtrace:
=0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0
(0x7f68ceb3c7a0)
Backtracing for thread 0019 in process 0008 (Z:\amd64\MultipleThreads.exe):
Backtrace:
=0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0
(0x7f68cec4c7a0)
Backtracing for thread 0018 in process 0008 (Z:\amd64\MultipleThreads.exe):
Backtrace:
=0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0
(0x7f68ced5c320)
Backtracing for thread 0009 in process 0008 (Z:\amd64\MultipleThreads.exe):
Backtrace:
=0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0
(0x7f68cef7deb0)
0x7f0d2737b5ab __libc_read+0x2b in libpthread.so.0: syscall
Testing on Gentoo x86_64, with wine 1.3.2. Identical source code
compiled with VS2005 32-bit compiler running under wine32 produces valid
backtraces
Re: Debugging 64-bit Wine Apps with winedbg
I'm happy to provide test source code, 64-bit and 32-bit binaries and matching PDB files, if anyone is interested in looking at the issue. sure send me the .exe+pdb (+source) I'll have a look at it I only tested winedbg on 64bit with gcc A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Debugging 64-bit Wine Apps with winedbg
On 24/09/10 06:43, Eric Pouech wrote: sure send me the .exe+pdb (+source) I'll have a look at it Source and binaries sent to Eric in private, so that the list isn't polluted with megabytes of binaries. If anyone else is interested in having a copy, please let me know and I'll forward it in private. Cheers, Peter Urbanec
Re: Debugging Xfire: need help
Am 18.10.2009 um 15:02 schrieb Warren Dumortier: Xfire was working until version 1.104, but since then it crashed on every Wine version, so the Xfire update broke it under Wine. Here's the problem: Xfire crashes every time you interact with it's GUI, well most of the time... When using the keyboard it crashes sometimes, but when using the mouse it crashes every time... I used winedbg to find the possible cause, but i can't figure it out myself, however here is the output: http://pastebin.be/21435 As you can see, it crashes in user32/button.c, because i clicked on a button. xfire_toucan_39439 is its hooking DLL that is injected into every process(even non-games ones, and Xfire itself). It could be a hook going bad. I doubt it, because as far as I can see Xfire only tries to hook D3D's EndScene calls, but on the other hand Xfire worked for me in my hooking-enabled tree. My hooking patches are in Wine git by now - but you need binutils and gcc from SVN to enable that code. A short summary: 1) Install GNU binutils from cvs. You don't have to install it system- wide. You can install it somewhere else, e.g. with ./configure -- prefix=/home/myUser/wine-build. Then, set PATH accordingly, so gcc uses the new as binary. 2) Install gcc from svn. The gcc configure scripts check if the assembler supports the swap suffix. This has to be available at compile time, gcc doesn't have runtime checks for that. Early during the compile process you should see a line like checking assembler for swap suffix... yes 3) Compile wine with the new gcc. Again, make sure that the configure script sees the right gcc and as binaries. In the Wine ./configure output you should see a line like: checking for ms_hook_prologue attribute... yes 4) If Xfire still doesn't run(very likely), you can try to make *all* functions hookable, not just the selected ones I patched so far. To do so, edit include/windef.h, and make __attribute__ ((__ms_hook_prologue__)) part of the WINAPI (or even __stdcall) definitions. Then make clean, and recompile. 5) If (4) makes Xfire work, try to figure out which function(s) it tries to hook, and send a patch to add DECLSPEC_HOTPATCH to those functions(look at dlls/kernel32/module.c, LoadLibraryA for an example)
Re: Debugging Xfire: need help
Am 18.10.2009 um 16:24 schrieb Warren Dumortier: I don't think it's worth to be tested, because if Xfire doesn't crash (simply by not interacting with it) games are detected. However i will try it, who knows! ;) An easier way to test is probably to disable Xfire In-Game, if you find out how to do that without using the normal options dialog. Game detection has nothing to do with hooking. Game detection just reads your registry keys, files on disk etc for known games. The hooking comes into action once you start a game. Xfire injects its DLL, hooks some calls, and then displays a message telling that Xfire- In-Game is enabled. That allows you to use Xfire features like the chat, screenshots and movie recording from inside the game, even if the game is running in fullscreen mode, and without tabbing out of the game. The Steam in-game overlay works in the same way. However, Steam only injects its DLL into games started by Steam, while Xfire injects its DLL into every running app, even if it was already running when Xfire was started.
Re: Debugging tools
Alexandros Dermenakis schrieb: Hi, I would like some help about which tools to use for editing code, searching through the source files etc. also, is there a way to import all the source code in Kdevelop? thanks I mostly edit the files with Geany(geany.org), but thats a matter of taste. Also i use source.winehq.org to find functions and defines. I just would try to use Kdevelop, but i dont know if it will work. -- Best Regards, André Hentschel
Re: Debugging tools
I just would try to use Kdevelop, but i dont know if it will work. Actually KDevelop works. I created a new empty project and Imported the whole git repository and I chose to use wine's custom MakeFile and configure files. I'm not able though to start the debug properly but I'm working on it. thanks for the help guys ;-)
Re: Debugging tools
On Sun, Aug 9, 2009 at 10:50 PM, Alexandros Dermenakisalder...@gmail.com wrote: Hi, I would like some help about which tools to use for editing code, searching through the source files etc. also, is there a way to import all the source code in Kdevelop? To get the source: http://wiki.winehq.org/GitWine for a ton more stuff: http://wiki.winehq.org/Developers -- -Austin
Re: Debugging Wine thoughts
On Wednesday 10 September 2008 10:44:09 pm Damjan Jovanovic wrote:
For example applications don't expect to see pointers into the upper
1-2 GB of the 4 GB virtual memory address space because on Windows the
kernel's memory is mapped there. But, ld-linux.so.2 could load
libraries there, including libraries hosting Wine's DLLs, and pointers
to memory in those would leak into the Windows code.
AFAIK, Wine doesn't load .dll.so files using the standard dl lib functions. At
least, the dlopen/dlsym functions don't recognize the .dll.so files in a
winelib app. What it does, again AFAIK, is mmap the lower 2-3GB range so it
can put kernel32/etc where some apps expect it to be, and to mimick Windows'
allocation algorithms.
However, because it's all premapped, further libc malloc calls can't use that
same range, and will quickly run out of allocatable memory. This causes
problems particularly with video cards that have 512MB VRAM or more, since
there's not enough room to map and/or mirror the card resources.
An idea I had and mentioned on IRC a couple times is to have libwine expose
functions that can be used by drivers and other native modules to
allocate win32 memory instead of using the standard libc functions. It
would be pretty easy for a driver or such to do:
void *hdl = dlopen(libwine.so, RTLD_NOLOAD);
void *(*mallocfunc)(size_t) = (hdl ? dlsym(hdl, wine_malloc) : NULL);
void (*freefunc)(void*) = (hdl ? dlsym(hdl, wine_free) : NULL);
if(!mallocfunc || !freefunc || dlerror() != NULL)
{
mallocfunc = malloc;
freefunc = free;
}
..use mallocfunc/freefunc for memory..
This will, of course, rely on drivers to be aware of Wine and handle it.
An alternative idea Alexandre had was to override libc's mmap, so anything
loaded in the process would automatically use the new function (and thus not
need any Wine-specific code). However, my attempts at doing that caused glibc
to crash on init.
Re: Debugging Wine thoughts
Am 10.09.2008 um 17:32 schrieb Stefan Dösinger: You can attach any debugger to a Win32 process running in Wine. This includes Linux debuggers like gdb, [...] As I didn't find hints on how to do this I tried myself: ** First, start gdb in the C: directory [EMAIL PROTECTED]:/otherubuntu/home/mah/.wine/drive_c$ gdb GNU gdb 6.8-debian Copyright [...] This GDB was configured as x86_64-linux-gnu. (gdb) file wine Reading symbols from /usr/local/bin/wine...done. (gdb) directory /otherubuntu/home/mah/wine/ Source directories searched: /otherubuntu/home/mah/wine:$cdir:$cwd (gdb) ** Then, run the app (gdb) run windows/notepad.exe Starting program: /usr/local/bin/wine windows/notepad.exe [Thread debugging using libthread_db enabled] [New Thread 0xf7c628c0 (LWP 793)] [New Thread 0xf7c61b90 (LWP 796)] [Thread 0xf7c61b90 (LWP 796) exited] [New process 793] Executing new program: /usr/local/bin/wine-preloader warning: Cannot initialize thread debugging library: generic error warning: Cannot initialize thread debugging library: generic error [New process 793] Fontconfig warning: /etc/fonts/conf.d/53-monospace-lcd-filter.conf, line 17: invalid constant used : lcdlegacy Fontconfig warning: /etc/fonts/conf.d/53-monospace-lcd-filter.conf, line 17: invalid constant used : lcdlegacy Fontconfig warning: /etc/fonts/conf.d/53-monospace-lcd-filter.conf, line 17: invalid constant used : lcdlegacy ** Notepad should be running here. Interrupt it from the command line to have a look: ^C Program received signal SIGINT, Interrupt. 0xf7fec430 in ?? () (gdb) bt #0 0xf7fec430 in ?? () #1 0x0008 in ?? () #2 0x7bc76516 in ?? () #3 [...] (gdb) list 1 /* 2* Preloader for ld.so 3* 4* Copyright (C) [...] As you see, listing appears to work in principle, while symbol lookup doesn't. It's no secret Wine runs multiple processes and Windows applications run multiple threads, so you might want to look up how to handle this in gdb: http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html My tries to break not into the preloader, but the actual Windows application weren't successful so far, gdb's console appears to lock up somehow when setting follow-fork-mode friends. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
RE: Debugging Wine thoughts
You can attach any debugger to a Win32 process running in Wine. This includes Linux debuggers like gdb, or any graphical frontends, as well as Windows debuggers like visual studio. If you built wine from source, the Linux debuggers will see the Wine source. Probably they can also read the Windows apps source if you have it. I'm not sure if Windows debuggers can access the Wine source, but maybe dbghelp.dll can do that From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, September 10, 2008 10:17 AM To: [EMAIL PROTECTED] Cc: wine-devel@winehq.org Subject: Debugging Wine thoughts Dan / All, I think what the guy was asking on improving winedbg is to have some sort of visual debugger much like VC/C++ , Eclipse, Borland C++ or the like... Where you can step through the code (seeing the whole thing like any visual debugger). Then when looking at stacks you click on a variable or stack and it either winds it back or display's it. Below is my thoughts on what would be a nice to have in some form of Debugger / Gui Debugger for Wine So my wish list would be: 1) Some form of a Standard Gui Debugger 2) A way to select the debug flags used with an explanation of what each is for... +sed is for this +relay does that...etc 3) When you do +relay you could open separate output windows for each thread 4) The ability to turn each of the +relay wine thread output on or off... 4) Currently Wading through a relay log is a real pain and in some cases it prevents the problem from occuring. Time outs because of too much data being collected and then having to wade through and determine what to and not to turn off. So a note or best practice somewhere showing the heavy hitters in a +relay log and turn them off by default. However, note somewhere saying if +relay doesnt give enough information then turn on just these flags and run. That way we are not managing flag lists when trying to figure out whats going wrong in an application. IMHO +relay is too unweldly and turning each flag on individually is as well, so there needs to be some sort of happy medium somewhere. 5) A window with a list of the important wine structures or resources that can be watched as the application runs. 6) Source code debugging in the GUI with step through, break points, etc..( not like now in winedbg but more like one of the GUI's mentioned before) 7) Loading of application from gui debugger and run it 8) Ability to look at a stack and backtrace in the GUI 9) Value Watches within the GUI. 10) Code Checking Some sort of bounds checking... Uninitialized variable checking Unreachable Code Checking 11) Use the GUI to help enforce the Wine Coding standard.. most modern GUI environments let you specify a style of coding. This would help the new people understand and follow the coding standards set up... instead of guessing like they do now. 12) Online help / Context help... point to the IC in the wiki... lots of good stuff there... just hard to find sometimes 13) Integration with bugzilla... they find a bug... they create it in the GUI.. dump out the screen, stack and the like... so some of the base information is collected instead of wasting time back and forth and having so many invalid bugs. Again this format can be enforced through coding style templates... you want to submit a bug here is what you do... check boxes to include things... like I said screen shots... logs, traces, variables, hardware config, etc... 14) Integration with GIT... check and see if there is a new tree out there.. if so... flag it and git it... 15) Link to whats fixed in the new GIT tree... or a list of it... 16) Link to Dan's patchwatcher status... (kinda a workflow sort of thing) to know whats good and bad... 17) Generation of the GIT patch and then mail it to the list through a button... 18) GIT integration You have to remember guy's alot of the new people coming in are not old timers like some of us who grew up in a non-gui world.. Like it or not they are used to doing things in certain ways and I think we could get alot more people looking at bugs and helping fix them if we started thinking of something along these lines. This of course is not a complete list... And I am sure this is going to start a flame war or something close to it.. But I think this might be a good next step for something like the summer of code people to do.. or whomever maintains the wine debugger to think seriously about. Most of these things I think could be implemented using the current wine debugger with some form of pipe between it and the GUI. That way the 'purists' can still debug using winedebug like now and the new people who choose to can use the GUI? Thoughts Problems I have noticed when debugging... If I kill (press the X button or close it from the task bar) the wine application, Wine does not clean up from itself... it leaves
Re: Debugging Wine thoughts
Is there any documentation on the wine site how to set this up stefan??? It may be a start to what I am thinking. chris -Original Message- From: Stefan Dösinger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: wine-devel@winehq.org Sent: Wed, 10 Sep 2008 11:32 am Subject: RE: Debugging Wine thoughts You can attach any debugger to a Win32 process running in Wine. This includes Linux debuggers like gdb, or any graphical frontends, as well as Windows debuggers like visual studio. If you built wine from source, the Linux debuggers will see the Wine source. Probably they can also read the Windows apps source if you have it. I'm not sure if Windows debuggers can access the Wine source, but maybe dbghelp.dll can do that From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, September 10, 2008 10:17 AM To: [EMAIL PROTECTED] Cc: wine-devel@winehq.org Subject: Debugging Wine thoughts Dan / All, I think what the guy was asking on improving winedbg is to have some sort of visual debugger much like VC/C++ , Eclipse, Borland C++ or the like... Where you can step through the code (seeing the whole thing like any visual debugger). Then when looking at stacks you click on a variable or stack and it either winds it back or display's it. Below is my thoughts on what would be a nice to have in some form of Debugger / Gui Debugger for Wine So my wish list would be: 1) Some form of a Standard Gui Debugger 2) A way to select the debug flags used with an explanation of what each is for... +sed is for this +relay does that...etc 3) When you do +relay you could open separate output windows for each thread 4) The ability to turn each of the +relay wine thread output on or off... 4) Currently Wading through a relay log is a real pain and in some cases it prevents the problem from occuring. Time outs because of too much data being collected and then having to wade through and determine what to and not to turn off. So a note or best practice somewhere showing the heavy hitters in a +relay log and turn them off by default. However, note somewhere saying if +relay doesnt give enough information then turn on just these flags and run. That way we are not managing flag lists when trying to figure out whats going wrong in an application. IMHO +relay is too unweldly and turning each flag on individually is as well, so there needs to be some sort of happy medium somewhere. 5) A window with a list of the important wine structures or resources that can be watched as the application runs. 6) Source code debugging in the GUI with step through, break points, etc..( not like no w in winedbg but more like one of the GUI's mentioned before) 7) Loading of application from gui debugger and run it 8) Ability to look at a stack and backtrace in the GUI 9) Value Watches within the GUI. 10) Code Checking Some sort of bounds checking... Uninitialized variable checking Unreachable Code Checking 11) Use the GUI to help enforce the Wine Coding standard.. most modern GUI environments let you specify a style of coding. This would help the new people understand and follow the coding standards set up... instead of guessing like they do now. 12) Online help / Context help... point to the IC in the wiki... lots of good stuff there... just hard to find sometimes 13) Integration with bugzilla... they find a bug... they create it in the GUI.. dump out the screen, stack and the like... so some of the base information is collected instead of wasting time back and forth and having so many invalid bugs. Again this format can be enforced through coding style templates... you want to submit a bug here is what you do... check boxes to include things... like I said screen shots... logs, traces, variables, hardware config, etc... 14) Integration with GIT... check and see if there is a new tree out there.. if so... flag it and git it... 15) Link to whats fixed in the new GIT tree... or a list of it... 16) Link to Dan's patchwatcher status... (kinda a workflow sort of thing) to know whats good and bad... 17) Generation of the GIT patch and then mail it to the list through a button... 18) GIT integration You have to remember guy's alot of the new people coming in are not old timers like some of us who grew up in a non-gui world.. Like it or not they are used to doing things in certain ways and I think we could get alot more people looking at bugs and helping fix them if we started thinking of something along these lines. This of course is not a complete list... And I am sure this is going to start a flame war or something close to it.. But I think this might be a good next step for something like the summer of code people to do.. or whomever maintains the wine debugger to think seriously about. Most of these things I think could
Re: Debugging Wine thoughts
dbghelp supports both linux debug formats (stabs, dwarf) as well as microsoft's one so any debugger using dbghelp as it's debug info provide should debug with all bells whistles native builtin applications I had some success with windbg (with a an 'e' between n d ;-) unfortunately, http://www.winehq.org/site/docs/winedev-guide/dbg-others isn't fully uptodate A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Debugging Wine thoughts
On Wed, Sep 10, 2008 at 8:17 PM, [EMAIL PROTECTED] wrote: Question : Why does wine have to allocate all its memory at startup? re... the issue that is causing the ATI drivers to have such a fuss why not just allocate as needed? or have the ability (if its not there already) to specify the total amount of memory which is available to the wine process and limit wine to just that ammount of memory (kind of like the way most VM machines have the option of setting the maximum amount of memory which is available). Windows applications assume a certain memory layout, which sometimes conflicts with what *nix does. For example applications don't expect to see pointers into the upper 1-2 GB of the 4 GB virtual memory address space because on Windows the kernel's memory is mapped there. But, ld-linux.so.2 could load libraries there, including libraries hosting Wine's DLLs, and pointers to memory in those would leak into the Windows code. So Wine prevents the special areas of Windows memory from being used by *nix libraries and functions like malloc() by mmap()ing that memory in advance. In my opinion, it would be better if we used a custom dynamic linker (ie. an ld-wine.so) that could control where all libraries get loaded so we wouldn't have to steal memory in advance and go through one of the most elaborate startup processes in existence, where an assembly _start routine in wine-preloader loads before ld-linux.so.2 and then pretends to be the kernel. Bye Damjan Jovanovic
Re: Debugging applications running on wine
On Sep 8, 2008, at 9:36 PM, Dan Kegel wrote: Kevin K wrote: Is winedbg the only method of debugging applications being developed for Windows on Wine? For instance, assume a program developed with Visual Studio in C or C++, and I needed to debug it on Linux? If winedbg doesn't work for you, we should fix it. Same goes for other debuggers. For instance, ollydbg seems to work http://appdb.winehq.org/objectManager.php?sClass=applicationiId=2619 Visual C++ 6's debugger seems to work at least a little, too: http://appdb.winehq.org/objectManager.php?sClass=versioniId=31 Please file bugs for any problems you run into. - Dan Thanks. This is just hypothetical right now about some future development that may have to support Linux, XP/Vista, and Windows Mobile.
re: Debugging applications running on wine
Kevin K wrote: Is winedbg the only method of debugging applications being developed for Windows on Wine? For instance, assume a program developed with Visual Studio in C or C++, and I needed to debug it on Linux? If winedbg doesn't work for you, we should fix it. Same goes for other debuggers. For instance, ollydbg seems to work http://appdb.winehq.org/objectManager.php?sClass=applicationiId=2619 Visual C++ 6's debugger seems to work at least a little, too: http://appdb.winehq.org/objectManager.php?sClass=versioniId=31 Please file bugs for any problems you run into. - Dan
Re: debugging applications Re: Networking problems with IDU Verwaltung software
You change the registry with: regedit (wine provide an own implementation) Patches are welcome. The source of the website is managed with git: http://source.winehq.org/git/website.git (templates/en/*) No time for doing that. However, here's a patch which improves the wording a bit I hope. Werner == --- developer-cheatsheet.htm~ 2008-08-09 15:51:58.0 +0200 +++ developer-cheatsheet.htm2008-08-09 15:53:16.0 +0200 @@ -684,8 +684,10 @@ calls between Wine DLLs: for instance, from GDI32 to KERNEL32. Investigate the RelayInclude and RelayExclude string values in [HKCU\Software\Wine\Debug] if you're being -overwhelmed by certain functions. A good initial value for -RelayExclude is:p +overwhelmed by certain functions. (lsquo;HKCUrsquo; stands +for the lsquo;HKEY_CURRENT_USERrsquo; tree in the Windows +registry; you can edit it with the command lsquo;wine +regeditrsquo;.) A good initial value for RelayExclude is:p code RtlEnterCriticalSection;RtlLeaveCriticalSection;_EnterSysLevel;_LeaveSysLevel; _CheckNotSysLevel;RtlAllocateHeap;RtlFreeHeap;LOCAL_Lock;LOCAL_Unlock
Re: debugging applications Re: Networking problems with IDU Verwaltung software
On Fr, 2008-08-08 at 16:51 +0200, Werner LEMBERG wrote: Investigate the RelayInclude and RelayExclude string values in [HKCU\Software\Wine\Debug] if you're being overwhelmed by certain functions. [...] I suppose this is a registry entry, right? Yes. HKCU (or HCU) is: HKEY_CURRENT_USER Perhaps one or two sentences can be added to mention this, together with an explanation which program should be used to change those settings. You change the registry with: regedit (wine provide an own implementation) Patches are welcome. The source of the website is managed with git: http://source.winehq.org/git/website.git (templates/en/*) Thanks for helping Wine -- By by ... Detlef
Re: debugging applications Re: Networking problems with IDU Verwaltung software
Glad to hear that you have sorted out the problem with a new version of the application. I think the general rule is that if wine doesn't provide some component (such as mfc and vc++ 80), using winetricks to install the additional components is preferred over installing application's bundled additional installers. OK. As mentioned before, I explicitly looked into Winetricks, and for that particular VC++ runtime library version it does an ordinary install and nothing else. As for debugging problems with applications, the most useful and concise advice I have read is actual this - I looked for it earlier but couldn't find it because the web page has a strange name :-): http://www.winehq.org/site/developer-cheatsheet Aah. Indeed, this helps. A minor things: I can read Investigate the RelayInclude and RelayExclude string values in [HKCU\Software\Wine\Debug] if you're being overwhelmed by certain functions. [...] I suppose this is a registry entry, right? (I normally don't use Windows, so I'm not too acquainted with that.) Perhaps one or two sentences can be added to mention this, together with an explanation which program should be used to change those settings. Werner
Re: Debugging Question
On Wed, Jul 2, 2008 at 10:29 PM, Chris Ahrendt [EMAIL PROTECTED] wrote: Is there a way within wine or wine debug to tell it to output just the API's which are being called? I am trying to debug a exception that causes an application to crash. As usual I don't have the windows source code in order to debug it that way. So I was hoping there is a way within wine to tell what API's are being called. Sincerely Chris WINEDEBUG=+relay
Re: Debugging Question
Austin English wrote: On Wed, Jul 2, 2008 at 10:29 PM, Chris Ahrendt [EMAIL PROTECTED] wrote: Is there a way within wine or wine debug to tell it to output just the API's which are being called? I am trying to debug a exception that causes an application to crash. As usual I don't have the windows source code in order to debug it that way. So I was hoping there is a way within wine to tell what API's are being called. Sincerely Chris WINEDEBUG=+relay Not looking for the calls within wine... thanks for all the pointers guys.. esp the one to all the flags.. What I am looking for exactly is a way to just get wine to dump the Win32 API calls that are made... I am trying to figure out what an application calls right before it gets an exception from the result sent back from wine. If I knew the API its calling I could write a test case and find the issue. So is there any way to output just the win32 API calls and no wine information. Chris
Re: Debugging Question
So is there any way to output just the win32 API calls and no wine information. That's precisely what +relay does. I'm not sure what you mean by no wine information. --Juan
Re: Debugging Question
Juan Lang wrote: So is there any way to output just the win32 API calls and no wine information. That's precisely what +relay does. I'm not sure what you mean by no wine information. --Juan Ok when I put +relay on I get alot of other stuff I am not looking for... So what I am looking for is application A called Win32 api say an open window or other such thing... I cant remember the exact api's (G) its been a long week at work.. So it would be like this trace:d3d_caps:win32 API called returning w:1600, h:1200, ref:60, fmt:WINED3DFMT_X8R8G8B8 or something along those lines... if relay does that does it also put in the wine calls as well? if it does is there any way to filter those out... I just want the high level API calls nothing more... chris Sorry if this is rambling... like I said its been a LONG Week
Re: Debugging Question
Ok when I put +relay on I get alot of other stuff I am not looking for... Sure. Some Windows APIs call other Windows APIs. +relay almost always produces too much information, but guessing which debug channel you really want is hard. Sometimes you have to read the relay channel to guess which channel you really want. So it would be like this trace:d3d_caps:win32 API called returning w:1600, h:1200, ref:60, fmt:WINED3DFMT_X8R8G8B8 No, that'll only appear if you turn on trace for the d3d_caps channel. +relay only turns it on for the relay channel. --Juan
Re: Debugging Question
Juan Lang wrote: Ok when I put +relay on I get alot of other stuff I am not looking for... Sure. Some Windows APIs call other Windows APIs. +relay almost always produces too much information, but guessing which debug channel you really want is hard. Sometimes you have to read the relay channel to guess which channel you really want. So it would be like this trace:d3d_caps:win32 API called returning w:1600, h:1200, ref:60, fmt:WINED3DFMT_X8R8G8B8 No, that'll only appear if you turn on trace for the d3d_caps channel. +relay only turns it on for the relay channel. --Juan ok so its wade through relay time I guess... =) and then take a wild guess... sigh... chris
Re: Debugging Question
On Wed, Jul 2, 2008 at 10:29 PM, Chris Ahrendt [EMAIL PROTECTED] wrote: Is there a way within wine or wine debug to tell it to output just the API's which are being called? I am trying to debug a exception that causes an application to crash. As usual I don't have the windows source code in order to debug it that way. So I was hoping there is a way within wine to tell what API's are being called. http://wiki.winehq.org/DebugChannels Highly recommended to guess which channels you need as opposed to turning them all on. The logs balloon quickly. --John Klehm
Re: debugging help
On 6/18/07, Damjan Jovanovic [EMAIL PROTECTED] wrote: only appear in +snoop, not in +relay. And is there a way for a builtin DLL to LoadLibrary() the native DLL of the same name and call functions in it? It would be very useful in narrowing down the bug. You can definitely use LoadLibrary() / GetProcAddress() inside of a builtin DLL manually to compare results against the native function. You'll have to change the name of the native DLL to avoid loading the builtin one by accident. Of course, none of that type of debugging code should be in the main git tree. Take a look at the tests/ folders for good examples of how to dynamically load the DLLs and functions.
Re: Debugging Supreme Commander Installer
On 3/19/07, Stephan Rose [EMAIL PROTECTED] wrote: On Mon, 2007-03-19 at 09:40 +0100, Stefan Dösinger wrote: Am Montag 19 März 2007 01:49 schrieb Stephan Rose: I've been playing around with the supreme commander install most of today trying to figure out why it does not want to install. Running with +file,+msgbox and noticed the following error for virtually all files: So it seems that it freaks out because somehow the file appears in the directory tree late. Sounds like a race :-) . I don't know anything about wine's msi and dcom implementation(which installshield uses heavilly). DCOM is about the most complex thing in Windows :-/ One think you can try if that game works with windows 98 too is to use native msi 2.0 and / or native dcom98 . If that fails in the same way it is a bug somewhere else(ntdll / kernel), otherwise most likely msi or dcom. Dan's Winetricks may help with installing that. You need winver = win98 for native msi and dcom. No luck there...but I am one step closer to tracking down the source of the problem. I found that kernel32 is calling RaiseException when the file that is failing comes up. So I went to check it out with +seh, this is the exception that comes up: trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7ee4ca80 trace:seh:raise_exception info[0]=19930520 trace:seh:raise_exception info[1]=00334aec trace:seh:raise_exception info[2]=100f7058 trace:seh:raise_exception eax=7ee37d89 ebx=7eeb8880 ecx= edx=100f18d8 esi=100f18d8 edi=00334ad0 trace:seh:raise_exception ebp=00334a90 esp=00334a2c cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00200216 Anyone have any idea on what the exception is? I've come as far so far as that it seems to be some MS Specific C++ exception. I've still got to find out what function this exception is originating in. Going to try and figure that one out next. I could be way off the mark on this one but I think I remember hearing somewhere that ebx=7eeb8880 was copy protection (SD2?). Like I said maybe way off the mark, but we will see. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373from=power-email
Re: Debugging Supreme Commander Installer
Stephan Rose wrote: I've been playing around with the supreme commander install most of today trying to figure out why it does not want to install. Running with +file,+msgbox and noticed the following error for virtually all files: warn:file:wine_nt_to_unix_file_name LTUB500.xsb not found in /home/stephan/.wine/dosdevices/c:/Program Files/THQ/Gas Powered Games/Supreme Commander/sounds/Voice/fr/Tutorials This is the file being copied when I get the Error 87 message from Install shield. Also, pretty much every file, if not every file, gives the same trace in the debug log. It's weird that install shield will copy hundreds of files with that warning in their trace and not complain until it is 80% through. So then I wondered, is that really the cause or not? I think yes. Install shield appears to be kind enough to not re-copy the files if they already exist, so I killed the process to keep all files already copied and added the one missing file above from my windows install and then ran install shield again. This time around, the file was processed correctly and no error. Instead it gives the error now on the next file, which is TUB500.xwb. Some more trace below: trace:file:GetFileAttributesW Lc:\\Program Files\\THQ\\Gas Powered Games\\Supreme Commander\\sounds\\Voice\\fr\\Tutorials\\TUB500.xwb trace:file:RtlDosPathNameToNtPathName_U (Lc:\\Program Files\\THQ\\Gas Powered Games\\Supreme Commander\\sounds\\Voice\\fr\\Tutorials\ \TUB500.xwb,0x334b84,(nil),(nil)) trace:file:RtlGetFullPathName_U (Lc:\\Program Files\\THQ\\Gas Powered Games\\Supreme Commander\\sounds\\Voice\\fr\\Tutorials\\TUB500.xwb 520 0x3348f8 (nil)) warn:file:wine_nt_to_unix_file_name LTUB500.xwb not found in /home/stephan/.wine/dosdevices/c:/Program Files/THQ/Gas Powered Games/Supreme Commander/sounds/Voice/fr/Tutorials These messages are normal. GetFileAttributes is often used by programs to check for the existence of a file. trace:file:MoveFileWithProgressW (L,(null),(nil),(nil),0004) trace:file:RtlDosPathNameToNtPathName_U (L,0x3348b8,(nil),(nil)) This is not. Moving a file with a blank name isn't going to work properly. Probably a test case is needed to see what happens on Windows. However, my guess is that there is a bug elsewhere that causes the installer to not get the correct filename. -- Rob Shearman
Re: Debugging Supreme Commander Installer
On Mon, 2007-03-19 at 09:40 +0100, Stefan Dösinger wrote: Am Montag 19 März 2007 01:49 schrieb Stephan Rose: I've been playing around with the supreme commander install most of today trying to figure out why it does not want to install. Running with +file,+msgbox and noticed the following error for virtually all files: So it seems that it freaks out because somehow the file appears in the directory tree late. Sounds like a race :-) . I don't know anything about wine's msi and dcom implementation(which installshield uses heavilly). DCOM is about the most complex thing in Windows :-/ One think you can try if that game works with windows 98 too is to use native msi 2.0 and / or native dcom98 . If that fails in the same way it is a bug somewhere else(ntdll / kernel), otherwise most likely msi or dcom. Dan's Winetricks may help with installing that. You need winver = win98 for native msi and dcom. No luck there...but I am one step closer to tracking down the source of the problem. I found that kernel32 is calling RaiseException when the file that is failing comes up. So I went to check it out with +seh, this is the exception that comes up: trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7ee4ca80 trace:seh:raise_exception info[0]=19930520 trace:seh:raise_exception info[1]=00334aec trace:seh:raise_exception info[2]=100f7058 trace:seh:raise_exception eax=7ee37d89 ebx=7eeb8880 ecx= edx=100f18d8 esi=100f18d8 edi=00334ad0 trace:seh:raise_exception ebp=00334a90 esp=00334a2c cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00200216 Anyone have any idea on what the exception is? I've come as far so far as that it seems to be some MS Specific C++ exception. I've still got to find out what function this exception is originating in. Going to try and figure that one out next. Stephan
Re: Debugging Supreme Commander Installer
Am Montag 19 März 2007 01:49 schrieb Stephan Rose: I've been playing around with the supreme commander install most of today trying to figure out why it does not want to install. Running with +file,+msgbox and noticed the following error for virtually all files: So it seems that it freaks out because somehow the file appears in the directory tree late. Sounds like a race :-) . I don't know anything about wine's msi and dcom implementation(which installshield uses heavilly). DCOM is about the most complex thing in Windows :-/ One think you can try if that game works with windows 98 too is to use native msi 2.0 and / or native dcom98 . If that fails in the same way it is a bug somewhere else(ntdll / kernel), otherwise most likely msi or dcom. Dan's Winetricks may help with installing that. You need winver = win98 for native msi and dcom. pgp1f9uTV08Pl.pgp Description: PGP signature
Re: Debugging solidworks 2006
After doing the suggested tactis it still failed but with fewer errors:
Here is the output
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
err:wgl:ConvertPixelFormatWGLtoGLX Can't find a matching FBCONFIG_ID for
VISUAL_ID 0x24!
err:wgl:X11DRV_ChoosePixelFormat Can't find a matching FBCONFIG_ID for
VISUAL_ID 0x24!
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:shdocvw:PersistStreamInit_InitNew (0x335d488)
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
fixme:shdocvw:navigate_url Unsupported arguments
fixme:ole:CoCreateInstance no instance created for interface
{08c0e040-62d1-11d1-9326-0060b067b86e} of class
{4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80004002
fixme:shdocvw:ClOleCommandTarget_QueryStatus (0x335d524)-((null) 1
0x33e520 (nil))
fixme:shdocvw:ClOleCommandTarget_Exec (0x335d524)-((null) 25 2 0x33e534
(nil))
fixme:shdocvw:ClOleCommandTarget_Exec (0x335d524)-((null) 26 2 0x33e534
(nil))
fixme:shdocvw:ClDispatch_Invoke (0x335d524)-(-709
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)-(-5512
{----} 2048 0002 0x33e448 0x33e494 (nil)
0x33e458)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)-(-5501
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)-(-5512
{----} 2048 0002 0x33e448 0x33e494 (nil)
0x33e458)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)-(-5502
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)-(-5513
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)-(-726
Re: Debugging solidworks 2006
First thing to do is to open bug at bugs.winehq.org and describe your
problem there.
Then, please try to:
1) copy msimtf.dll from Windows to your wine's system32, register it
with regsvr32 and try if Solid Works issue persists
2) copy atl.dll from Windows to your wine's system32, register it and
try again with WINEDLLOVERRIDES=atl=n
3) install MS IE6 and try again
Also, maybe +relay debug log will spot a root cause.
Kartik Thakore wrote, on 11/15/06 04:50 MSK:
I am currently trying Solid Works 2006 to work with wine-0.9.25. It
installed with some error, but it finished. The trouble is when it is
run. What is my next step? As this is the first time I am doing
debugging in wine and I have little experience with windows programming.
I am doing this so I can get solidworks working as I really need it. Any
help will be very much appreciated.
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
err:wgl:ConvertPixelFormatWGLtoGLX Can't find a matching FBCONFIG_ID for
VISUAL_ID 0x24!
err:wgl:X11DRV_ChoosePixelFormat Can't find a matching FBCONFIG_ID for
VISUAL_ID 0x24!
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:shdocvw:PersistStreamInit_InitNew (0x335d3f0)
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
fixme:shdocvw:navigate_url Unsupported arguments
err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} not
registered
err:ole:CoGetClassObject no class object {4955dd33-b159-11d0-8fcf-00aa006bcc59}
could be created for context 0x1
fixme:shdocvw:ClOleCommandTarget_QueryStatus (0x335d48c)-((null) 1 0x33e520
(nil))
fixme:shdocvw:ClOleCommandTarget_Exec (0x335d48c)-((null) 25 2 0x33e534 (nil))
fixme:shdocvw:ClOleCommandTarget_Exec (0x335d48c)-((null) 26 2 0x33e534 (nil))
fixme:shdocvw:ClDispatch_Invoke (0x335d48c)-(-709
{----} 2048 0002 0x33e488 0x33e4d4 (nil) 0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d48c)-(-5512
{----} 2048 0002 0x33e448 0x33e494 (nil) 0x33e458)
fixme:shdocvw:ClDispatch_Invoke (0x335d48c)-(-5501
{----} 2048 0002 0x33e488
Re: Debugging solidworks 2006
After doing the suggested tactis it still failed but with fewer errors:
Here is the output
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
err:wgl:ConvertPixelFormatWGLtoGLX Can't find a matching FBCONFIG_ID for
VISUAL_ID 0x24!
err:wgl:X11DRV_ChoosePixelFormat Can't find a matching FBCONFIG_ID for
VISUAL_ID 0x24!
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:shdocvw:PersistStreamInit_InitNew (0x335d488)
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
fixme:shdocvw:navigate_url Unsupported arguments
fixme:ole:CoCreateInstance no instance created for interface
{08c0e040-62d1-11d1-9326-0060b067b86e} of class
{4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80004002
fixme:shdocvw:ClOleCommandTarget_QueryStatus (0x335d524)-((null) 1
0x33e520 (nil))
fixme:shdocvw:ClOleCommandTarget_Exec (0x335d524)-((null) 25 2 0x33e534
(nil))
fixme:shdocvw:ClOleCommandTarget_Exec (0x335d524)-((null) 26 2 0x33e534
(nil))
fixme:shdocvw:ClDispatch_Invoke (0x335d524)-(-709
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)-(-5512
{----} 2048 0002 0x33e448 0x33e494 (nil)
0x33e458)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)-(-5501
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)-(-5512
{----} 2048 0002 0x33e448 0x33e494 (nil)
0x33e458)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)-(-5502
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)-(-5513
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)-(-726
Re: Debugging solidworks 2006
On 11/15/06, Kartik Thakore [EMAIL PROTECTED] wrote: After doing the suggested tactis it still failed but with fewer errors: Did you already setup a bug number for this? what number? It would be best to attach log outputs to the bug report. Doesn't Solidworks use the (Macromedia) Safecast copy protection ? In that case you are probably out of luck. I tried getting Autocad 2004, and got it to install with some Wine tweaking. There were some patches for wine that make it support some older Safecast versions (ntoskrnl), but I couldn't get it to work with the newer Safcast versions. Safecast is particularly difficult to debug because it is intended to be as complicated as possible to prevent reverse engineering. (The shear size of it is the only thing preventing it from reverse engineering). Also Safecast is designed to hide detected problems for a long time, and only bail out much later, or even not at, just limiting the software in some way, like not being able to run the last level of a game. Jaap.
Re: Debugging _CheckNotSysLevel() errors?
Dan Kegel [EMAIL PROTECTED] wrote: http://bugs.winehq.org/show_bug.cgi?id=4063 is a crash on exit from a VB6 app due to a _CheckNotSysLevel() error. What typically causes these - are they a bug in the windows program? And is there a good reference from understanding the whole syslevel thing in gdi? Does it help if you undefine STRETCH_VIA_DIB before MFDRV_StretchBlt in dlls/gdi/mfdrv/bitblt.c ? -- Dmitry.
Re: Debugging _CheckNotSysLevel() errors?
On Fri, 07 Jul 2006 00:24:49 -0700, Dan Kegel wrote: http://bugs.winehq.org/show_bug.cgi?id=4063 is a crash on exit from a VB6 app due to a _CheckNotSysLevel() error. What typically causes these - are they a bug in the windows program? And is there a good reference from understanding the whole syslevel thing in gdi? Thanks! The developers guide talks about this, because I once asked exactly the same questions :) Syslevels are an internal mutex that understands ordering constraints, if a syslevel violation occurs it's always a bug in Wine and a backtrace can be useful to see how Wine got into the invalid state. thanks -mike
Re: Debugging _CheckNotSysLevel() errors?
On 7/6/06, Dmitry Timoshkov [EMAIL PROTECTED] wrote: http://bugs.winehq.org/show_bug.cgi?id=4063 is a crash on exit from a VB6 app due to a _CheckNotSysLevel() error. What typically causes these - are they a bug in the windows program? And is there a good reference from understanding the whole syslevel thing in gdi? Does it help if you undefine STRETCH_VIA_DIB before MFDRV_StretchBlt in dlls/gdi/mfdrv/bitblt.c ? Nope.
Re: Debugging string comparison problem
Juan Lang wrote: I'm trying to figure out why CompareStringA returns CSTR_EQUAL for the strings \1 and \2. (See bug 5469, and the todo_wine test case in dlls/kernel/tests/locale.c) CompareStringA does the usual thing, calls MultiByteToWideChar and calls CompareStringW. So CompareStringW is comparing L\0001 to L\0002. CompareStringW calls wine_compare_string, in libs/unicode/sortkey.c That calls compare_unicode_weights. That has this little bit of code: ce1 = collation_table[collation_table[*str1 8] + (*str1 0xff)]; ce2 = collation_table[collation_table[*str2 8] + (*str2 0xff)]; With the strings L\0001 and L\0002, *str1 is 0x0001, and *str2 is 0x0002. So *str1 8 is 0, and *str2 8 is 0. *str1 0xff is 0x01, *str2 0xff is 0x02. So, ce1 == collation_table[1], which is 0x0300 (in collation.c), and ce2 == collation_table[2], which is 0x0400. You missed the two collation_table lookups. The first lookup is to find an index (the table is stored with some trivial compression). This will be 0x200 for both *str1 and *str2. Then the second lookup is done for collation_table[0x201] and collation_table[0x202] and these are both 0 (see the data beginning with line /* 0x .. 0x00ff */ in collation.c). Note that on Windows using CompareString on L\0001\0002 and L\0002\0001 gives a result of CSTR_EQUAL, so I don't think the bug is in the collation tables. -- Rob Shearman
Re: Debugging string comparison problem
- Original Message - From: Juan Lang [EMAIL PROTECTED] To: wine-devel@winehq.org Sent: Wednesday, June 28, 2006 12:20 AM Subject: Debugging string comparison problem I'm trying to figure out why CompareStringA returns CSTR_EQUAL for the strings \1 and \2. (See bug 5469, and the todo_wine test case in dlls/kernel/tests/locale.c) CompareStringA does the usual thing, calls MultiByteToWideChar and calls CompareStringW. So CompareStringW is comparing L\0001 to L\0002. CompareStringW calls wine_compare_string, in libs/unicode/sortkey.c That calls compare_unicode_weights. That has this little bit of code: ce1 = collation_table[collation_table[*str1 8] + (*str1 0xff)]; ce2 = collation_table[collation_table[*str2 8] + (*str2 0xff)]; With the strings L\0001 and L\0002, *str1 is 0x0001, and *str2 is 0x0002. So *str1 8 is 0, and *str2 8 is 0. *str1 0xff is 0x01, *str2 0xff is 0x02. So, ce1 == collation_table[1], which is 0x0300 (in collation.c), and ce2 == collation_table[2], which is 0x0400. That gets us here: if (ce1 != (unsigned int)-1 ce2 != (unsigned int)-1) ret = (ce1 16) - (ce2 16); else ret = *str1 - *str2; Well, 0x0300 16 is 0, and so is 0x0400, so ce1 - ce2 is 0, so these strings are considered equal. But as the test case shows, they're not supposed to be. I'm just not sure what to do about it. Changing collation.c isn't really an option, since it's generated. So there's some flaw in the logic here, but I don't understand the meaning of collation_table. Could someone explain to me what it is? That's really a problem with collation.c, or rather with the it's been generated from www.unicode.org/reports/tr10/allkeys.txt. There are a lot of differences between that file and microsoft's implementation. We have some hacks in Crossover to compensate it, and to do so what I did is just fixed up the allkeys.txt from unicode.org and regenerated collation.c. -- Dmitry.
Re: Debugging X errors?
Hi, On Tue, Mar 28, 2006 at 03:39:43AM -0800, Dan Kegel wrote: OK, I've had it. The X errors I'm running into are keeping me from getting work done. They might be due to bugs in my X server (ubuntu 05.10), but while I wait for the next release of ubuntu, maybe I could try to track them down anyway. Good idea ;) It looks like the procedure for diagnosing X errors such as X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 17 (X_GetAtomName) Atom id in failed request: 0x0 Serial number of failed request: 468 Current serial number in output stream: 470 in Wine is to do WINEDEBUG=+synchronous export WINEDEBUG and then use winedbg to run the apps, and get a backtrace when the error occurs. I'll try that. Random semi-helpful notes I've been writing down about that: -- SOLUTION: gdb: b _XError b wxXErrorHandler How do I trace the cause of an X11 error such as BadMatch? When a fatal X11 error occurs, the application quits with no stack trace. To find out where the problem is, put a breakpoint on g_log (b g_log in gdb). Unexpected async reply is commonly due to a multi-threaded app with Motif/Xlib calls from more than 1 thread; or to Motif/Xlib calls from a signal handler. http://www.rahul.net/kenton/perrors.html try: XSynchronize(display, True); for debugging Maybe can happen if app is overwriting Xlib-owned memory... -- Andreas Mohr
Re: Debugging X errors?
Andreas Mohr wrote: Hi, On Tue, Mar 28, 2006 at 03:39:43AM -0800, Dan Kegel wrote: OK, I've had it. The X errors I'm running into are keeping me from getting work done. They might be due to bugs in my X server (ubuntu 05.10), but while I wait for the next release of ubuntu, maybe I could try to track them down anyway. Good idea ;) It looks like the procedure for diagnosing X errors such as X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 17 (X_GetAtomName) Atom id in failed request: 0x0 Serial number of failed request: 468 Current serial number in output stream: 470 in Wine is to do WINEDEBUG=+synchronous export WINEDEBUG and then use winedbg to run the apps, and get a backtrace when the error occurs. I'll try that. Random semi-helpful notes I've been writing down about that: -- SOLUTION: gdb: b _XError b wxXErrorHandler How do I trace the cause of an X11 error such as BadMatch? When a fatal X11 error occurs, the application quits with no stack trace. To find out where the problem is, put a breakpoint on g_log (b g_log in gdb). Unexpected async reply" is commonly due to a multi-threaded app with Motif/Xlib calls from more than 1 thread; or to Motif/Xlib calls from a signal handler. http://www.rahul.net/kenton/perrors.html try: XSynchronize(display, True); for debugging Maybe can happen if app is overwriting Xlib-owned memory... -- Andreas Mohr Do this as either your user or as root (via sudo): V -version Email us the ful output (drag the mouse over the top line to the next line that is your shell and middle click in yor email client to paste) sorry if i treated you like a idiot, but some people don't realize that X has 2 clipboards per se, one done by X itself, and another handled by QT/GTK+/Wine (Try this: select some text in Wine, and middle click in a Xterm, nothing happens! Go back to the Windows app, tell it to copy the text, and try to paste it into the xterm, nothing again! I think it's a bug IMHO)
Re: Debugging X errors?
Andreas Mohr wrote: Hi, On Tue, Mar 28, 2006 at 03:39:43AM -0800, Dan Kegel wrote: OK, I've had it. The X errors I'm running into are keeping me from getting work done. They might be due to bugs in my X server (ubuntu 05.10), but while I wait for the next release of ubuntu, maybe I could try to track them down anyway. Good idea ;) It looks like the procedure for diagnosing X errors such as X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 17 (X_GetAtomName) Atom id in failed request: 0x0 Serial number of failed request: 468 Current serial number in output stream: 470 in Wine is to do WINEDEBUG=+synchronous export WINEDEBUG and then use winedbg to run the apps, and get a backtrace when the error occurs. I'll try that. Random semi-helpful notes I've been writing down about that: -- SOLUTION: gdb: b _XError b wxXErrorHandler How do I trace the cause of an X11 error such as BadMatch? When a fatal X11 error occurs, the application quits with no stack trace. To find out where the problem is, put a breakpoint on g_log (b g_log in gdb). Unexpected async reply" is commonly due to a multi-threaded app with Motif/Xlib calls from more than 1 thread; or to Motif/Xlib calls from a signal handler. http://www.rahul.net/kenton/perrors.html try: XSynchronize(display, True); for debugging Maybe can happen if app is overwriting Xlib-owned memory... -- Andreas Mohr Do this as either your user or as root (via sudo): X -version Email us the ful output (drag the mouse over the top line to the next line that is your shell and middle click in yor email client to paste) sorry if i treated you like a idiot, but some people don't realize that X has 2 clipboards per se, one done by X itself, and another handled by QT/GTK+/Wine (Try this: select some text in Wine, and middle click in a Xterm, nothing happens! Go back to the Windows app, tell it to copy the text, and try to paste it into the xterm, nothing again! I think it's a bug IMHO)
Re: Debugging X errors?
On Tue, 28 Mar 2006 15:25:26 -0500 Segin [EMAIL PROTECTED] wrote: (Try this: select some text in Wine, and middle click in a Xterm, nothing happens! Go back to the Windows app, tell it to copy the text, and try to paste it into the xterm, nothing again! I think it's a bug IMHO) You need to set the Wine registry entry X11 Driver/UsePrimarySelection to 'Y'. I submitted a patch for Winecfg to do it, but it wasn't accepted and it was a long time ago... -- Ph.
Re: Debugging
Hi, On Friday 24 February 2006 06:28, Juan Lang wrote: As far as how to deal with this, try modifying kernel32.spec to add a stub for BlockInput, like: @ stub BlockInput and see if the program gets any further. Hi according to MSDN, BlockInput is a user32.dll function: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/keyboardinput/keyboardinputreference/keyboardinputfunctions/blockinput.asp In fact, we do have a commented out stub in dlls/user/user32.spec # @ stub BlockInput Bye, -- Michael Jung [EMAIL PROTECTED]
Re: Debugging
Hi, As such, I'm looking for a little advice on debugging issues when apps don't work (yes, I've read what's on winehq.) I have the application KeePass (keepass.sourceforge.net) which installs just fine. When I go to run it, it just drops me right back to the prompt. Pardon my ignorance, but why don't you use the Linux version instead? http://keepass.sourceforge.net/download.php lists a Linux port. If you have the necessary tools to compile keepass, you can build the Win32 version from source and put a few debugging printfs into it, to see where it stops. This could shorten the debug time greatly. (Of course this doesn't work for apps where the source isn't available) pgpbivqpVxm4Q.pgp Description: PGP signature
Re: Debugging
On Friday 24 February 2006 13:46, Stefan Dösinger wrote: Hi, As such, I'm looking for a little advice on debugging issues when apps don't work (yes, I've read what's on winehq.) I have the application KeePass (keepass.sourceforge.net) which installs just fine. When I go to run it, it just drops me right back to the prompt. Pardon my ignorance, but why don't you use the Linux version instead? http://keepass.sourceforge.net/download.php lists a Linux port. If you have the necessary tools to compile keepass, you can build the Win32 version from source and put a few debugging printfs into it, to see where it stops. This could shorten the debug time greatly. (Of course this doesn't work for apps where the source isn't available) No, that's fine. I'm not surprised that somebody knew there was a Linux port. The reason is simple. I'm in the process of trying to put together a presentation for my local LUG on Wine in a couple of months and I'm trying to get to know how to use it better. I also happened to ask a few people what they would like to learn in relation to Wine. One request was how to debug getting a program to work when it doesn't necessarilly run right out of the box, so to say. In addition, one of the guys told me he tried to run this program under Wine and couldn't get it to work. I tried it and was when I couldn't find any noticable reason for the crash. He's familiar with the Linux port, but it's a version behind and can't read the current database he has all of his information in. It's a valid question. I just thought it'd be a good place for me to start in the realm of trying to get things working because I knew that it would be freely and easily available to anyone on this list so that I might get a little bit of direction. That all. -- -- In a world without fences, who needs Gates? pgpbKEDCi7uu3.pgp Description: PGP signature
Re: Debugging
Hi Rich, the key one to use is relay. WINEDEBUG=relay tells you every API function that's called. It can be a bit overwhelming, but it's what you fall back on when nothing else is working. I downloaded and tried it, and scanned backwards in my relay trace a good distance till I saw some failure. Here's what I think it is: 0009:Call kernel32.GetProcAddress(2029,0052b895 BlockInput) ret=0052cc6a 0009:Call ntdll.RtlInitAnsiString(73ccfe20,0052b895 BlockInput) ret=201d2c3e 0009:Ret ntdll.RtlInitAnsiString() retval= ret=201d2c3e 0009:Call ntdll.LdrGetProcedureAddress(2029,73ccfe20,,73ccfe1c) ret=201d2c4d 0009:Ret ntdll.LdrGetProcedureAddress() retval=c07a ret=201d2c4d 0009:Call ntdll.RtlNtStatusToDosError(c07a) ret=201d2c7d 0009:Ret ntdll.RtlNtStatusToDosError() retval=007f ret=201d2c7d 0009:Ret kernel32.GetProcAddress() retval= ret=0052cc6a 0009:Call kernel32.ExitProcess(0052cb10) ret=0052cc7b That is, somebody's trying to get the function BlockInput from kernel32.dll, and it isn't there, so the program exits. I don't know if this is in MFC somewhere, or in the program's source. Luckily the source is available, so you might be able to proceed. Hope that helps, --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Debugging
I appreciate the tip about falling back on the relay debug channel, but may I ask how you know the problem is with BlockInput not existing? Is there something from the output that I'm not understanding, or do you just know that because you're familiar with the kernel32.dll code? I'm a long way from ever becoming a Wine developer, but I do want to learn how to either get my programs working, or to be able to accurately identify bugs. On Thursday 23 February 2006 20:18, Juan Lang wrote: Hi Rich, the key one to use is relay. WINEDEBUG=relay tells you every API function that's called. It can be a bit overwhelming, but it's what you fall back on when nothing else is working. I downloaded and tried it, and scanned backwards in my relay trace a good distance till I saw some failure. Here's what I think it is: 0009:Call kernel32.GetProcAddress(2029,0052b895 BlockInput) ret=0052cc6a 0009:Call ntdll.RtlInitAnsiString(73ccfe20,0052b895 BlockInput) ret=201d2c3e 0009:Ret ntdll.RtlInitAnsiString() retval= ret=201d2c3e 0009:Call ntdll.LdrGetProcedureAddress(2029,73ccfe20,,73ccfe1c) ret=201d2c4d 0009:Ret ntdll.LdrGetProcedureAddress() retval=c07a ret=201d2c4d 0009:Call ntdll.RtlNtStatusToDosError(c07a) ret=201d2c7d 0009:Ret ntdll.RtlNtStatusToDosError() retval=007f ret=201d2c7d 0009:Ret kernel32.GetProcAddress() retval= ret=0052cc6a 0009:Call kernel32.ExitProcess(0052cb10) ret=0052cc7b That is, somebody's trying to get the function BlockInput from kernel32.dll, and it isn't there, so the program exits. I don't know if this is in MFC somewhere, or in the program's source. Luckily the source is available, so you might be able to proceed. Hope that helps, --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- -- In a world without fences, who needs Gates? pgp9m04gGTyIZ.pgp Description: PGP signature
Re: Debugging
Rich Gilson wrote: I appreciate the tip about falling back on the relay debug channel, but may I ask how you know the problem is with BlockInput not existing? Is there something from the output that I'm not understanding, or do you just know that because you're familiar with the kernel32.dll code? I'll give it a shot (I'm a chronic newbie so this might be wrong). 0009:Call kernel32.GetProcAddress(2029,0052b895 BlockInput) There's the call asking for an address for BlockInput. 0009:Ret kernel32.GetProcAddress() retval= ret=0052cc6a 0009:Call kernel32.ExitProcess(0052cb10) ret=0052cc7b There the application exits, right after GetProcAddress returns . Look up GetProcAddress in MSDN: http://www.google.com/search?q=GetProcAddressbtnI It says: If the function fails, the return value is NULL. Which seems to be what we're seeing. It also says: To get extended error information, call GetLastError. Luckily, the source code is LGPL and we know that there are bits and pieces missing of it, so an easier way than calling GetLastError is to just grep the sources for kernel32 and see if BlockInput might be missing (probably not a bad guess)... HTH, hope I'm not way off.
Re: Debugging
I appreciate the tip about falling back on the relay debug channel, but may I ask how you know the problem is with BlockInput not existing? Is there something from the output that I'm not understanding, or do you just know that because you're familiar with the kernel32.dll code? Molle's right--it just looks suspicious, since it's the last thing that's called before ExitProcess. I didn't copy-paste any more of the log, but there were a whole bunch of GetProcAddress calls prior to this that succeeded, which raises the probability that this was the cause. And, as Molle suggested, a quick glance at the kernel32 code shows that BlockInput is missing. As far as how did I spot this in the log--well, that's just experience. You can learn it pretty quickly though, especially when an app dies early. I just scroll through a log from the end toward the beginning, and look for a change in pattern on the screen. Different things are starting to happen there, so I slow down for a closer look. If it looks like normal shutdown code--and there's usually hundreds of lines of this stuff--I ignore it and move on. As far as how to deal with this, try modifying kernel32.spec to add a stub for BlockInput, like: @ stub BlockInput and see if the program gets any further. Chances are it'll crash somewhere else down the line, so you'll have to do the usual wash-rinse-repeat. You should also take a look through KeePass's source code and try to find out what's going on. --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Debugging a null pointer dereference
On Sat, Jan 14, 2006 at 08:41:50PM +0100, Christer Palm wrote: Hi! I'm new to this list, but a long time Wine user and regular WWN reader. The other day I decided to try out Semiolog, a free as-in-beer piece of software to create labels from electric equipment manufacturer Hager, under wine. The software can be downloaded from here: http://www.hager.se/files/download/0/482_1/0/SemiologSue40a.exe Unfortunately it doesn't work. So although I haven't been doing any Windows programming in the last 15 years I decided to try to do something useful and try find out why it doesn't work. I figured that this application would be a good thing to try to get to work as it is supposedly rather trivial. So what follows is a description of a newbies attempt at some wine debugging: The application installs and starts up just fine, but when I try to create a new document, I get a null pointer dereference in mfc42.dll. After messing around with with the mfc42 runtime, I managed to get a backtrace with debugging information, which looks like this: =1 0x5f4056dd CEnumOleVerb::~CEnumOleVerb+0x37 [oleverb.cpp:61] in mfc42 (0x5f4056dd) You should find out what it does before. Capture a WINEDEBUG=+relay,+seh trace (redirect output to a logfile). Then look at this trace, search for the winedbg call and scroll back until the RaiseException with c0005 code (likely only some dozen lines above the initial debugger start). The look backwards from this to see where it might have got this NULL pointer... :/ If its bad, it could have got it from millions of lines ago. :/ Ciao, Marcus
Re: Debugging a null pointer dereference
Marcus Meissner wrote: On Sat, Jan 14, 2006 at 08:41:50PM +0100, Christer Palm wrote: After messing around with with the mfc42 runtime, I managed to get a backtrace with debugging information, which looks like this: =1 0x5f4056dd CEnumOleVerb::~CEnumOleVerb+0x37 [oleverb.cpp:61] in mfc42 (0x5f4056dd) You should find out what it does before. Capture a WINEDEBUG=+relay,+seh trace (redirect output to a logfile). Then look at this trace, search for the winedbg call and scroll back until the RaiseException with c0005 code (likely only some dozen lines above the initial debugger start). The look backwards from this to see where it might have got this NULL pointer... :/ If its bad, it could have got it from millions of lines ago. :/ Hello Marcus and thanks for your response! OK, sounds a bit ad-hoc to me but I'm sure that you're talking from experience. In the relay trace, I can see that just before the exception is raised, it sits in a loop calling: 0009:Call user32.ShowWindow(,) ret=5f4056f5 0009:Ret user32.ShowWindow() retval= ret=5f4056f5 33 times (same return address each time), which looks a bit suspicious to me (HWND being 0). The return address is in MFC42, but as winedbg refuses to run the dang thing I can't resolve that into the actual MFC function or set any breakpoints or anything. So, looking a bit further up in the trace, my best bet is that it's getting that HWND from: 0009:Call user32.GetParent(00010026) ret=5f401281 ... 0009:Ret user32.GetParent() retval= ret=5f401281 But that's just a wild guess. 00010026 seems to the apps main window, because I see a lot of activity on that HWND before the crash - for example: 0009:Call user32.DrawMenuBar(00010026) ret=5f4136d0 ... 0009:Ret user32.DrawMenuBar() retval=0001 ret=5f4136d0 And I can see the menu bar of the main (top) window being updated just before the crash. I played around a bit with the graphics settings in winecfg with no result other than that I've now managed to lock myself out of wine (including winecfg) by specifying an invalid display depth :-( Does anyting of this make sense? Cheers, -- Christer Palm
Re: debugging help
Robert Reif wrote: I'm trying to help someone on wine-bugs (http://bugs.winehq.org/show_bug.cgi?id=4053) with a crash in a game. The problem is that the game is catching and displaying the exception. It also appears that the game won't run in winedbg. Does anyone have any ideas on how to proceed from here. from what I see in the debug log (from winedbg), the game runs under winedbg. IMO, you should use 'pass' instead of 'cont' to get further (this would pass the exception back to program instead of pretending it's fixed). A+ -- Eric Pouech
Re: debugging help
On Sat, 2005-12-24 at 10:04 -0500, Robert Reif wrote: I'm trying to help someone on wine-bugs (http://bugs.winehq.org/show_bug.cgi?id=4053) with a crash in a game. The problem is that the game is catching and displaying the exception. It also appears that the game won't run in winedbg. Does anyone have any ideas on how to proceed from here. This is just an off guess, but maybe you could try using a win32 debugger under wine (something like IDA Pro might work here; you can find a demo version that will probably do what you need here: http://www.datarescue.be/downloaddemo.htm) You might get more stuff on the crash if you do that. I don't have this game, so I haven't tested it myself. Hope this helps. James
Re: Debugging winelib apps in Eclipse
Michael Ost wrote: Does anyone know how to set up Eclipse to debug winelib applications? I tried just replacing 'gdb' with 'winedbg' on the Debugger tab on the Debug window. After Eclipse says Launching... there is an error that says Process terminated. After reviewing the winelib debug docs, I found that there is a --gdb switch to winedbg so I added that as a C/C++ Program Argument on the Arguments tab of the same window... a long shot, and it didn't work. This is on Fedora Core 4, with Eclipse 3.1 (yum updated from the 3.1M6 version that comes with FC4), and with the wine 0.99.2 FC4 rpm. Any leads? Thanks ... mo There is no need to use winedbg for a winelib application. The only advantage for that is the heap-walk, thread-walk and other special winedbg commands that will be hard to reach from the GUI. The disadvantage is that it is not compatible enough and breaks the GUI. Just use gdb it can understand all your symbols and wine's. What you need to do is run wine-kthread or wine-pthread directly. Check in your ps when you run a wine application what actually loads. Free Life Boaz
Re: Debugging winelib apps in Eclipse
On 12/2/05, Michael Ost [EMAIL PROTECTED] wrote: Does anyone know how to set up Eclipse to debug winelib applications? I tried just replacing 'gdb' with 'winedbg' on the Debugger tab on the Debug window. After Eclipse says Launching... there is an error that says Process terminated. You're probably going to have to find a way to make Eclipse run wine-pthread directly instead of the wine binary. -- James Hawkins
Re: Debugging winelib apps in Eclipse
Michael Ost wrote: Does anyone know how to set up Eclipse to debug winelib applications? I tried just replacing 'gdb' with 'winedbg' on the Debugger tab on the Debug window. After Eclipse says Launching... there is an error that says Process terminated. After reviewing the winelib debug docs, I found that there is a --gdb switch to winedbg so I added that as a C/C++ Program Argument on the Arguments tab of the same window... a long shot, and it didn't work. This is on Fedora Core 4, with Eclipse 3.1 (yum updated from the 3.1M6 version that comes with FC4), and with the wine 0.99.2 FC4 rpm. Any leads? Thanks ... mo I'd rather set the debugger name to winedbg --gdb instead of winedbg. If you use the C++ pgm args, the final command line will be: winedbg myapp.exe --gdb instead of winedbg --gdb myapp.exe HTH -- Eric Pouech
Re: Debugging Critical Section lockups
Robert Shearman wrote: Yep, example of what not to do in concurrent programming. You should Tell me about it - I do hard realtime for a living. One of the locks is the Win6 lock, another does not seem to have a name (shown as ? when things go bad). I wonder if, under Real Windows, the Win116 subsystem does not lock, and that is why this program doesn't die under Windows.
Re: Debugging Critical Section lockups
David D. Hagood wrote: I may have a repeatable case of an error in locking critical sections, so I'd like some pointers as to how to debug this. The case occurs with the installer for Delorme Street Atlas 5 - on my 2GHz Athlon desktop it runs without a hitch, but on my oold slow laptop (how old is it? It's so old, it used PIO for the disk!) the program locks up 100% of the time at startup, with 2 threads trying to take different critical section locks and dying. It looks like the standard deadlock condition: one thread tries to lock A-B-C, the other tries to lock A-C-B, and so they deadlock. Unless the installer is using TryEnterCriticalSection, I would expect CPU utilisation to be 0% when deadlocking. Relay logs generally give the best clues in this kind of situation. -- Rob Shearman
Re: Debugging Critical Section lockups
Robert Shearman wrote: David D. Hagood wrote: Unless the installer is using TryEnterCriticalSection, I would expect CPU utilisation to be 0% when deadlocking. Yes, *once the deadlock occurs* the CPU drops to 0%. The issue (I think) is more along the lines of this: On fast CPU: thread 1 locks resource A, does something, locks B, unlocks B, unlocks A. Thread 2 locks B, does something, locks A, does something, unlocks C, A. On slow machine: Thread 1 locks resource A, does something. Context switch. Thread 2 locks B, does something. Context switch Thread 1 tries to lock B and blocks. Context switch. Thread 2 tries to lock A and blocks. Deadlock. In other words, on the fast CPU the deadlock does not happen because thread 1 gets everything done before thread 2 starts. On the slow machine, thread 2 starts while thread 1 is still doing stuff.
Re: Debugging Critical Section lockups
David D. Hagood wrote: Robert Shearman wrote: David D. Hagood wrote: Unless the installer is using TryEnterCriticalSection, I would expect CPU utilisation to be 0% when deadlocking. Yes, *once the deadlock occurs* the CPU drops to 0%. The issue (I think) is more along the lines of this: On fast CPU: thread 1 locks resource A, does something, locks B, unlocks B, unlocks A. Thread 2 locks B, does something, locks A, does something, unlocks C, A. On slow machine: Thread 1 locks resource A, does something. Context switch. Thread 2 locks B, does something. Context switch Thread 1 tries to lock B and blocks. Context switch. Thread 2 tries to lock A and blocks. Deadlock. In other words, on the fast CPU the deadlock does not happen because thread 1 gets everything done before thread 2 starts. On the slow machine, thread 2 starts while thread 1 is still doing stuff. Yep, example of what not to do in concurrent programming. You should make a note of the order in which locks are taken and always take the locks in that order and always release them in the opposite order. You have several options from here: 1. File a bug report with the maker of the application. 2. Find a function that B uses just before it locks that A doesn't use and add a Sleep call. Obviously this kind of fix won't be accepted into Wine. 3. Do tests to try to find a function that A uses that is much slower on Wine and try to fix it. -- Rob Shearman
Re: debugging app exceptions?
On Sun, 09 Oct 2005 10:42:13 +0200, wino wrote: I am trying to debug an app and making good progress with on sorting out the dlls reqd. but now have an exception I dont know how to follow. Look at the debugging guides we wrote on the wiki. For this kind of bug, a +relay,+tid,+seh trace is a good start. Find the first seh: line and that'll show you where the exception was thrown.
Re: Debugging remotely from Visual studio
what's strange is that esp is within stack limit... wine exception handler must this from another part... it may come from msvcmon tweaking the selectors (cs, ss) for some reasons I agree it is strange but it still comes up after a bunch of 001b: *signal* signal=5 that should not be there. Any idea how I can trace the cause for the repetition of this signal ? Or how I can fix it ? Thanks David
Re: Debugging remotely from Visual studio
David Hemmo a écrit : what's strange is that esp is within stack limit... wine exception handler must this from another part... it may come from msvcmon tweaking the selectors (cs, ss) for some reasons I agree it is strange but it still comes up after a bunch of 001b: *signal* signal=5 that should not be there. are you sure they are all from the same address ? if not, it only means the program is being single stepped. Any idea how I can trace the cause for the repetition of this signal ? we didn't change much in this area lately. Or how I can fix it ? can you send me the whole +seh,+server trace. TIA A+ -- Eric Pouech
Re: Debugging remotely from Visual studio
David Hemmo a écrit :
Eric Pouech wrote:
- kernel send a trap signal
- wine's ntdll catches it, and queue the information as a debug event
in the wineserver
- the debugger (msvcmon in your case) get notified of the trap while
waiting for a debug event
I understand.
I made a log of what happens when I single step with the debugger:
I see the debugger waking up
001b: *wakeup* signaled=258 cookie=0x2f9ce4
then, a little further it get the exception status
001b: get_exception_status() = 0
{status=65538,context={flags=00010007,...,eflags=00210346,...}}
and then the same thread has a lot of lines in the log with the same
message
001b: *signal* signal=5
until the message
001b:warn:seh:setup_exception exception outside of stack limits in
thread 001b eip 002b448d esp 019b12ec stack 0x19b-0x1ab
what's strange is that esp is within stack limit... wine exception handler must
this from another part... it may come from msvcmon tweaking the selectors (cs,
ss) for some reasons
A+
--
Eric Pouech
Re: Debugging remotely from Visual studio
Eric Pouech wrote:
- kernel send a trap signal
- wine's ntdll catches it, and queue the information as a debug event in
the wineserver
- the debugger (msvcmon in your case) get notified of the trap while
waiting for a debug event
I understand.
I made a log of what happens when I single step with the debugger:
I see the debugger waking up
001b: *wakeup* signaled=258 cookie=0x2f9ce4
then, a little further it get the exception status
001b: get_exception_status() = 0
{status=65538,context={flags=00010007,...,eflags=00210346,...}}
and then the same thread has a lot of lines in the log with the same message
001b: *signal* signal=5
until the message
001b:warn:seh:setup_exception exception outside of stack limits in
thread 001b eip 002b448d esp 019b12ec stack 0x19b-0x1ab
It clearly looks like a recursive call, or an infinite loop.
Any idea of what can trigger such a behaviour ?
Another question that could be related is the status of the trace flag
in EFlags (0x100). It looks like wine clears it in some of its code
(raise_trap_exception and the handler for SIGTRAP in signal_i386.c).
Shouldn't it be the debugger responsibilty ?
Thanks
David Hemmo
PS: I hope I am clear enough. Don't hesitate to contact me if anything
is missing, or not clear.
Re: Debugging remotely from Visual studio
David Hemmo a écrit : Hello, After reading a mail exchanges about ptrace on Linux, I decided to switch to a newer Linux kernel to see how it modified my problem. Things got worse. Restarting a program from Visual studio stopped working. Is there anyone that can explain me how things are supposed to work ? I think I know the basics. To start, the debugger set the bit 0x100 in EFlags ot the current context, then wine test this bit to check what parameter to send to ptrace to restart the process. It gets blurry after that ... What happens after the traced instruction executes ? - kernel send a trap signal - wine's ntdll catches it, and queue the information as a debug event in the wineserver - the debugger (msvcmon in your case) get notified of the trap while waiting for a debug event A+ -- Eric Pouech
Re: Debugging with GDB [was: Re: World of Warcraft - crash in game]
On Sun, Apr 24, 2005 at 09:23:22AM +1000, Troy Rollo wrote: On Saturday 23 April 2005 22:12, Alex Woods wrote: I'm attaching to the process with gdb, but it's not catching things at the point where they go wrong. Typically I am just seeing a stack like this though: #0 0x56752a01 in ?? () If it's only giving one frame in the stack trace the cause is normally a corrupted stack, so you may need to examine the stack to try to figure out where the stack frame should be (starting with x/256xw may be helpful if the stack pointer is still valid). Yeah, the stack always looks in pretty bad shape. The address of the #0 frame has been within nvidia's libGLCore.so.1 everytime I've had a SIGSEGV. Other times when an exception is caught by WoW, it often comes back with an Out of memory message from one of it's files - off the top of my head MapMem.cpp, SFile.cpp and Texture.cpp. I don't think it's a problem with the nvidia driver since it handles doom3 just fine. I do think it's a problem around the OpenGL space though, because turning down the graphical options makes the game stable. I might try playing with the options to see if any particular one is the cause. Otherwise, when debugging with GDB without going through winedbg you may need to use the pass command to skip over first chance exceptions in some cases before you get to the real exception. I'm not sure I'm seeing the first chance exceptions at all until - I presume these are exceptions that are raised but are expected to some extent and so are handled without stopping execution? I just seem to be seeing signals telling the thread it's been suspended I think. I'm not clear on how wine handles exceptions though. Cheers. -- Alex
Re: Debugging with GDB [was: Re: World of Warcraft - crash in game]
On Saturday 23 April 2005 22:12, Alex Woods wrote: I'm attaching to the process with gdb, but it's not catching things at the point where they go wrong. Typically I am just seeing a stack like this though: #0 0x56752a01 in ?? () If it's only giving one frame in the stack trace the cause is normally a corrupted stack, so you may need to examine the stack to try to figure out where the stack frame should be (starting with x/256xw may be helpful if the stack pointer is still valid). Otherwise, when debugging with GDB without going through winedbg you may need to use the pass command to skip over first chance exceptions in some cases before you get to the real exception.
Re: Debugging mingw applications using wine
Bryce McKinlay a écrit : Eric Pouech wrote: Bryce McKinlay a écrit : I'm trying to debug a windows .exe built with mingw using wine, but winedbg seems to have problems reading stabs from the mingw-built binary. My goal is to be able to debug a cross-compiled, native Java (GCJ) application, but even a simple C hello world seems to cause problems. winedbg using the gdb won't work here because (likely on unix) gdb isn't compiled with proper 'stabs in PE' support you can either: - use bare winedbg (without gdb support) - recompile gdb with 'stabs in PE' support (ie the settings used when compiling gdb under windows) Could you give any hints as to how to configure GDB with 'stabs in PE' support? The only reference I could find in the GDB documentation is: 6.4.5 PE Windows 95 and NT use the PE (/Portable Executable/) format for their executables. PE is basically COFF with additional headers. While BFD includes special PE support, GDB needs only the basic COFF reader. Is there a configure option to enable this support in the standard BFD/GDB code? (I'm using GDB from CVS head) - or are special patches required? How did you get/build the GDB you use? There's no such things (and it's definitively not an easy task, which still remains to be done, and that Wine decided not to implement some years ago). A+ -- Eric Pouech
Re: Debugging mingw applications using wine
Eric Pouech wrote: Could you give any hints as to how to configure GDB with 'stabs in PE' support? The only reference I could find in the GDB documentation is: 6.4.5 PE Windows 95 and NT use the PE (/Portable Executable/) format for their executables. PE is basically COFF with additional headers. While BFD includes special PE support, GDB needs only the basic COFF reader. Is there a configure option to enable this support in the standard BFD/GDB code? (I'm using GDB from CVS head) - or are special patches required? How did you get/build the GDB you use? There's no such things (and it's definitively not an easy task, which still remains to be done, and that Wine decided not to implement some years ago). In that case, what is winedbg --gdb for? Why have this option if no GDB supports it? Bryce
Re: Debugging mingw applications using wine
Eric Pouech wrote: Bryce McKinlay a écrit : I'm trying to debug a windows .exe built with mingw using wine, but winedbg seems to have problems reading stabs from the mingw-built binary. My goal is to be able to debug a cross-compiled, native Java (GCJ) application, but even a simple C hello world seems to cause problems. winedbg using the gdb won't work here because (likely on unix) gdb isn't compiled with proper 'stabs in PE' support you can either: - use bare winedbg (without gdb support) - recompile gdb with 'stabs in PE' support (ie the settings used when compiling gdb under windows) Could you give any hints as to how to configure GDB with 'stabs in PE' support? The only reference I could find in the GDB documentation is: 6.4.5 PE Windows 95 and NT use the PE (/Portable Executable/) format for their executables. PE is basically COFF with additional headers. While BFD includes special PE support, GDB needs only the basic COFF reader. Is there a configure option to enable this support in the standard BFD/GDB code? (I'm using GDB from CVS head) - or are special patches required? How did you get/build the GDB you use? Thanks! Bryce
Re: Debugging mingw applications using wine
Bryce McKinlay a écrit : I'm trying to debug a windows .exe built with mingw using wine, but winedbg seems to have problems reading stabs from the mingw-built binary. My goal is to be able to debug a cross-compiled, native Java (GCJ) application, but even a simple C hello world seems to cause problems. winedbg using the gdb won't work here because (likely on unix) gdb isn't compiled with proper 'stabs in PE' support you can either: - use bare winedbg (without gdb support) - recompile gdb with 'stabs in PE' support (ie the settings used when compiling gdb under windows) I tried your exe with latest cvs and it load just fine in winedbg (with and without gdb support) I don't know what the unknown stabs type are for. They aren't defined in latest gdb (6.3), the only trace I found was for the MacOS/X but I doubt it concerns your case. A+
Re: Debugging mingw applications using wine
On Sun, Jan 02, 2005 at 11:35:07AM +0100, Eric Pouech wrote: winedbg using the gdb won't work here because (likely on unix) gdb isn't compiled with proper 'stabs in PE' support Maybe we should lobby people (like Fedora) to enable it by default. -- Dimi.
Re: Debugging mingw applications using wine
Dimitrie O. Paun a écrit : On Sun, Jan 02, 2005 at 11:35:07AM +0100, Eric Pouech wrote: winedbg using the gdb won't work here because (likely on unix) gdb isn't compiled with proper 'stabs in PE' support Maybe we should lobby people (like Fedora) to enable it by default. but this would require teaching gdb to use winelib too A+
Re: Debugging mingw applications using wine
On Sat, 2005-01-01 at 17:53 -0500, Bryce McKinlay wrote: WINE is wine-0.20040914-1.rhfc2.nr from newrpms.sunsite.dk Did you try the newer rpms on Wine's download page? One was probably built for the same setup you're using. I've attached the mingw-compiled C binary. Is it worth trying again with a newwer WINE? Thanks! Always! -Scott Ritchie
Re: Debugging mingw applications using wine
On Sat, 2005-01-01 at 18:04 -0800, Scott Ritchie wrote: On Sat, 2005-01-01 at 17:53 -0500, Bryce McKinlay wrote: I've attached the mingw-compiled C binary. Is it worth trying again with a newwer WINE? Thanks! Always! -Scott Ritchie Wait, I need to correct myself: NOT ALWAYS. There was a horrible bug in winelib that prevents compiling anything in the last release. Heh, sorry. For now I recommend either CVS or waiting for a week or two for the next release. And, uh, I also recommend we go to a stable release system sooner rather than later :) -Scott
