Hi Eric,
One of my wine development machines is running a 64bit version of Debian. In case of debian all 32bit libraries and programs are installed in a 32bit 'chroot' /emul/ia32-linux. Wine is installed there aswell and further the 32bit libs from the chroot environment are in the library path. Wine itself works fine but when some program crashes winedbg doesn't produce very usefull information.
For instance a 'bt' using 'winedbg notepad' should give something like: 0x603984f7 start_process+0xe7 [/usr/src/wine/dlls/kernel/process.c:822] in kernel32: movl %edi,0x0(%esp) 822 ExitProcess( entry( peb ) );
On this system I get something like: Wine-dbg>bt Backtrace: =>1 0x603984f7 (0x603984f7) 2 0x60022657 (0x60022657)
Further I notice lots of lines like this: fixme:dbghelp:SymLoadModule Should have successfully loaded debug information for image c:\windows\system32\kernel32.dll fixme:dbghelp:SymLoadModule Should have successfully loaded debug information for image c:\windows\system32\ntdll.dll
I think that the cause of the problem lies in here as I don't see these lines on a standard 32bit system. Further if I install wine into a standard /usr/local prefix, winedbg works ok aswell. It shows the correct information and the SymLoadModule lines don't fail either.Most likely there's some path issue in dbghelp.
I have tried to look at the code but it is a big maze to me. Perhaps you have an idea where the problem can be.
Regards, Roderick Colenbrander
Dbghelp looks for the ELF module in the PATH and LD_LIBRARY_PATH environment
variables, while the internal loader relies on WINEDLLPATH and the default DLL dir (or the build one). You could work around this by setting one of those variables. Dbghelp needs to be updated to follow the loader's rules from libwine (I'll do it later on this week) A+
2006/8/20, Roderick Colenbrander [email protected]:
Hi Eric,
One of my wine development machines is running a 64bit version of Debian. In case of debian all 32bit libraries and programs are installed in a 32bit 'chroot' /emul/ia32-linux. Wine is installed there aswell and further the 32bit libs from the chroot environment are in the library path. Wine itself works fine but when some program crashes winedbg doesn't produce very usefull information.
For instance a 'bt' using 'winedbg notepad' should give something like: 0x603984f7 start_process+0xe7 [/usr/src/wine/dlls/kernel/process.c:822] in kernel32: movl %edi,0x0(%esp) 822 ExitProcess( entry( peb ) );
On this system I get something like: Wine-dbg>bt Backtrace: =>1 0x603984f7 (0x603984f7) 2 0x60022657 (0x60022657)
Further I notice lots of lines like this: fixme:dbghelp:SymLoadModule Should have successfully loaded debug information for image c:\windows\system32\kernel32.dll fixme:dbghelp:SymLoadModule Should have successfully loaded debug information for image c:\windows\system32\ntdll.dll
I think that the cause of the problem lies in here as I don't see these lines on a standard 32bit system. Further if I install wine into a standard /usr/local prefix, winedbg works ok aswell. It shows the correct information and the SymLoadModule lines don't fail either.Most likely there's some path issue in dbghelp.
I have tried to look at the code but it is a big maze to me. Perhaps you have an idea where the problem can be.
Regards, Roderick Colenbrander --
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Eric Pouech wrote:
Dbghelp looks for the ELF module in the PATH and LD_LIBRARY_PATH environment variables, while the internal loader relies on WINEDLLPATH and the default DLL dir (or the build one). You could work around this by setting one of those variables. Dbghelp needs to be updated to follow the loader's rules from libwine (I'll do it later on this week) A+
as a matter of fact, we already take care of the WINEDLLPATH in dbghelp so the issue is somewhere else could you send me the +dbghelp trace in both cases (when it works and when it doesn't) TIA
I have attached a tarball containing two logs one in case it works (log.works) and one in which it fails (log.fails). When it worked wine was installed in /usr/local and in the other case in /emul/ia32-linux/usr.
In the working case I executed 'WINEDEBUG=+dbghelp winedbg notepad' and piped the output to a log and directly killed it. You'll notice the first line of winedbg in it.
The second time I did the same but because wine wasn't in the path yet I did 'WINEDEBUG=+dbghelp /emu/ia32-linux/usr/bin/wine winedbg notepad'. In previous cases I had symlinks to wine/wineserver in the path and at that moment the same problem appeared
Roderick
On Thursday 24 August 2006 18:55, Eric Pouech wrote:
Eric Pouech wrote:
Dbghelp looks for the ELF module in the PATH and LD_LIBRARY_PATH environment variables, while the internal loader relies on WINEDLLPATH and the default DLL dir (or the build one). You could work around this by setting one of those variables. Dbghelp needs to be updated to follow the loader's rules from libwine (I'll do it later on this week) A+
as a matter of fact, we already take care of the WINEDLLPATH in dbghelp so the issue is somewhere else could you send me the +dbghelp trace in both cases (when it works and when it doesn't) TIA
Roderick Colenbrander wrote:
I have attached a tarball containing two logs one in case it works (log.works) and one in which it fails (log.fails). When it worked wine was installed in /usr/local and in the other case in /emul/ia32-linux/usr.
In the working case I executed 'WINEDEBUG=+dbghelp winedbg notepad' and piped the output to a log and directly killed it. You'll notice the first line of winedbg in it.
The second time I did the same but because wine wasn't in the path yet I did 'WINEDEBUG=+dbghelp /emu/ia32-linux/usr/bin/wine winedbg notepad'. In previous cases I had symlinks to wine/wineserver in the path and at that moment the same problem appeared
Roderick
On Thursday 24 August 2006 18:55, Eric Pouech wrote:
Eric Pouech wrote:
Dbghelp looks for the ELF module in the PATH and LD_LIBRARY_PATH environment variables, while the internal loader relies on WINEDLLPATH and the default DLL dir (or the build one). You could work around this by setting one of those variables. Dbghelp needs to be updated to follow the loader's rules from libwine (I'll do it later on this week) A+
as a matter of fact, we already take care of the WINEDLLPATH in dbghelp so the issue is somewhere else could you send me the +dbghelp trace in both cases (when it works and when it doesn't) TIA
Hi Roderick
thanks for the logs why isn't /emul/ia32-linux/usr/bin/ in your PATH environment variable ? that should fix it (and I don't see a simple way of guessing the exec path from the debugger) A+
-
Eric Pouech -
Eric Pouech -
Roderick Colenbrander