On Tue, 20 Nov 2001, Jussi Jumppanen wrote: > lawson_whitney@juno.com wrote: > > > Now for _my_ version of "Why are you doing this?": Why run it with > > --debugmsg +all ?? If you have the source > > I do have the source. > > >, can you not tell what functions it is using/interested in/unhappy > > with the behavior of? > > But from the trace I am not even sure if the code has hit my source > code since I do not recognize the calls to NtEnumerateValueKey. > > I was hoping for some inspiration on how to track down this bug :) > > > For general debugging, +relay is what you want. > > I ran the function with: > > $ WINEPRELOAD=./x_zeus.so wine --debugmsg +relay > > and all that got produced in the trace output was: > > Segmetation Fault > > I suspect that there is something wrong with the loading > of the x_zeus.so since a I wrote a simple test application > and it loaded and ran fine. I am just not sure how to determine > where it is going wrong? > > As a test I compared the traces for the succesful load of > my test application and the failed load and both are identical > up to the point of: > > boot_done() Hmmm, boot_done does not appear in a +relay trace. It does however in a +all. As Gerard mentioned, +all may trigger some traces that are buggy, or as I suspect, try to trace each other recursively. If you must have boot_done, use +server. If you want to see heap also, use +server,+heap May as well throw in relay: --debugmsg +server,+heap,+relay That should give a big enough trace, without the perils of +all. Maybe a few more lines of context before it crashes would help us. It might take several hundred. The windose API is very busy, to very little good purpose AFAICT. > > Failed Load: > ============ > > 0806d080: boot_done() = 0 > 0806d080:trace:heap:HeapAlloc (40360000,00000002,00000018): returning > 4036168c > Segmentation fault > 0806d080: *killed* exit_code=0 > /home/jussij/.wine/user.reg: saving key \\User\\jussij > [jussij@linux zeus]$ /home/jussij/.wine/system.reg: saving key > \\Machine > /home/jussij/.wine/userdef.reg: saving key \\User\\.Default > Server: exiting (pid=6217) > > Successful load: > ================ > 0806d080: boot_done() = 0 > 0806d080:trace:heap:HeapAlloc (40360000,00000002,00000018): returning > 4036169c > 0806d080:trace:heap:HeapAlloc (40360000,00000002,00000018): returning > 403616c0 > 0806d080:trace:heap:HeapAlloc (40360000,00000002,00000018): returning > 403616e4 > 0806d080:trace:global:GLOBAL_Alloc 131 flags=0042 > 0806d080:trace:heap:HeapAlloc (40360000,00000002,000000a0): returning > 40361708 > 0806d080:trace:string:lstrcpynA (0x4036177d, "ntdll."..., 6) > 0806d080:trace:dosfs:GetShortPathNameA "ntdll.dll" > 0806d080:trace:heap:HeapAlloc (40360000,00000002,00000400): returning > 403617b4 > ..... > > So it would appear the fault lies very early on in the loading of > the x_test.so module. > > Are there any tips on how to go about debugging this point of the > load process? > > I tried using Winedbg but it behaves the same as using Wine. > > Regards Jussi Jumppanen > jussij@zeusedit.com > If you have winedbg set up properly in the registry, - I change <wine>/winedefault.reg to look so: ... # # Configuration for unhandled exceptions # [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug] # command line to start a debugger when an exception occurs "Debugger"="/usr/local/bin/winedbg %ld %ld" # to 0 if a message box has to be presented before running the debugger "Auto"="1" ... and run regapi setValue -- -force <winedefault.reg - winedbg should start up when a program segment faults, and give you a chance to see what it was trying to do. Lawson ---oof--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.
