Hi Mark,
Be careful, there is also Wine's port.h in fst/include.
I tried copying current versions of the borrowed wine files, and cleaning
up the resulting problems (mostly just headers that need to be found in
the right place since fst's directory structure is not the same as
Wine's). It still seg faults in the same way. As you pointed out, this
wouldn't explain why the memory patch made such a big difference.
Now look in fst/libwinelib.c. This is the meat of the hack that allows
fst to use wine in the way it does. I don't think this is a "normal"
winelib application, as those shouldn't use wineserver (right?). In
libwinelib.c you will find that all kinds of things from virtual.c are
called:
GET_SYMBOL (ntallocatevm, ntdll, "NtAllocateVirtualMemory");
GET_SYMBOL (ntfreevm, ntdll, "NtFreeVirtualMemory");
GET_SYMBOL (ntprotectvm, ntdll, "NtProtectVirtualMemory");
GET_SYMBOL (acquirepeblock, ntdll, "RtlAcquirePebLock");
GET_SYMBOL (releasepeblock, ntdll, "RtlReleasePebLock");
The change in behavior of these functions probably nukes the delicate
operation of kludging fst into wineserver.
- Walter
On Fri, 29 Oct 2004, Mark Knecht wrote:
> On Fri, 29 Oct 2004 09:21:10 -0700, Duane Clark <dclark@xxxxxxxxxxx> wrote:
> > Walt Ogburn wrote:
> > > 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.
> > >
> >
> > Yes, that is exactly what I am starting to think. I wonder if the
> > problem would go away if jack_fst were recompiled with a current version
> > of Wine. I suspect there is a good chance that would fix things.
>
> No - I tried it. Didn't work. Recompiled both fst and jack_fst. Same
> issue. Same issue even if I recompiled them the special version that
> only has the fixes from 5/24.
>
> Looking through the fst-1.6 library there are a smallish list of files
> that were lifted right out of Wine at the time they did the work to
> make fst-1.6:
>
> flash wine $ ls -la
> total 132
> drwxr-xr-x 2 mark users 1024 Oct 29 09:35 .
> drwxr-xr-x 4 mark users 1024 Oct 29 08:49 ..
> -rw-r--r-- 1 mark users 1217 Oct 29 06:48 gettid.c
> -rw-r--r-- 1 mark users 6814 Oct 29 06:48 interlocked.c
> -rw-r--r-- 1 mark users 10899 Oct 29 06:48 port.h
> -rw-r--r-- 1 mark users 5645 Oct 29 06:48 pthread.c
> -rw-r--r-- 1 mark users 4947 Oct 29 06:48 pthread.h
> -rw-r--r-- 1 mark users 3702 Oct 29 06:48 server.h
> -rw-r--r-- 1 mark users 83049 Oct 29 06:48 server_protocol.h
> -rw-r--r-- 1 mark users 6725 Oct 29 06:48 thread.h
> -rw-r--r-- 1 mark users 4503 Oct 29 06:48 windef16.h
> flash wine $
>
> The changelog says this was all done in March/2004. It worked until
> May/2004 and then died on May 24th as I've discovered. Using some diff
> tools the Gentoo folks turned me on to I can see that the changes are
> very big in some cases.
>
> However, when I look for an overlap between the files that were copied
> in March and the files that were changed in the update that killed
> jack_fst (shown below) I see no direct overlaps.
>
> <SNIP>
> Modified files:
> loader : main.c
> libs/wine : wine.map wine.def port.c loader.c Makefile.in
> include/wine : library.h
> dlls/ntdll : virtual.c
> dlls/kernel : process.c
> Added files:
> libs/wine : mmap.c
>
> Log message:
> Added support for managing reserved memory areas in libwine and ntdll.
> Try to reserve everything above 0x80000000 on startup.
> <SNIP>
>
> The log message above is a bit scary WRT the problem I'm having
> though. Segfaults are often memory issues, I think.
>
> For fun I created a TEST-fst-1.7 directory, copied all the code from
> 1.6 over, and then copied the newest files from wine-20041019 to
> replace the files above. fst won't build. (Not a big surprise, but
> disappointing.) Redefinition problems. Other things too...
>
> Don't exactly know where to go right now. I suspect that Alexandre
> won't be very interested in helping fix a program that copied old Wine
> files and is now broken. Of far more interest to me is how do I fix
> this so that it continues to work with Wine into the future? A bit
> beyond me, but an interesting task I think.
>
> >
> > Mark Knecht wrote:
> > > It's quite interesting doing this poking around. I'm a hardware
> > > designer by trade - PC chipsets and 1394 stuff - I don't mess with
> > > code at this level very often.
> > >
> >
> > Ah, well that interesting. I am also a hardware designer; doing various
> > FPGA design work. I use Wine to run some engineering software, and try
> > to tinker with it in my spare time.
> >
>
> Funnt. It'll probably turn out you're in the cube next to me in
> Silicon Valley. Small world. ;-)
> _______________________________________________
> wine-users mailing list
> wine-users@xxxxxxxxxx
> http://www.winehq.org/mailman/listinfo/wine-users
>
_______________________________________________
wine-users mailing list
wine-users@xxxxxxxxxx
http://www.winehq.org/mailman/listinfo/wine-users
