Ke Wang <ke.w...@sun.com> writes:
> I think the problem is that JAW could not find the so library file.
That is one possibility, however, the empty catch block in AtkWrapper
silently muffles all possible Exceptions so that debugging initialisation
problems becomes pretty obscure.
I am refering to this piece of code in
wrapper/org/GNOME/Accessibility/AtkWrapper.java.in:
static {
try {
Process p = Runtime.getRuntime().exec("@XPROP@ -root");
BufferedReader b = new BufferedReader (new
InputStreamReader(p.getInputStream()));
String result;
accessibilityEnabled = false;
while ((result = b.readLine()) != null) {
if (result.indexOf ("AT_SPI_IOR") >= 0) {
accessibilityEnabled = true;
break;
}
}
if (accessibilityEnabled) {
System.loadLibrary("atk-wrapper");
AtkWrapper.initNativeLibrary();
}
} catch (Exception e) { }
}
Now, the problem on my system (Debian) is that @XPROP@
gets expanded to /usr/X11/bin/xprop, but on my system xprop
is located in /usr/bin. So the System#loadLibrary call is never
executed and the exception thrown by Runtime#exec is silently ignored.
Correcting the absolute path to xprop did apparently help to
get me further but now I do get a segmentation fault.
If you have any hints on how to debug segfaults related to the use of
java-atk-wrapper, please let me know.
Stack: [0xb6b33000,0xb6b84000], sp=0xb6b823f0, free space=13cb6b81d94k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libpthread.so.0+0x7aa7]
C [libX11.so.6+0x2a08f]
C [libX11.so.6+0x4087e] XrmQGetResource+0x3e
C [libX11.so.6+0x2054b] XGetDefault+0xcb
C [libmawt.so+0xed8f] Java_sun_awt_X11_XlibWrapper_XGetDefault+0xcf
j
sun.awt.X11.XlibWrapper.XGetDefault(JLjava/lang/String;Ljava/lang/String;)Ljava/lang/String;+0
j sun.awt.X11.XToolkit.initializeMultiClickTime()V+12
j sun.awt.X11.XToolkit.getMultiClickTime()I+6
j sun.awt.X11.XToolkit.initializeDesktopProperties()V+66
j java.awt.Toolkit.getDesktopProperty(Ljava/lang/String;)Ljava/lang/Object;+32
j
sun.swing.SwingUtilities2$AATextInfo.getAATextInfo(Z)Lsun/swing/SwingUtilities2$AATextInfo;+11
j
javax.swing.plaf.metal.MetalLookAndFeel.initComponentDefaults(Ljavax/swing/UIDefaults;)V+12213
j
javax.swing.plaf.basic.BasicLookAndFeel.getDefaults()Ljavax/swing/UIDefaults;+25
j
javax.swing.plaf.metal.MetalLookAndFeel.getDefaults()Ljavax/swing/UIDefaults;+9
j javax.swing.UIManager.setLookAndFeel(Ljavax/swing/LookAndFeel;)V+79
j javax.swing.UIManager.setLookAndFeel(Ljava/lang/String;)V+16
j javax.swing.UIManager.initializeDefaultLAF(Ljava/util/Properties;)V+28
j javax.swing.UIManager.initialize()V+9
...
To wrap my experience up: I think xprop should be executed
without a hardcoded path (relying on $PATH), and exceptions should at
least
print a stacktrace on the console if they occur.
However, I am stuck when it comes to the segmentation fault,
especially because JAW doesn't appear in the stack trace at all.
P.S.: I basically just tried JAW because JABG apparently stopped working
on my system since the last major upgrade (it can no longer connect to
orbit). So currently, I am left without access to the Java platform,
which is very unfortunate given that I am developing an application[1]
for people with special needs, based on Java (and swing).
If you read this and know why JABG is no longer talking to ORBit, please
drop me a note, I need working Java Accessibility again (which did work
for at least a year for me now).
[1] http://code.google.com/p/freedots/
--
CYa,
⡍⠁⠗⠊⠕
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
