It turns out the scribbling is almost it! The crash is not the scribbling
itself, but the "char buf[JACK_THREAD_STACK_TOUCH];". This is usually
something huge. If you make it smaller, the crash goes away - for me, the
critical value is 14528 (OK), 14529 (crashes). It seems that the end of
buf is getting close to 0xC0000000 when the size of buf is 14528, and
maybe something starts to go over.
Now, I don't know anything about memory issues, so why is 0xC0000000 so
important?
If one of you who has tried compiling the doesn't-break-jack-fst version
of wine cares to check, you might see which of the following possibilities
is the case with the older wine: (1) buf doesn't get close to 0xC0000000;
or (2) it does, but it's OK. I just replaced the size of buf in
libjack/client.c: jack_activate with 14528 by hand and put in a debugging
message like
printf ("buf: base = %p, size = %d, end = %p.\n", buf, size(buf), buf+sizeof(buf));
(Of course, if you don't want a crash, you should also replace
JACK_THREAD_STACK_TOUCH with 14528 in the scribbling code!)
- Walter
> >
> > 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.
>
> Question - Do you have Jack installed and running?
>
> I don't think the above comment is as evil as it might look. In the
> context of how Jack works it uses FIFOs in memory to transfer audio
> data from client to client. I think it uses /dev/shm type memory which
> needs to be built into your kernel as far as I know. I have this
> stuff. Do you?
_______________________________________________
wine-users mailing list
wine-users@xxxxxxxxxx
http://www.winehq.org/mailman/listinfo/wine-users
