On Thu, 28 Oct 2004 20:57:39 -0700 (PDT), Walt Ogburn <reuben@xxxxxxxxxxxxxxxx> wrote: > Hi Mark, > > Yes, FIXME is really intended as a warning that something in particular > needs to be fixed, but I was just using it like a print. Assuming that > Wine is compiled with the usual options, you will see its output even > if you didn't set any debug flags. I'm further from being a programmer > than you are (physics grad student), just trying to learn something and > make a few useful applications work. > > From your next message... > > Oh well, that didn't reveal much! The pointer is not anything crazy, > and in fact its value is one that didn't crash before. I was hoping > maybe for something obviously weird. > > - Walter > > I tried one more time with WINEDEBUG=+all and the FIXME in. Seems like that's the most info I can get without adding more FIXME's somewhere else. Here's the last bit. Still nothing obvious to me: 000b:Call ntdll.RtlLeaveCriticalSection(7fc2f540) ret=7fdec9cb 000b:fixme:ntdll:RtlLeaveCriticalSection Watching for seg fault: (crit = 0x7fc2f540) 000b:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7fdec9cb 000b:trace:syslevel:_LeaveSysLevel (0x7fc2f540, level 3): thread b count after 1 000b:Ret kernel32._LeaveSysLevel() retval=00000052 ret=7fbf7d3b 000b:Ret gdi32.GDI_ReleaseObj() retval=00000052 ret=7f9e5296 000b:Call ntdll.RtlEnterCriticalSection(7fa2c680) ret=7fa0ab22 000b:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=7fa0ab22 000b:Call ntdll.RtlLeaveCriticalSection(7fa2c680) ret=7fa0ab52 000b:fixme:ntdll:RtlLeaveCriticalSection Watching for seg fault: (crit = 0x7fa2c680) 000b:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7fa0ab52 000b:Call gdi32.GetObjectType(0000076c) ret=7f9e53f8 000b:trace:gdi:GetObjectType 0x76c 000b:Call kernel32._EnterSysLevel(7fc2f540) ret=7fbf7b9b 000b:trace:syslevel:_EnterSysLevel (0x7fc2f540, level 3): thread b count before 1 000b:Call ntdll.RtlEnterCriticalSection(7fc2f540) ret=7fdec83c 000b:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=7fdec83c 000b:trace:syslevel:_EnterSysLevel (0x7fc2f540, level 3): thread b count after 2 000b:Ret kernel32._EnterSysLevel() retval=7fe6e440 ret=7fbf7b9b 000b:trace:gdi:GDI_GetObjPtr (0x76c): enter 2 000b:trace:gdi:GDI_ReleaseObj (0x76c): leave 2 000b:Call kernel32._LeaveSysLevel(7fc2f540) ret=7fbf7d3b 000b:trace:syslevel:_LeaveSysLevel (0x7fc2f540, level 3): thread b count before 2 000b:Call ntdll.RtlLeaveCriticalSection(7fc2f540) ret=7fdec9cb 000b:fixme:ntdll:RtlLeaveCriticalSection Watching for seg fault: (crit = 0x7fc2f540) 000b:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7fdec9cb 000b:trace:syslevel:_LeaveSysLevel (0x7fc2f540, level 3): thread b count after 1 000b:Ret kernel32._LeaveSysLevel() retval=00000052 ret=7fbf7d3b 0009: *killed* exit_code=0 000a: *killed* exit_code=0 000b: *killed* exit_code=0 000c: *killed* exit_code=0 Segmentation fault flash mark $ /home/mark/.wine/system.reg: saving key \\Machine /home/mark/.wine/userdef.reg: saving key \\User\\.Default /home/mark/.wine/user.reg: saving key \\User\\mark wineserver: exiting (pid=14841) Should I try some sort of FIXME in LeaveSysLevel? Oweing to the fact that virtual.c was a pretty major edit, and the edits are strewn all over the file, it still seems like there's a chance that the problem is in there. One thing I sort of found strange was that in the version on 5/23 there was a function being used called 'munmap'. One of the canges on 5/24 was to switch that to a new function called 'unmap_area'. This is fine, except on 5/24 there were a couple of large code areas added, and those areas still use 'munmap'. Probably it's nothing, but if someone was working in parallel is it possible that a shift to unmap_area was missed on these new areas? Anyway, I'm just loooking at pixels on the screen. I don't know what any of this does... _______________________________________________ wine-users mailing list wine-users@xxxxxxxxxx http://www.winehq.org/mailman/listinfo/wine-users
