firefox 4, openjdk6, icedtea - a problem
Andriy Gapon
avg at FreeBSD.org
Tue Apr 19 09:50:29 UTC 2011
Here's a new twist.
First, some more details. The applet in question would start normally, but then
at some point it would seem to just hang. Then I accidentally noticed that if I
let the applet to just sit there, then it would recover after some long-ish
timeout, like 3 or 5 minutes.
I started investigating that and here are some results.
It seems that the plugin and a Java process that actually runs an applet
communicate with each other over a couple of named pipes (fifos). I see the
following when the hang happens:
- the plugin sends GetJavaObject message to the applet runner via fifo #1
- the applet runner gets the message, processes it and sends a reply via fifo #2
- the plugin doesn't see the message and keeps waiting
- the plugin finally times out and goes on to do other things
- a while later the plugin reads the message from fifo #2
So the problem seems to be that the plugin somehow doesn't see that there is a
message available for it in the fifo (or doesn't even check) until much later.
Some code snippets from the plugin code.
That's how the reception channel is set up:
in_from_appletviewer = g_io_channel_new_file (in_pipe_name,"r", &channel_error);
in_watch_source =
g_io_add_watch (in_from_appletviewer,
(GIOCondition) (G_IO_IN | G_IO_ERR | G_IO_HUP),
plugin_in_pipe_callback, (gpointer) in_from_appletviewer);
That's how the plugin waits for a response:
do
{
clock_gettime(CLOCK_REALTIME, &curr_t);
if (!result_ready && (curr_t.tv_sec < t.tv_sec))
{
if (g_main_context_pending(NULL))
g_main_context_iteration(NULL, false);
else
usleep(200);
}
else
break;
} while (1);
I suppose that internally the glib code should perform some kind of poll/select
on a fifo fd.
Not sure where things go wrong though.
Maybe something in glib, maybe firefox somehow messes up its polling.
Maybe this would ring a bell for anybody.
--
Andriy Gapon
More information about the freebsd-java
mailing list