[Wine]old Wine from CVS

[Duane Clark]

Mark Knecht wrote:
> ...
> Wine is being called by jack_fst, so when jack_fst dies I assume that
> Wine is cleaned up by Linux since it's a subprocess? If Wine had
> segfaulted wouldn't jack_fst still be in memory, which I don't see?
> 

Well, I did a bit of checking. I compiled fst/jack_fst, and ran it under 
an old version of Wine to check that things work and they seem to. I am 
using dfx_Scrubby.dll, whatever that does ;)

Then I tried without making changes to the fst code, but with a current 
Wine, and I do see the crash.

So then I executed it this way. First run jack_fst under gdb:
gdb jack_fst
Then at the gdb prompt, type
(gdb) r dfx_Scrubby.dll
That quickly crashed, as expected:

Starting program: /usr/local/bin/jack_fst dfx_Scrubby.dll
[New Thread 1081888352 (LWP 9484)]
[New Thread 1092565808 (LWP 9507)]
[New Thread 1093618480 (LWP 9508)]
[New Thread 1124731696 (LWP 9509)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1081888352 (LWP 9484)]
0x4001c3f4 in jack_activate (client=0x80b8318) at client.c:1376
1376    {
(gdb) bt
#0  0x4001c3f4 in jack_activate (client=0x80b8318) at client.c:1376
#1  0x0804a4f6 in main (argc=2, argv=0xbfffdb54) at jfst.c:260
#2  0x42015704 in __libc_start_main () from /lib/tls/libc.so.6

The crash is within the jack library. Looking at line 1376, I see that 
this is:
int
jack_activate (jack_client_t *client)
{
	jack_request_t req;

	/* we need to scribble on our stack to ensure that its memory
	 * pages are actually mapped (more important for mlockall(2)
	 * usage in jack_start_thread())
	 */
...

Oops, I wonder if that is doing evil things with Wine.