Re: [platform-swt-dev] Running ControlExample exampleprogramfailsunder

[Sridhar Bidigalu <sridhar@xxxxxxx>]

It works. Thanks!

-Sri

Carolyn_MacLeod@xxxxxxx wrote:

> Sridhar,
> We removed the call to XInitThreads and replaced it with our own thread
> locking mechanism.
> I believe we did this in about the middle of February.
> We did it because we had an unbelievable number of problems with
> XInitThreads: hangs in drag & drop, printing, and using the IME.
> Please try the latest drop of eclipse (I am currently running 20020305,
> and it is basically fine - only a few unimportant annoyances <g>).
> Let us know if your polygon draws using the latest SWT code.
> Carolyn
>
> Sridhar Bidigalu <sridhar@xxxxxxx>
> Sent by: platform-swt-dev-admin@xxxxxxxxxxx
> 03/08/2002 09:43 AM
> Please respond to platform-swt-dev
>
>
>         To:     platform-swt-dev@xxxxxxxxxxx
>         cc:
>         Subject:        Re: [platform-swt-dev] Running ControlExample
> exampleprogramfailsunderHP-UX
>
>
> Guys,
> 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.
> Does this mean I can take out calling XInitThreads? and everything should
> work fine. Can anyone tell why it use to fail calling XinitThreads?
> Thanks
> -Sri
>
> Mike_Wilson@xxxxxxx wrote:
>
> > 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.
>
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev