[Wine]old Wine from CVS

[Walt Ogburn]

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...
>