java-gnome-hackers

[java-gnome-hackers] gnome.UIInfo array out of bound.

[Mark H. <mh...@ti...>]

Hi, 
  Whenever trying to use the UIInfo object, I get the following
exception:
java.lang.ArrayIndexOutOfBoundsException
	at org.gnu.gnome.UIInfo.setPixmapInfo(UIInfo.java:native)
	at org.gnu.gnome.UIInfo.<init>(UIInfo.java:142)
	at org.gnu.gnome.UIInfo.newItem(UIInfo.java:441)
	at app.AppExample.buildMyMenus(AppExample.java:59)
	at app.AppExample.<init>(AppExample.java:43)
	at app.AppExample.main(AppExample.java:165)
This is even done in src/examples/gnome/app/AppExample.java

Would it be possible for someone to fix this please (I'm guessing the
person who wrote it would be able to do it far quicker than anyone
else).  

Also:
I've just been trying a number of the other gnome example apps. These
often seem to segfault after a while (sometimes when you click on a
widget, but not always). Nothing is written to the console. Does
everyone else encounter this?
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] gnome.UIInfo array out of bound.

[Tom B. <Tom...@Su...>]

Hi Mark,

The AppExample works for me using either Sun's 1.4.1 or gcj, but both
runtimes report four 'uiinfo->widget != NULL' assertion failures (so the
problem is most likely in our code).  Sun's 1.3.1_03 segv's however,
which is weird.  What VM and version do you use?

I don't know the UIInfo code, but a quick review shows that it's sloppy
about byte versus char arrays with its string parameters.  That's
understandable because in ASCII byte and char arrays are often swapped
in C, but in Java (and outside the USA) they are very different types
(String.getBytes can return ugly results with localized strings).  Your
exception is thrown when a String.getBytes() call is passed to an
overloaded method that takes either byte or char arrays, suggesting that
just cleaning up the char/byte array handling may fix your problem as a
side-effect.

I think that all the byte array methods should be replaced with char
arrays until the actual native GTK or GNOME call is made.  In Java, char
arrays should always be used with characters, while byte arrays should
only be used for raw data.  If we adopt this policy now, we probably
won't be broken by future internationalization fixes in GTK and GNOME.

If you'd rather I clean up UIInfo, let me know.

Tom

P.S.  There's never a need to call either "new String()" or "new
String(<string>)", since strings are immutable.  If you need an empty
string, just use '""'; since all constant strings are interned, there is
only one instance of it is shared by the whole runtime.

On Sat, 2002-12-21 at 04:01, Mark Howard wrote:
> Hi, 
>   Whenever trying to use the UIInfo object, I get the following
> exception:
> java.lang.ArrayIndexOutOfBoundsException
> 	at org.gnu.gnome.UIInfo.setPixmapInfo(UIInfo.java:native)
> 	at org.gnu.gnome.UIInfo.<init>(UIInfo.java:142)
> 	at org.gnu.gnome.UIInfo.newItem(UIInfo.java:441)
> 	at app.AppExample.buildMyMenus(AppExample.java:59)
> 	at app.AppExample.<init>(AppExample.java:43)
> 	at app.AppExample.main(AppExample.java:165)
> This is even done in src/examples/gnome/app/AppExample.java
> 
> Would it be possible for someone to fix this please (I'm guessing the
> person who wrote it would be able to do it far quicker than anyone
> else).  
> 
> Also:
> I've just been trying a number of the other gnome example apps. These
> often seem to segfault after a while (sometimes when you click on a
> widget, but not always). Nothing is written to the console. Does
> everyone else encounter this?
-- 
Tom Ball <Tom...@Su...>

Re: [java-gnome-hackers] gnome.UIInfo array out of bound.

[Mark H. <mh...@ti...>]

On Mon, 2002-12-23 at 19:04, Tom Ball wrote:
> Hi Mark,
Hi Tom,

> which is weird.  What VM and version do you use?
At the moment kaffe 1.0.7. Blackdown have not yet released 1.4.1 for
Debian; earlier releases do not work with the latest libc (they depend
on undocumented libc calls, which have now been removed)

> just cleaning up the char/byte array handling may fix your problem as a
> side-effect.
excellent. 

> I think that all the byte array methods should be replaced with char
> arrays until the actual native GTK or GNOME call is made.  In Java, char
> arrays should always be used with characters, while byte arrays should
> only be used for raw data.  If we adopt this policy now, we probably
> won't be broken by future internationalization fixes in GTK and GNOME.
Does this mean that the automatically generated code would have been
better using char arrays also? or does it just affect the custom written
code. 

> If you'd rather I clean up UIInfo, let me know.
If you have time, this would be great, thanks. 

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

[java-gnome-hackers] jcharArray, jbyteArray, jstring

[Mark H. <mh...@ti...>]

