I traced thru. the SWT code and the problem occurs in XInitThreads.
I was running the stable build drop 200020125. And it, does use
the XInitThreads. Since, I had no clue about the SWT code, I did
not know, where to look for the XInitThreads and when I traced thru.
the program, I saw it get initialized at Display class of SWT. I created
my own JNI method, where it creates a shell calling X, Xt
directly(which uses XFillPolygon) and provided calling this method
within SWT code, until I reached where it stopped drawing XFillPolygon.
And, it failed to draw after calling XInitThreads.
> I hope, everyone do agree
that the problem is isolated
> to SWT code and some kind
of memory corruption is going
> on, correct?
Sridhar,
The problem is that, perfectly reasonable, working SWT code that runs on
several versions of linux, as well as Solaris, is failing because of an
incompatibility between that code and the HP-UX implementation of X/Motif.
I _do_not_ believe that memory corruption is the problem, although I _do_
believe it's probably the *symptom* you are seeing.
Basically, you need to look at all the native calls which are occurring
in the "high level" example James sent, and compare them against the ones
in the "low level Java PI" version. If there are any calls which show up
in the high level one which are not in the low level one, then they are
possible problem sites. For the calls which show up in both, make sure
the arguments are reasonable in both. If you have not got a debugger that
you can use for this, then you will need to add printfs, etc. If you've
got a JVMDI compatible VM, then you should be able to use the remote debugging
support in Eclipse to help you.
The most obvious places where there could be problems are:
- differences in expected arguments/return values between HP-UX Motif and,
the other Motifs.
- new endian problems which we haven't seen yet (although this would be
somewhat odd, since we do run on at least one big-endian platform)
- type size differences
- type layout differences
If, for example, you find a place where a bogus argument is being passed
to one of the natives, then you need to trace back through the code to
find out where it was created.
Really, there's not a lot more I can say though, You actually have the
best possible situation you could expect to have when porting. You have
two very small examples which should be doing the same thing but aren't.
You're just going to have to work through them.
I wish I could be more helpful,
McQ.