Re: [Java-gnome-developer] Running File I/O Thread Crashes Java-Gnome

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

On Sat, 2010-06-05 at 08:11 +0000, someone who still doesn't have a real
name wrote:

> running the data retrieving part in a separate process (not just a separate
> thread).

That really shouldn't be necessary. You're either 

a) doing something horribly wrong.

or 

b) you've uncovered a nasty bug somewhere.

Given that worker threads and action handlers have been working fine for
us for years, I'm not entirely convinced it's (b), but it's always
possible that something has changed somewhere in the stack and that
you've hit something strange as a result.

On the other hand, it's not immediately obvious that you're doing (a),
so I'm not sure.

> which still causes the crash.

Yup.

What would be ideal is some kind of test case that ran automatically,
but that's not always easy. You've got it narrowed down fairly nicely as
it is.

You should probably open a bug now.

> This makes java-gnome unfit for many real-world application.

{shrug}

I know of a number of highly threaded apps that work just fine,
including several that I have written myself. So I'm not really sure I'd
agree with that sentiment, but then again I'm biased; java-gnome works
for everything I throw at it. So you're certainly not going to get my
goat with that one :)


> Your suggestion about sleeping the thread is good and I've tried this. My sleep
> time was 100ms per cycle 

That was just a debugging measure to slow things down a bit so we could
try and isolate what was happening. But personally, if I was dealing
with shorter sleeps I'd just Thread.yield().

The fact that it works fine for a while, then the DrawingArea stops
doing getting ExposeEvents is interesting. And that only happens when
you've started your worker thread. And not that the problem does *not*
happen if you terminate you app before the DrawingArea jams up.

It's *not* the whole app freezing, which is the behaviour you see if
you've somehow managed to block the main loop.

Which means it is something else.

> gdk_window_get_position: assertion `GDK_IS_WINDOW (window)' failed

"is window failed."
"isn't a window."
"isn't a GDK window."
"no window."
"no window?"
"client-side windows?"

Hmmm.

I wonder if this has something to do with the client-side windows
changes introduced in GTK 2.18? Well, the way to find out is to set
GDK_NATIVE_WINDOWS=true as an environment variable. That makes GTK fall
back to the deprecated-way-it-was to-be-removed-as
soon-as-all-the-bugs-are-fixed and-people-fix-their-apps behaviour.

$ GDK_NATIVE_WINDOWS=true java -classpath ~/workspace/java-gnome/tmp/gtk-4.0.jar:tmp/classes/ DrawingWindow

Works fine!

Try it?

++

Well. That would make this either:

i) a GTK bug

or

ii) a bug in the way that java-gnome is doing something to bind GTK,

or

iii) something you're not doing "correctly" as the developer using GTK
(in light of the client-side window changes).


My guess is that it is hopefully (iii) :) There are lots of people using
GtkDrawingAreas out there, so I can't imagine that if this were a GTK
problem it would have gone undetected this long. Under (ii) it _might_
be related to GC, or it might be somehow a change in how top level
Windows are reference counted. But I doubt that. We'll see.

Please open a bug. File it against java-gnome, and then we can consult
with the GTK hackers about the way forward [we may need to duplicate the
effect in C code to prove it's not a java-gnome or Java bug].

But before you do that, have a search of the GTK mailing list archives
for the last year or so. You'll see mention somwehere that some windows
have to explicitly request they be given a native X window to support
them if they need such a thing. My understanding was that GtkDrawingArea
already took care of this but in any case most GtkWidgets didn't need
such a thing because things would "just work". It's possible that the
interaction between us, GTK, and Cairo is confusing things. Anyway,
there may be a call we need to [add to java-gnome for you to] make.

AfC
Sydney

P.S. 

Note that you do NOT want this fallback as a global environment setting.
It's a major optimization for GTK and "the way ahead". The idea is to
fix the problematic usages, not rely on something that less performant
and deprecated.


-- 
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: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London