Hi,
  I've been trying some of the other applications again and coming into
yet more problems which I assume to be related to passing byte arrays.
I'm not entirely sure why I'm encountering them and noone else is - I am
just using normal english and even the same source files in some cases.
I guess it must be a difference between kaffe and java.
The latest methods I've found problems with are for new Gtk Labels and
Frames. 
This is all autogenerated code:
JNIEXPORT jint JNICALL Java_org_gnu_gtk_Label_gtk_1label_1new (JNIEnv
*env, jclass cls, jbyteArray str) 
{
  jint str_len = (*env)->GetArrayLength(env, str);
  gchar* str_g = (gchar*)g_malloc(str_len + 1);
  (*env)->GetByteArrayRegion(env, str, 0, str_len, (jbyte*)str_g);
  str_g[str_len] = 0;
  {
      return (jint)gtk_label_new (str_g);
  }
}

I've found that changing it to this fixes the problems (for me at least)
JNIEXPORT jint JNICALL Java_org_gnu_gtk_Label_gtk_1label_1new (JNIEnv
*env, jclass cls, jstring str) 
{
  const  gchar *str_g = (*env)->GetStringUTFChars(env, str, 0);
  {
      return (jint)gtk_label_new (str_g);
  }
}
Is this the best way to handle it?


-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] gnome.UIInfo array out of bound.

[Mark H. <mh...@ti...>]

> If you'd rather I clean up UIInfo, let me know.
Thanks for your efforts Tom.

It seems that kaffe's GetByteArrayRegion throws an exception if it has
nothing to do. To fix this, I've had to add an additional test:

if (label_len != 0 ) (*env)->GetByteArrayRegion(env, label, 0,
label_len, (jbyte*)label_g);

With this, the example will then be displayed, but unfortunately it
takes very little effort and there will be a segfault, with no output on
the console. I guess we still have a lot of work to do...

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] gnome.UIInfo array out of bound.

[Tom B. <Tom...@Su...>]

On Mon, 2002-12-23 at 13:36, Mark Howard wrote:
> > I think that all the byte array methods should be replaced with char
> > arrays until the actual native GTK or GNOME call is made.  In Java, char
> > arrays should always be used with characters, while byte arrays should
> > only be used for raw data.  If we adopt this policy now, we probably
> > won't be broken by future internationalization fixes in GTK and GNOME.
> Does this mean that the automatically generated code would have been
> better using char arrays also? or does it just affect the custom written
> code. 

I don't have a strong opinion, unless that code is part of our public or
protected API, then yes, string or char array parameters should use Java
char arrays.  If the API isn't affected, then converting to a byte array
in Java may make sense.  

In general, I'm looking to minimize the native code I work on and move
what functionality I can into Java.  That's not because I'm a Java
bigot, but because maintaining the code is easier since more bugs are
caught by the compiler and runtime.  This is especially true for native
code that makes unnecessary upcalls into the VM, since upcalls are a lot
slower than downcalls.  

Tom

Re: [java-gnome-hackers] gnome.UIInfo array out of bound.

[Tom B. <Tom...@Su...>]

On Thu, 2002-12-26 at 08:09, Mark Howard wrote:
> It seems that kaffe's GetByteArrayRegion throws an exception if it has
> nothing to do. To fix this, I've had to add an additional test:
> 
> if (label_len != 0 ) (*env)->GetByteArrayRegion(env, label, 0,
> label_len, (jbyte*)label_g);
> 
> With this, the example will then be displayed, but unfortunately it
> takes very little effort and there will be a segfault, with no output on
> the console. I guess we still have a lot of work to do...

Perhaps Kaffe needs to be fixed instead, although it's no problem for us
to check for zero length arrays before fetching them (it's probably
faster, too).  

As for chars versus bytes, UIInfo was using char arrays to store byte
array information (xpm graphic data).  This usually worked because
graphic data tends to be word aligned, but its not very safe.  Since GTK
still uses 8-bit chars, I left everything string-related as byte arrays
when it gets close to a native call.  

Tom

Re: [java-gnome-hackers] jcharArray, jbyteArray, jstring

[Tom B. <Tom...@Su...>]

On Thu, 2002-12-26 at 06:54, Mark Howard wrote:
> I've found that changing it to this fixes the problems (for me at least)
> JNIEXPORT jint JNICALL Java_org_gnu_gtk_Label_gtk_1label_1new (JNIEnv
> *env, jclass cls, jstring str) 
> {
>   const  gchar *str_g = (*env)->GetStringUTFChars(env, str, 0);
>   {
>       return (jint)gtk_label_new (str_g);
>   }
> }
> Is this the best way to handle it?

This approach makes the most sense, as GetStringUTFChars should hide any
encoding issues both for US English and other locales, and the less we
have to deal directly with I18N issues, the better.  Let the runtime do
it for us!

Tom