java-gnome-hackers

[java-gnome-hackers] Xlib: unexpected async reply

[Stefan P. <st...@pr...>]

Hi all,

I have a fairly complex java-gnome application which produces the
following exception after some time:
  Xlib: unexpected async reply (sequence 0x316e)!

Before this happens I use several signal handlers (MenuItem.ACTIVATE,
TreeView.ROW_ACTIVATE, Button.CLICKED) to open dialogs, modify data and
close them again. The error usually occurs after the last dialog is
closed and only the main application window is visible.

I failed writing a stripped down application that produces the same kind
of error.

Searching around I found a posting [1] which explains that manipulating
widgets from another thread might cause this problem, unless proper care
is taken (which I don't if java-gnome does yet).  

I did not add Java threads to my application, so all I did was relying
on the threads provided by the underlying GTK+/java-gnome library.

Has anyone of you experienced something similiar before and can advise
me what might cause this issue?

Cheers,
  Stefan

[1] http://osdir.com/ml/gnome.lib.gtk+.devel.apps/2002-04/msg00203.html

Re: [java-gnome-hackers] Xlib: unexpected async reply

[Stefan P. <st...@pr...>]

Perhaps related, perhaps not, but the same application causes crashes in
the JVM, resp. in the native GTK code.

You find the logs attached. Perhaps it helps.

Stefan

Re: [java-gnome-hackers] Xlib: unexpected async reply

[Andrew C. <an...@op...>]

On Fri, 2008-06-13 at 22:34 +0200, Stefan Prelle wrote:
> Perhaps related, perhaps not, but the same application causes crashes in
> the JVM, resp. in the native GTK code.

The only thing that stands out is that you've got nested Dialogs going
on.

I didn't really expect to see someone doing that, but it shouldn't
matter in the slightest.

AfC
Sydney

Re: [java-gnome-hackers] Xlib: unexpected async reply

[Andrew C. <an...@op...>]

On Fri, 2008-06-13 at 22:13 +0200, Stefan Prelle wrote:
> I have a fairly complex java-gnome application which produces the
> following exception after some time:
>   Xlib: unexpected async reply (sequence 0x316e)!

I haven't seen one of those in ages.

We go to *considerable* effort to lock GDK properly and to thereby make
java-gnome transparently thread safe. See
http://research.operationaldynamics.com/blogs/andrew/software/gnome-desktop/gtk-thread-awareness.html
and
http://research.operationaldynamics.com/blogs/andrew/software/java-gnome/thread-safety-for-java.html

It is possible that we missed synchronizing in some piece of Override
code, though I tend to be careful about looking for such things.

There was previously a separate problem where a native thread not
spawned by Java would not be attached, but that was fixed in revno 486.
Vreixo pointed out that we'll also need to synchronize access to the
knownProxies collections at some point, but that probably is not your
problem either.

Another possibility is that you've hit some part of GTK that is not
properly coded to be thread aware. That would be a bug, but finding it
may prove tricky. [FileChooser was rife with them at once point, but my
understanding is that most of that was cleaned up]

... if you grep the GTK source files you're code is going through for
add_timeout or add_idle and don't see it as gdk_threads_add_timeout() or
gdk_threads_add_idle() then that's probably a concern.


> I did not add Java threads to my application, so all I did was relying
> on the threads provided by the underlying GTK+ library.

That does tend to point to the sort of problem that GtkFileChooser
[once] caused.

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London