> In the code calling the ggLock/ggUnlock with the NULL value is code from
> the file unix.c from the libgii-0.6/gii
> directory. In my version I got the file in the form of a tgz file and
> built it so that I could build and debug the game.
> A snippet of code around the call from gii/unix.c is ....
> /* Give the sources a try. */
> tmpmask = _giiPollall(inp, mask, NULL); // <<<<<<<<<<<< here it is
The NULL is a pointer to a fd_set ... if there is none, Pollall will just
poll. If there is it can select();
> gii_event_mask
> _giiPollall(struct gii_input *inp, gii_event_mask mask, void *arg)
> {
> retmask |= (curr->GIIeventpoll(curr, arg) & mask);
> where the NULL from above is now the value for the void * arg.
Yes. Correct it is passing the currently select()ed fds, so that the libs
that support it can decide faster, if they are interested in the current
poll phase.
> The routine at curr->GIIeventpoll( ... ) isn't debugable, so I don't
> know where that goes.
It jumps into one of the dynamically loaded input libraries.
> The level of call goes to ggLock and ggUnlock, where the NULL value for
> the mutex causes the failure in the original version of the code.
If it is really arg being NULL, that causes this (which I doubt, but ...),
then one of the dynamically loaded input libraries is broken an should be
fixed. Arg should never be used in conjunction with ggLock/Unlock.
Hmm - the only lib calling ggLock/Unlock is the xwin lib, and the code
looks right:
static gii_event_mask GII_xwin_eventpoll(gii_input *inp, void *arg)
{
xwin_priv *priv = XWIN_PRIV(inp);
...
GIIDPRINT_EVENTS("GII_xwin_eventpoll(%p) called\n", inp);
if (priv->lock) ggLock(priv->lock);
As the lock is derived from inp, as it should be, not from arg, I don't see
any problem.
You aren't trying to set up the xwin input module yourself, are you ?
It's tricky to do that by hand. Don't, unless you really really know
what is going on there and really really want to bypass the standard
mechanism. LibGGI will do it right for you.
> Is there something obvious that avoids this problem -- it looks
> unavoidable (since the call is set up in a library I don't own)?
No, you will probably have to check out the problem again. Passing a NULL
arg is not a problem. strace and GGI_DEBUG=255 will help you to track the
problem further.
> Why is this tightly coupled library abusing the interface?
It isn't.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
