You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2006/11/23 18:31:57 UTC
[classlib][awt] Test failure
It looks like the following code (taken from [1]) doesn't allow for a
function address not being found.
int (* p_nbridge_XmuLookupStandardColormap) (void *, int, long, int,
long, int, int) = NULL;
JNIEXPORT jint JNICALL
Java_org_apache_harmony_awt_nativebridge_linux_X11_XmuLookupStandardColormap(
JNIEnv *env, jobject self, jlong dpy, jint screen, jlong visualid, jint
depth, jlong property, jint replace, jint retain) {
if (p_nbridge_XmuLookupStandardColormap == NULL) {
p_nbridge_XmuLookupStandardColormap = (int (*) (void *, int,
long, int, long, int, int)) FindFunction(libXmu,
"XmuLookupStandardColormap");
}
return (jint) (* p_nbridge_XmuLookupStandardColormap)((void *) dpy,
(int) screen, (long) visualid, (int) depth, (long) property, (int)
replace, (int) retain);
}
which I'm guessing is the cause of the recurrent build failure on the
build machine (latest classlib + IBM VM) ...
> [exec] [junit] Type=Segmentation error vmState=0x00040000
> [exec] [junit] J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> [exec] [junit] Handler1=402504A4 Handler2=401FD343 InaccessibleAddress=00000000
> [exec] [junit] EDI=0816DA90 ESI=0000001B EAX=BB501CA4 EBX=BB501B38
> [exec] [junit] ECX=00000000 EDX=081C4C18
> [exec] [junit] EIP=00000000 ES=0000007B DS=C010007B ESP=BFFFD538
> [exec] [junit] EFlags=00010282 CS=00000073 SS=0000007B EBP=BFFFD584
> [exec] [junit] Target=2_30_20060727_07300_lHdSMR (Linux 2.6.8-3-686-smp)
> [exec] [junit] CPU=x86 (8 logical CPUs) (0xdcc94000 RAM)
<snip>
> [exec] [junit] Thread: main (priority 5) (LOCATION OF ERROR)
> [exec] [junit] NATIVE org/apache/harmony/awt/nativebridge/linux/X11.XmuLookupStandardColormap(JIJIJII)I
> [exec] [junit] 00000080 org/apache/harmony/awt/gl/linux/XGraphicsConfiguration.obtainRGBColorMap()J
> [exec] [junit] 00000015 org/apache/harmony/awt/gl/linux/XGraphicsConfiguration.<init>(Lorg/apache/harmony/awt/gl/linux/XGraphicsDevice;Lorg/apache/harmony/awt/nativebridge/linux/X11$XVisualInfo;)V
> [exec] [junit] 000000a5 org/apache/harmony/awt/gl/linux/XGraphicsDevice.createConfigs()V
> [exec] [junit] 00000008 org/apache/harmony/awt/gl/linux/XGraphicsDevice.getConfigs()[Lorg/apache/harmony/awt/gl/linux/XGraphicsConfiguration;
> [exec] [junit] 00000001 org/apache/harmony/awt/gl/linux/XGraphicsDevice.getDefaultConfiguration()Ljava/awt/GraphicsConfiguration;
> [exec] [junit] 0000000f java/awt/Window.getGraphicsConfiguration(Ljava/awt/GraphicsConfiguration;)Ljava/awt/GraphicsConfiguration;
> [exec] [junit] 0000007a java/awt/Window.<init>(Ljava/awt/Window;Ljava/awt/GraphicsConfiguration;)V
> [exec] [junit] 00000003 java/awt/Frame.<init>(Ljava/lang/String;Ljava/awt/GraphicsConfiguration;)V
> [exec] [junit] 00000003 java/awt/Frame.<init>(Ljava/lang/String;)V
> [exec] [junit] 00000003 java/awt/Frame.<init>()V
> [exec] [junit] 00000009 java/awt/Graphics2DTest.setUp()V
Not sure what has changed to cause this failure. The file [1] says
/* DO NOT EDIT THIS FILE - it is based on X11 headers and was
autogenerated by nativebridge tool */
so I'm guessing I can't fix it up there. suggestions?
[1]
http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/awt/src/main/native/x11wrapper/linux/org_apache_harmony_awt_nativebridge_linux_X11.cpp?revision=476395&view=markup
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][awt] Test failure
Posted by Oleg Khaschansky <ol...@gmail.com>.
> I don't know at this level if it is survivable or not. The native
> contract is to call that function, if I can't then I'll just throw an
> exception. If it is handled as survivable in the Java code then fine,
> otherwise it will cause a sane termination.
It is survivable, in this case it's possible to proceed to this code
(see XGraphicsConfiguration.java):
long cmap = x11.XCreateColormap(
dev.display,
rootWindow,
vis.lock(),
X11Defs.AllocNone
);
We need to wrap the xmu call into try/catch and set the status
variable to zero in the catch block. I can make a patch for
XGraphicsConfiguration.
On 11/27/06, Tim Ellison <t....@gmail.com> wrote:
> Geir Magnusson Jr. wrote:
> > Tim Ellison wrote:
> >> Oleg Khaschansky wrote:
> >>> Do you suggest to introduce the error handling for all the wrappers or
> >>> only for this one? If for all, do you think if it will affect the
> >>> performance?
> >>
> >> I was thinking of something like this. In the non-error case it would
> >> add an additional NULL check as the function address is being cached,
> >> and no additional overhead after the cache has been populated.
> >>
> >> The actual exception thrown is open to debate.\
> >
> > :)
> >
> > I don't understand the context - in the event of this fault, is it time
> > to simply shut down? Or is this survivable? My understanding is that
> > you just don't want to see a GPF.
>
> I don't know at this level if it is survivable or not. The native
> contract is to call that function, if I can't then I'll just throw an
> exception. If it is handled as survivable in the Java code then fine,
> otherwise it will cause a sane termination.
>
> > Either way, how about a hint - like "missing libxmu" or similar?
>
> I don't know the cause, so the exception will just describe the effect.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [classlib][awt] Test failure
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> Tim Ellison wrote:
>> Oleg Khaschansky wrote:
>>> Do you suggest to introduce the error handling for all the wrappers or
>>> only for this one? If for all, do you think if it will affect the
>>> performance?
>>
>> I was thinking of something like this. In the non-error case it would
>> add an additional NULL check as the function address is being cached,
>> and no additional overhead after the cache has been populated.
>>
>> The actual exception thrown is open to debate.\
>
> :)
>
> I don't understand the context - in the event of this fault, is it time
> to simply shut down? Or is this survivable? My understanding is that
> you just don't want to see a GPF.
I don't know at this level if it is survivable or not. The native
contract is to call that function, if I can't then I'll just throw an
exception. If it is handled as survivable in the Java code then fine,
otherwise it will cause a sane termination.
> Either way, how about a hint - like "missing libxmu" or similar?
I don't know the cause, so the exception will just describe the effect.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][awt] Test failure
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> Oleg Khaschansky wrote:
>> Do you suggest to introduce the error handling for all the wrappers or
>> only for this one? If for all, do you think if it will affect the
>> performance?
>
> I was thinking of something like this. In the non-error case it would
> add an additional NULL check as the function address is being cached,
> and no additional overhead after the cache has been populated.
>
> The actual exception thrown is open to debate.\
:)
I don't understand the context - in the event of this fault, is it time
to simply shut down? Or is this survivable? My understanding is that
you just don't want to see a GPF.
Either way, how about a hint - like "missing libxmu" or similar?
geir
>
> Index:
> src/main/native/x11wrapper/linux/org_apache_harmony_awt_nativebridge_linux_X11.cpp
> ===================================================================
> ---
> src/main/native/x11wrapper/linux/org_apache_harmony_awt_nativebridge_linux_X11.cpp
> (revision 478891)
> +++
> src/main/native/x11wrapper/linux/org_apache_harmony_awt_nativebridge_linux_X11.cpp
> (working copy)
> @@ -23,6 +23,7 @@
>
> #include "org_apache_harmony_awt_nativebridge_linux_X11.h"
> #include "org_apache_harmony_awt_nativebridge_linux_ErrorHandler.h"
> +#include "exceptions.h"
>
> static libHandler libX11;
> static libHandler libXmu;
> @@ -575,6 +576,10 @@
> JNIEXPORT jint JNICALL
> Java_org_apache_harmony_awt_nativebridge_linux_X11_XmuLookupStandardColormap(
> JNIEnv *env, jobject self, jlong dpy, jint screen, jlong visualid, jint
> depth, jlong property, jint replace, jint retain) {
> if (p_nbridge_XmuLookupStandardColormap == NULL) {
> p_nbridge_XmuLookupStandardColormap = (int (*) (void *, int,
> long, int, long, int, int)) FindFunction(libXmu,
> "XmuLookupStandardColormap");
> + if (p_nbridge_XmuLookupStandardColormap == NULL) {
> + throwNewExceptionByName(env,
> "java/lang/UnsupportedOperationException", "Function not found");
> + return 0;
> + }
> }
> return (jint) (* p_nbridge_XmuLookupStandardColormap)((void *) dpy,
> (int) screen, (long) visualid, (int) depth, (long) property, (int)
> replace, (int) retain);
> }
>
>
> What do you think?
>
> Regards,
> Tim
>
Re: [classlib][awt] Test failure
Posted by Oleg Khaschansky <ol...@gmail.com>.
> What do you think?
I don't like the idea of changing these wrappers manually. It's
possible to loose these changes if somebody will regenerate them
someday. But it is ok as a temporary solution.
On 11/24/06, Tim Ellison <t....@gmail.com> wrote:
> Oleg Khaschansky wrote:
> > Do you suggest to introduce the error handling for all the wrappers or
> > only for this one? If for all, do you think if it will affect the
> > performance?
>
> I was thinking of something like this. In the non-error case it would
> add an additional NULL check as the function address is being cached,
> and no additional overhead after the cache has been populated.
>
> The actual exception thrown is open to debate.
>
> Index:
> src/main/native/x11wrapper/linux/org_apache_harmony_awt_nativebridge_linux_X11.cpp
> ===================================================================
> ---
> src/main/native/x11wrapper/linux/org_apache_harmony_awt_nativebridge_linux_X11.cpp
> (revision 478891)
> +++
> src/main/native/x11wrapper/linux/org_apache_harmony_awt_nativebridge_linux_X11.cpp
> (working copy)
> @@ -23,6 +23,7 @@
>
> #include "org_apache_harmony_awt_nativebridge_linux_X11.h"
> #include "org_apache_harmony_awt_nativebridge_linux_ErrorHandler.h"
> +#include "exceptions.h"
>
> static libHandler libX11;
> static libHandler libXmu;
> @@ -575,6 +576,10 @@
> JNIEXPORT jint JNICALL
> Java_org_apache_harmony_awt_nativebridge_linux_X11_XmuLookupStandardColormap(
> JNIEnv *env, jobject self, jlong dpy, jint screen, jlong visualid, jint
> depth, jlong property, jint replace, jint retain) {
> if (p_nbridge_XmuLookupStandardColormap == NULL) {
> p_nbridge_XmuLookupStandardColormap = (int (*) (void *, int,
> long, int, long, int, int)) FindFunction(libXmu,
> "XmuLookupStandardColormap");
> + if (p_nbridge_XmuLookupStandardColormap == NULL) {
> + throwNewExceptionByName(env,
> "java/lang/UnsupportedOperationException", "Function not found");
> + return 0;
> + }
> }
> return (jint) (* p_nbridge_XmuLookupStandardColormap)((void *) dpy,
> (int) screen, (long) visualid, (int) depth, (long) property, (int)
> replace, (int) retain);
> }
>
>
> What do you think?
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [classlib][awt] Test failure
Posted by Tim Ellison <t....@gmail.com>.
Oleg Khaschansky wrote:
> Do you suggest to introduce the error handling for all the wrappers or
> only for this one? If for all, do you think if it will affect the
> performance?
I was thinking of something like this. In the non-error case it would
add an additional NULL check as the function address is being cached,
and no additional overhead after the cache has been populated.
The actual exception thrown is open to debate.
Index:
src/main/native/x11wrapper/linux/org_apache_harmony_awt_nativebridge_linux_X11.cpp
===================================================================
---
src/main/native/x11wrapper/linux/org_apache_harmony_awt_nativebridge_linux_X11.cpp
(revision 478891)
+++
src/main/native/x11wrapper/linux/org_apache_harmony_awt_nativebridge_linux_X11.cpp
(working copy)
@@ -23,6 +23,7 @@
#include "org_apache_harmony_awt_nativebridge_linux_X11.h"
#include "org_apache_harmony_awt_nativebridge_linux_ErrorHandler.h"
+#include "exceptions.h"
static libHandler libX11;
static libHandler libXmu;
@@ -575,6 +576,10 @@
JNIEXPORT jint JNICALL
Java_org_apache_harmony_awt_nativebridge_linux_X11_XmuLookupStandardColormap(
JNIEnv *env, jobject self, jlong dpy, jint screen, jlong visualid, jint
depth, jlong property, jint replace, jint retain) {
if (p_nbridge_XmuLookupStandardColormap == NULL) {
p_nbridge_XmuLookupStandardColormap = (int (*) (void *, int,
long, int, long, int, int)) FindFunction(libXmu,
"XmuLookupStandardColormap");
+ if (p_nbridge_XmuLookupStandardColormap == NULL) {
+ throwNewExceptionByName(env,
"java/lang/UnsupportedOperationException", "Function not found");
+ return 0;
+ }
}
return (jint) (* p_nbridge_XmuLookupStandardColormap)((void *) dpy,
(int) screen, (long) visualid, (int) depth, (long) property, (int)
replace, (int) retain);
}
What do you think?
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][awt] Test failure
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> Oleg Khaschansky wrote:
>> Do you suggest to introduce the error handling for all the wrappers or
>> only for this one? If for all, do you think if it will affect the
>> performance?
>
> That's a moot question ... GPF-ing is unacceptable known behavior.
>
>> The only place is that native code :) I need some time to find out if
>> it is possible to get the tool which generated it to harmony.
>
> That's ok, I was just respecting the source file comment. Since we have
> what we have in harmony I'll edit it directly.
And nuke or clarify the comment...
geir
Re: [classlib][awt] Test failure
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Oleg Khaschansky wrote:
>> That's a moot question ... GPF-ing is unacceptable known behavior.
> I am not sure if we should guarantee the correct behavior in case of
> invalid system configuration, missing libraries, etc. Should we?
That's not what Tim said - he said that GPF-ing (I almost wrote
"GPL-ing") is unacceptable, and we can handle that error in ways better
than just falling over dead.
geir
>
> On 11/24/06, Tim Ellison <t....@gmail.com> wrote:
>> Oleg Khaschansky wrote:
>> > Do you suggest to introduce the error handling for all the wrappers or
>> > only for this one? If for all, do you think if it will affect the
>> > performance?
>>
>> That's a moot question ... GPF-ing is unacceptable known behavior.
>>
>> > The only place is that native code :) I need some time to find out if
>> > it is possible to get the tool which generated it to harmony.
>>
>> That's ok, I was just respecting the source file comment. Since we have
>> what we have in harmony I'll edit it directly.
>>
>> Regards,
>> Tim
>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
Re: [classlib][awt] Test failure
Posted by Mark Hindess <ma...@googlemail.com>.
On 27 November 2006 at 14:30, "Oleg Khaschansky" <ol...@gmail.com> wrote:
> > That's a moot question ... GPF-ing is unacceptable known behavior.
> I am not sure if we should guarantee the correct behavior in case of
> invalid system configuration, missing libraries, etc. Should we?
I don't think anyone is expecting correct behaviour in the case of
errors. That would be pretty impressive. ;-)
In this case, however, the configuration is actually valid/normal and
I think users could reasonably expect the code to run correctly.
I do think we must try to raise reasonable errors rather than just
SIGSEGV. Just think how much more quickly this issue would hav
been resolved if a helpful error message was returned when I first
mentioned this back in early October.
Regards,
Mark.
> On 11/24/06, Tim Ellison <t....@gmail.com> wrote:
> > Oleg Khaschansky wrote:
> > > Do you suggest to introduce the error handling for all the wrappers or
> > > only for this one? If for all, do you think if it will affect the
> > > performance?
> >
> > That's a moot question ... GPF-ing is unacceptable known behavior.
> >
> > > The only place is that native code :) I need some time to find out if
> > > it is possible to get the tool which generated it to harmony.
> >
> > That's ok, I was just respecting the source file comment. Since we have
> > what we have in harmony I'll edit it directly.
> >
> > Regards,
> > Tim
> >
> > --
> >
> > Tim Ellison (t.p.ellison@gmail.com)
> > IBM Java technology centre, UK.
> >
>
Re: [classlib][awt] Test failure
Posted by Mark Hindess <ma...@googlemail.com>.
On 27 November 2006 at 14:30, "Oleg Khaschansky" <ol...@gmail.com> wrote:
> > That's a moot question ... GPF-ing is unacceptable known behavior.
> I am not sure if we should guarantee the correct behavior in case of
> invalid system configuration, missing libraries, etc. Should we?
I don't think we should guarantee correct behaviour, but:
1) The system configuration in this case is actually valid/normal
2) We can and should raise a more appropriate error message[0]
Regards,
Mark.
[0] Just think how much more quickly this issue would have been resolved
if even a vaguely helpful error was returned when I first mentioned this
back in early October.
> On 11/24/06, Tim Ellison <t....@gmail.com> wrote:
> > Oleg Khaschansky wrote:
> > > Do you suggest to introduce the error handling for all the wrappers or
> > > only for this one? If for all, do you think if it will affect the
> > > performance?
> >
> > That's a moot question ... GPF-ing is unacceptable known behavior.
> >
> > > The only place is that native code :) I need some time to find out if
> > > it is possible to get the tool which generated it to harmony.
> >
> > That's ok, I was just respecting the source file comment. Since we have
> > what we have in harmony I'll edit it directly.
> >
> > Regards,
> > Tim
> >
> > --
> >
> > Tim Ellison (t.p.ellison@gmail.com)
> > IBM Java technology centre, UK.
> >
>
Re: [classlib][awt] Test failure
Posted by Oleg Khaschansky <ol...@gmail.com>.
> That's a moot question ... GPF-ing is unacceptable known behavior.
I am not sure if we should guarantee the correct behavior in case of
invalid system configuration, missing libraries, etc. Should we?
On 11/24/06, Tim Ellison <t....@gmail.com> wrote:
> Oleg Khaschansky wrote:
> > Do you suggest to introduce the error handling for all the wrappers or
> > only for this one? If for all, do you think if it will affect the
> > performance?
>
> That's a moot question ... GPF-ing is unacceptable known behavior.
>
> > The only place is that native code :) I need some time to find out if
> > it is possible to get the tool which generated it to harmony.
>
> That's ok, I was just respecting the source file comment. Since we have
> what we have in harmony I'll edit it directly.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [classlib][awt] Test failure
Posted by Tim Ellison <t....@gmail.com>.
Oleg Khaschansky wrote:
> Do you suggest to introduce the error handling for all the wrappers or
> only for this one? If for all, do you think if it will affect the
> performance?
That's a moot question ... GPF-ing is unacceptable known behavior.
> The only place is that native code :) I need some time to find out if
> it is possible to get the tool which generated it to harmony.
That's ok, I was just respecting the source file comment. Since we have
what we have in harmony I'll edit it directly.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][awt] Test failure
Posted by Oleg Khaschansky <ol...@gmail.com>.
Do you suggest to introduce the error handling for all the wrappers or
only for this one? If for all, do you think if it will affect the
performance?
The only place is that native code :) I need some time to find out if
it is possible to get the tool which generated it to harmony.
On 11/24/06, Tim Ellison <t....@gmail.com> wrote:
> Oleg Khaschansky wrote:
> > I'd suggest to install libxmu.
>
> Surely we can do better than GPF in such circumstances :-)
>
> Where should I modify the code to return gracefully from the native if
> the function is not found (bearing in mind the warning in the source file).
>
> Regards,
> Tim
>
> > On 11/23/06, Tim Ellison <t....@gmail.com> wrote:
> >> It looks like the following code (taken from [1]) doesn't allow for a
> >> function address not being found.
> >>
> >> int (* p_nbridge_XmuLookupStandardColormap) (void *, int, long, int,
> >> long, int, int) = NULL;
> >>
> >> JNIEXPORT jint JNICALL
> >> Java_org_apache_harmony_awt_nativebridge_linux_X11_XmuLookupStandardColormap(
> >>
> >> JNIEnv *env, jobject self, jlong dpy, jint screen, jlong visualid, jint
> >> depth, jlong property, jint replace, jint retain) {
> >> if (p_nbridge_XmuLookupStandardColormap == NULL) {
> >> p_nbridge_XmuLookupStandardColormap = (int (*) (void *, int,
> >> long, int, long, int, int)) FindFunction(libXmu,
> >> "XmuLookupStandardColormap");
> >> }
> >> return (jint) (* p_nbridge_XmuLookupStandardColormap)((void *) dpy,
> >> (int) screen, (long) visualid, (int) depth, (long) property, (int)
> >> replace, (int) retain);
> >> }
> >>
> >>
> >> which I'm guessing is the cause of the recurrent build failure on the
> >> build machine (latest classlib + IBM VM) ...
> >>
> >>
> >> > [exec] [junit] Type=Segmentation error vmState=0x00040000
> >> > [exec] [junit] J9Generic_Signal_Number=00000004
> >> Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> >> > [exec] [junit] Handler1=402504A4 Handler2=401FD343
> >> InaccessibleAddress=00000000
> >> > [exec] [junit] EDI=0816DA90 ESI=0000001B EAX=BB501CA4
> >> EBX=BB501B38
> >> > [exec] [junit] ECX=00000000 EDX=081C4C18
> >> > [exec] [junit] EIP=00000000 ES=0000007B DS=C010007B
> >> ESP=BFFFD538
> >> > [exec] [junit] EFlags=00010282 CS=00000073 SS=0000007B
> >> EBP=BFFFD584
> >> > [exec] [junit] Target=2_30_20060727_07300_lHdSMR (Linux
> >> 2.6.8-3-686-smp)
> >> > [exec] [junit] CPU=x86 (8 logical CPUs) (0xdcc94000 RAM)
> >>
> >> <snip>
> >>
> >> > [exec] [junit] Thread: main (priority 5) (LOCATION OF ERROR)
> >> > [exec] [junit] NATIVE
> >> org/apache/harmony/awt/nativebridge/linux/X11.XmuLookupStandardColormap(JIJIJII)I
> >>
> >> > [exec] [junit] 00000080
> >> org/apache/harmony/awt/gl/linux/XGraphicsConfiguration.obtainRGBColorMap()J
> >>
> >> > [exec] [junit] 00000015
> >> org/apache/harmony/awt/gl/linux/XGraphicsConfiguration.<init>(Lorg/apache/harmony/awt/gl/linux/XGraphicsDevice;Lorg/apache/harmony/awt/nativebridge/linux/X11$XVisualInfo;)V
> >>
> >> > [exec] [junit] 000000a5
> >> org/apache/harmony/awt/gl/linux/XGraphicsDevice.createConfigs()V
> >> > [exec] [junit] 00000008
> >> org/apache/harmony/awt/gl/linux/XGraphicsDevice.getConfigs()[Lorg/apache/harmony/awt/gl/linux/XGraphicsConfiguration;
> >>
> >> > [exec] [junit] 00000001
> >> org/apache/harmony/awt/gl/linux/XGraphicsDevice.getDefaultConfiguration()Ljava/awt/GraphicsConfiguration;
> >>
> >> > [exec] [junit] 0000000f
> >> java/awt/Window.getGraphicsConfiguration(Ljava/awt/GraphicsConfiguration;)Ljava/awt/GraphicsConfiguration;
> >>
> >> > [exec] [junit] 0000007a
> >> java/awt/Window.<init>(Ljava/awt/Window;Ljava/awt/GraphicsConfiguration;)V
> >>
> >> > [exec] [junit] 00000003
> >> java/awt/Frame.<init>(Ljava/lang/String;Ljava/awt/GraphicsConfiguration;)V
> >>
> >> > [exec] [junit] 00000003
> >> java/awt/Frame.<init>(Ljava/lang/String;)V
> >> > [exec] [junit] 00000003 java/awt/Frame.<init>()V
> >> > [exec] [junit] 00000009 java/awt/Graphics2DTest.setUp()V
> >>
> >>
> >> Not sure what has changed to cause this failure. The file [1] says
> >> /* DO NOT EDIT THIS FILE - it is based on X11 headers and was
> >> autogenerated by nativebridge tool */
> >>
> >> so I'm guessing I can't fix it up there. suggestions?
> >>
> >>
> >> [1]
> >> http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/awt/src/main/native/x11wrapper/linux/org_apache_harmony_awt_nativebridge_linux_X11.cpp?revision=476395&view=markup
> >>
> >>
> >> Regards,
> >> Tim
> >>
> >> --
> >>
> >> Tim Ellison (t.p.ellison@gmail.com)
> >> IBM Java technology centre, UK.
> >>
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [classlib][awt] Test failure
Posted by Tim Ellison <t....@gmail.com>.
Oleg Khaschansky wrote:
> I'd suggest to install libxmu.
Surely we can do better than GPF in such circumstances :-)
Where should I modify the code to return gracefully from the native if
the function is not found (bearing in mind the warning in the source file).
Regards,
Tim
> On 11/23/06, Tim Ellison <t....@gmail.com> wrote:
>> It looks like the following code (taken from [1]) doesn't allow for a
>> function address not being found.
>>
>> int (* p_nbridge_XmuLookupStandardColormap) (void *, int, long, int,
>> long, int, int) = NULL;
>>
>> JNIEXPORT jint JNICALL
>> Java_org_apache_harmony_awt_nativebridge_linux_X11_XmuLookupStandardColormap(
>>
>> JNIEnv *env, jobject self, jlong dpy, jint screen, jlong visualid, jint
>> depth, jlong property, jint replace, jint retain) {
>> if (p_nbridge_XmuLookupStandardColormap == NULL) {
>> p_nbridge_XmuLookupStandardColormap = (int (*) (void *, int,
>> long, int, long, int, int)) FindFunction(libXmu,
>> "XmuLookupStandardColormap");
>> }
>> return (jint) (* p_nbridge_XmuLookupStandardColormap)((void *) dpy,
>> (int) screen, (long) visualid, (int) depth, (long) property, (int)
>> replace, (int) retain);
>> }
>>
>>
>> which I'm guessing is the cause of the recurrent build failure on the
>> build machine (latest classlib + IBM VM) ...
>>
>>
>> > [exec] [junit] Type=Segmentation error vmState=0x00040000
>> > [exec] [junit] J9Generic_Signal_Number=00000004
>> Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
>> > [exec] [junit] Handler1=402504A4 Handler2=401FD343
>> InaccessibleAddress=00000000
>> > [exec] [junit] EDI=0816DA90 ESI=0000001B EAX=BB501CA4
>> EBX=BB501B38
>> > [exec] [junit] ECX=00000000 EDX=081C4C18
>> > [exec] [junit] EIP=00000000 ES=0000007B DS=C010007B
>> ESP=BFFFD538
>> > [exec] [junit] EFlags=00010282 CS=00000073 SS=0000007B
>> EBP=BFFFD584
>> > [exec] [junit] Target=2_30_20060727_07300_lHdSMR (Linux
>> 2.6.8-3-686-smp)
>> > [exec] [junit] CPU=x86 (8 logical CPUs) (0xdcc94000 RAM)
>>
>> <snip>
>>
>> > [exec] [junit] Thread: main (priority 5) (LOCATION OF ERROR)
>> > [exec] [junit] NATIVE
>> org/apache/harmony/awt/nativebridge/linux/X11.XmuLookupStandardColormap(JIJIJII)I
>>
>> > [exec] [junit] 00000080
>> org/apache/harmony/awt/gl/linux/XGraphicsConfiguration.obtainRGBColorMap()J
>>
>> > [exec] [junit] 00000015
>> org/apache/harmony/awt/gl/linux/XGraphicsConfiguration.<init>(Lorg/apache/harmony/awt/gl/linux/XGraphicsDevice;Lorg/apache/harmony/awt/nativebridge/linux/X11$XVisualInfo;)V
>>
>> > [exec] [junit] 000000a5
>> org/apache/harmony/awt/gl/linux/XGraphicsDevice.createConfigs()V
>> > [exec] [junit] 00000008
>> org/apache/harmony/awt/gl/linux/XGraphicsDevice.getConfigs()[Lorg/apache/harmony/awt/gl/linux/XGraphicsConfiguration;
>>
>> > [exec] [junit] 00000001
>> org/apache/harmony/awt/gl/linux/XGraphicsDevice.getDefaultConfiguration()Ljava/awt/GraphicsConfiguration;
>>
>> > [exec] [junit] 0000000f
>> java/awt/Window.getGraphicsConfiguration(Ljava/awt/GraphicsConfiguration;)Ljava/awt/GraphicsConfiguration;
>>
>> > [exec] [junit] 0000007a
>> java/awt/Window.<init>(Ljava/awt/Window;Ljava/awt/GraphicsConfiguration;)V
>>
>> > [exec] [junit] 00000003
>> java/awt/Frame.<init>(Ljava/lang/String;Ljava/awt/GraphicsConfiguration;)V
>>
>> > [exec] [junit] 00000003
>> java/awt/Frame.<init>(Ljava/lang/String;)V
>> > [exec] [junit] 00000003 java/awt/Frame.<init>()V
>> > [exec] [junit] 00000009 java/awt/Graphics2DTest.setUp()V
>>
>>
>> Not sure what has changed to cause this failure. The file [1] says
>> /* DO NOT EDIT THIS FILE - it is based on X11 headers and was
>> autogenerated by nativebridge tool */
>>
>> so I'm guessing I can't fix it up there. suggestions?
>>
>>
>> [1]
>> http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/awt/src/main/native/x11wrapper/linux/org_apache_harmony_awt_nativebridge_linux_X11.cpp?revision=476395&view=markup
>>
>>
>> Regards,
>> Tim
>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][awt] Test failure
Posted by Mark Hindess <ma...@googlemail.com>.
On 24 November 2006 at 18:27, "Oleg Khaschansky" <ol...@gmail.com> wrote:
> I'd suggest to install libxmu.
It is installed. See comment in HARMONY-1979.
-Mark.
> On 11/23/06, Tim Ellison <t....@gmail.com> wrote:
> > It looks like the following code (taken from [1]) doesn't allow for a
> > function address not being found.
> >
> > int (* p_nbridge_XmuLookupStandardColormap) (void *, int, long, int,
> > long, int, int) = NULL;
> >
> > JNIEXPORT jint JNICALL
> > Java_org_apache_harmony_awt_nativebridge_linux_X11_XmuLookupStandardColorma
> p(
> > JNIEnv *env, jobject self, jlong dpy, jint screen, jlong visualid, jint
> > depth, jlong property, jint replace, jint retain) {
> > if (p_nbridge_XmuLookupStandardColormap == NULL) {
> > p_nbridge_XmuLookupStandardColormap = (int (*) (void *, int,
> > long, int, long, int, int)) FindFunction(libXmu,
> > "XmuLookupStandardColormap");
> > }
> > return (jint) (* p_nbridge_XmuLookupStandardColormap)((void *) dpy,
> > (int) screen, (long) visualid, (int) depth, (long) property, (int)
> > replace, (int) retain);
> > }
> >
> >
> > which I'm guessing is the cause of the recurrent build failure on the
> > build machine (latest classlib + IBM VM) ...
> >
> >
> > > [exec] [junit] Type=Segmentation error vmState=0x00040000
> > > [exec] [junit] J9Generic_Signal_Number=00000004 Signal_Number=00
> 00000b Error_Value=00000000 Signal_Code=00000001
> > > [exec] [junit] Handler1=402504A4 Handler2=401FD343 InaccessibleA
> ddress=00000000
> > > [exec] [junit] EDI=0816DA90 ESI=0000001B EAX=BB501CA4 EBX=BB501B
> 38
> > > [exec] [junit] ECX=00000000 EDX=081C4C18
> > > [exec] [junit] EIP=00000000 ES=0000007B DS=C010007B ESP=BFFFD538
> > > [exec] [junit] EFlags=00010282 CS=00000073 SS=0000007B EBP=BFFFD
> 584
> > > [exec] [junit] Target=2_30_20060727_07300_lHdSMR (Linux 2.6.8-3-
> 686-smp)
> > > [exec] [junit] CPU=x86 (8 logical CPUs) (0xdcc94000 RAM)
> >
> > <snip>
> >
> > > [exec] [junit] Thread: main (priority 5) (LOCATION OF ERROR)
> > > [exec] [junit] NATIVE org/apache/harmony/awt/nativebridge/lin
> ux/X11.XmuLookupStandardColormap(JIJIJII)I
> > > [exec] [junit] 00000080 org/apache/harmony/awt/gl/linux/XGraphi
> csConfiguration.obtainRGBColorMap()J
> > > [exec] [junit] 00000015 org/apache/harmony/awt/gl/linux/XGraphi
> csConfiguration.<init>(Lorg/apache/harmony/awt/gl/linux/XGraphicsDevice;Lorg/
> apache/harmony/awt/nativebridge/linux/X11$XVisualInfo;)V
> > > [exec] [junit] 000000a5 org/apache/harmony/awt/gl/linux/XGraphi
> csDevice.createConfigs()V
> > > [exec] [junit] 00000008 org/apache/harmony/awt/gl/linux/XGraphi
> csDevice.getConfigs()[Lorg/apache/harmony/awt/gl/linux/XGraphicsConfiguration
> ;
> > > [exec] [junit] 00000001 org/apache/harmony/awt/gl/linux/XGraphi
> csDevice.getDefaultConfiguration()Ljava/awt/GraphicsConfiguration;
> > > [exec] [junit] 0000000f java/awt/Window.getGraphicsConfiguratio
> n(Ljava/awt/GraphicsConfiguration;)Ljava/awt/GraphicsConfiguration;
> > > [exec] [junit] 0000007a java/awt/Window.<init>(Ljava/awt/Window
> ;Ljava/awt/GraphicsConfiguration;)V
> > > [exec] [junit] 00000003 java/awt/Frame.<init>(Ljava/lang/String
> ;Ljava/awt/GraphicsConfiguration;)V
> > > [exec] [junit] 00000003 java/awt/Frame.<init>(Ljava/lang/String
> ;)V
> > > [exec] [junit] 00000003 java/awt/Frame.<init>()V
> > > [exec] [junit] 00000009 java/awt/Graphics2DTest.setUp()V
> >
> >
> > Not sure what has changed to cause this failure. The file [1] says
> > /* DO NOT EDIT THIS FILE - it is based on X11 headers and was
> > autogenerated by nativebridge tool */
> >
> > so I'm guessing I can't fix it up there. suggestions?
> >
> >
> > [1]
> > http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/awt/sr
> c/main/native/x11wrapper/linux/org_apache_harmony_awt_nativebridge_linux_X11.
> cpp?revision=476395&view=markup
> >
> > Regards,
> > Tim
> >
> > --
> >
> > Tim Ellison (t.p.ellison@gmail.com)
> > IBM Java technology centre, UK.
> >
>
Re: [classlib][awt] Test failure
Posted by Oleg Khaschansky <ol...@gmail.com>.
I'd suggest to install libxmu.
On 11/23/06, Tim Ellison <t....@gmail.com> wrote:
> It looks like the following code (taken from [1]) doesn't allow for a
> function address not being found.
>
> int (* p_nbridge_XmuLookupStandardColormap) (void *, int, long, int,
> long, int, int) = NULL;
>
> JNIEXPORT jint JNICALL
> Java_org_apache_harmony_awt_nativebridge_linux_X11_XmuLookupStandardColormap(
> JNIEnv *env, jobject self, jlong dpy, jint screen, jlong visualid, jint
> depth, jlong property, jint replace, jint retain) {
> if (p_nbridge_XmuLookupStandardColormap == NULL) {
> p_nbridge_XmuLookupStandardColormap = (int (*) (void *, int,
> long, int, long, int, int)) FindFunction(libXmu,
> "XmuLookupStandardColormap");
> }
> return (jint) (* p_nbridge_XmuLookupStandardColormap)((void *) dpy,
> (int) screen, (long) visualid, (int) depth, (long) property, (int)
> replace, (int) retain);
> }
>
>
> which I'm guessing is the cause of the recurrent build failure on the
> build machine (latest classlib + IBM VM) ...
>
>
> > [exec] [junit] Type=Segmentation error vmState=0x00040000
> > [exec] [junit] J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> > [exec] [junit] Handler1=402504A4 Handler2=401FD343 InaccessibleAddress=00000000
> > [exec] [junit] EDI=0816DA90 ESI=0000001B EAX=BB501CA4 EBX=BB501B38
> > [exec] [junit] ECX=00000000 EDX=081C4C18
> > [exec] [junit] EIP=00000000 ES=0000007B DS=C010007B ESP=BFFFD538
> > [exec] [junit] EFlags=00010282 CS=00000073 SS=0000007B EBP=BFFFD584
> > [exec] [junit] Target=2_30_20060727_07300_lHdSMR (Linux 2.6.8-3-686-smp)
> > [exec] [junit] CPU=x86 (8 logical CPUs) (0xdcc94000 RAM)
>
> <snip>
>
> > [exec] [junit] Thread: main (priority 5) (LOCATION OF ERROR)
> > [exec] [junit] NATIVE org/apache/harmony/awt/nativebridge/linux/X11.XmuLookupStandardColormap(JIJIJII)I
> > [exec] [junit] 00000080 org/apache/harmony/awt/gl/linux/XGraphicsConfiguration.obtainRGBColorMap()J
> > [exec] [junit] 00000015 org/apache/harmony/awt/gl/linux/XGraphicsConfiguration.<init>(Lorg/apache/harmony/awt/gl/linux/XGraphicsDevice;Lorg/apache/harmony/awt/nativebridge/linux/X11$XVisualInfo;)V
> > [exec] [junit] 000000a5 org/apache/harmony/awt/gl/linux/XGraphicsDevice.createConfigs()V
> > [exec] [junit] 00000008 org/apache/harmony/awt/gl/linux/XGraphicsDevice.getConfigs()[Lorg/apache/harmony/awt/gl/linux/XGraphicsConfiguration;
> > [exec] [junit] 00000001 org/apache/harmony/awt/gl/linux/XGraphicsDevice.getDefaultConfiguration()Ljava/awt/GraphicsConfiguration;
> > [exec] [junit] 0000000f java/awt/Window.getGraphicsConfiguration(Ljava/awt/GraphicsConfiguration;)Ljava/awt/GraphicsConfiguration;
> > [exec] [junit] 0000007a java/awt/Window.<init>(Ljava/awt/Window;Ljava/awt/GraphicsConfiguration;)V
> > [exec] [junit] 00000003 java/awt/Frame.<init>(Ljava/lang/String;Ljava/awt/GraphicsConfiguration;)V
> > [exec] [junit] 00000003 java/awt/Frame.<init>(Ljava/lang/String;)V
> > [exec] [junit] 00000003 java/awt/Frame.<init>()V
> > [exec] [junit] 00000009 java/awt/Graphics2DTest.setUp()V
>
>
> Not sure what has changed to cause this failure. The file [1] says
> /* DO NOT EDIT THIS FILE - it is based on X11 headers and was
> autogenerated by nativebridge tool */
>
> so I'm guessing I can't fix it up there. suggestions?
>
>
> [1]
> http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/awt/src/main/native/x11wrapper/linux/org_apache_harmony_awt_nativebridge_linux_X11.cpp?revision=476395&view=markup
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [classlib][awt] Test failure
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Did you ever figure out what changed to cause it?
Tim Ellison wrote:
> It looks like the following code (taken from [1]) doesn't allow for a
> function address not being found.
>
> int (* p_nbridge_XmuLookupStandardColormap) (void *, int, long, int,
> long, int, int) = NULL;
>
> JNIEXPORT jint JNICALL
> Java_org_apache_harmony_awt_nativebridge_linux_X11_XmuLookupStandardColormap(
> JNIEnv *env, jobject self, jlong dpy, jint screen, jlong visualid, jint
> depth, jlong property, jint replace, jint retain) {
> if (p_nbridge_XmuLookupStandardColormap == NULL) {
> p_nbridge_XmuLookupStandardColormap = (int (*) (void *, int,
> long, int, long, int, int)) FindFunction(libXmu,
> "XmuLookupStandardColormap");
> }
> return (jint) (* p_nbridge_XmuLookupStandardColormap)((void *) dpy,
> (int) screen, (long) visualid, (int) depth, (long) property, (int)
> replace, (int) retain);
> }
>
>
> which I'm guessing is the cause of the recurrent build failure on the
> build machine (latest classlib + IBM VM) ...
>
>
>> [exec] [junit] Type=Segmentation error vmState=0x00040000
>> [exec] [junit] J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
>> [exec] [junit] Handler1=402504A4 Handler2=401FD343 InaccessibleAddress=00000000
>> [exec] [junit] EDI=0816DA90 ESI=0000001B EAX=BB501CA4 EBX=BB501B38
>> [exec] [junit] ECX=00000000 EDX=081C4C18
>> [exec] [junit] EIP=00000000 ES=0000007B DS=C010007B ESP=BFFFD538
>> [exec] [junit] EFlags=00010282 CS=00000073 SS=0000007B EBP=BFFFD584
>> [exec] [junit] Target=2_30_20060727_07300_lHdSMR (Linux 2.6.8-3-686-smp)
>> [exec] [junit] CPU=x86 (8 logical CPUs) (0xdcc94000 RAM)
>
> <snip>
>
>> [exec] [junit] Thread: main (priority 5) (LOCATION OF ERROR)
>> [exec] [junit] NATIVE org/apache/harmony/awt/nativebridge/linux/X11.XmuLookupStandardColormap(JIJIJII)I
>> [exec] [junit] 00000080 org/apache/harmony/awt/gl/linux/XGraphicsConfiguration.obtainRGBColorMap()J
>> [exec] [junit] 00000015 org/apache/harmony/awt/gl/linux/XGraphicsConfiguration.<init>(Lorg/apache/harmony/awt/gl/linux/XGraphicsDevice;Lorg/apache/harmony/awt/nativebridge/linux/X11$XVisualInfo;)V
>> [exec] [junit] 000000a5 org/apache/harmony/awt/gl/linux/XGraphicsDevice.createConfigs()V
>> [exec] [junit] 00000008 org/apache/harmony/awt/gl/linux/XGraphicsDevice.getConfigs()[Lorg/apache/harmony/awt/gl/linux/XGraphicsConfiguration;
>> [exec] [junit] 00000001 org/apache/harmony/awt/gl/linux/XGraphicsDevice.getDefaultConfiguration()Ljava/awt/GraphicsConfiguration;
>> [exec] [junit] 0000000f java/awt/Window.getGraphicsConfiguration(Ljava/awt/GraphicsConfiguration;)Ljava/awt/GraphicsConfiguration;
>> [exec] [junit] 0000007a java/awt/Window.<init>(Ljava/awt/Window;Ljava/awt/GraphicsConfiguration;)V
>> [exec] [junit] 00000003 java/awt/Frame.<init>(Ljava/lang/String;Ljava/awt/GraphicsConfiguration;)V
>> [exec] [junit] 00000003 java/awt/Frame.<init>(Ljava/lang/String;)V
>> [exec] [junit] 00000003 java/awt/Frame.<init>()V
>> [exec] [junit] 00000009 java/awt/Graphics2DTest.setUp()V
>
>
> Not sure what has changed to cause this failure. The file [1] says
> /* DO NOT EDIT THIS FILE - it is based on X11 headers and was
> autogenerated by nativebridge tool */
>
> so I'm guessing I can't fix it up there. suggestions?
>
>
> [1]
> http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/awt/src/main/native/x11wrapper/linux/org_apache_harmony_awt_nativebridge_linux_X11.cpp?revision=476395&view=markup
>
> Regards,
> Tim
>