Hi Mark, That last one makes it look like the crash is in a different thread than the one we were looking at. I looked at jack_fst, and I guess you are using the fst library. This borrows a bunch of files from wine, so it's not too surprising if it breaks when the real wine version and the borrowed stuff are very dissimilar. - 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
