After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 527862 - Intermittent thread related test failure
Intermittent thread related test failure
Status: RESOLVED OBSOLETE
Product: java-gnome
Classification: Bindings
Component: GTK
4.0.x
Other Linux
: Normal major
: ---
Assigned To: java-gnome bindings maintainers
java-gnome bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2008-04-13 12:42 UTC by Andrew Cowie
Modified: 2009-02-01 04:44 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Andrew Cowie 2008-04-13 12:42:13 UTC
If you do:

$ while true
> do
>     make test
>     if [ $? -ne 0 ]
>     then
>         break
>     fi
> done

and let it run for a few minutes, you will may see:

org.gnome.glib.ValidateConstants
 - testEnumHandling()                                                 
(java:8389): GLib-GObject-WARNING **: IA__g_object_new_valist: object class `GThemedIcon' has no property named `names'
ok        

and then, even more exciting, you'll might see:

org.gnome.glib.ValidateConstants
 - testEnumHandling()                                                 
GLib-GObject-ERROR **: g_type_plugin_*() invalidly modified type `GFileInfo'
aborting...
make: *** [test] Error 1

Which is bad. It is clearly at:

        fc = new FileChooserButton("Test chooser", FileChooserAction.OPEN);

which is line 36 of ValidateConstants. This should be harmless, but it is definitely spawning off its own threads; (I had to add AttachCurrentThreadAsDaemon() to bindings_java_getEnv() in src/jni/bindings_java_util.c; see revno 486)

Having fixing that led to the error modes described above.

Forcing a core dump and firing up GDB shows the following. The problem is in Thread #1 at the bottom.

(gdb) thread apply all bt

Thread 6 (process 8517)

  • #0 __kernel_vsyscall
  • #1 sem_wait
    from /lib/libpthread.so.0
  • #2 check_pending_signals
    from /opt/sun-jdk-1.6.0.05/jre/lib/i386/client/libjvm.so
  • #3 os::signal_wait
    from /opt/sun-jdk-1.6.0.05/jre/lib/i386/client/libjvm.so
  • #4 signal_thread_entry
    from /opt/sun-jdk-1.6.0.05/jre/lib/i386/client/libjvm.so
  • #5 JavaThread::run
    from /opt/sun-jdk-1.6.0.05/jre/lib/i386/client/libjvm.so
  • #6 java_start
    from /opt/sun-jdk-1.6.0.05/jre/lib/i386/client/libjvm.so
  • #7 start_thread
    at pthread_create.c line 296
  • #8 clone
    from /lib/libc.so.6

AfC
Comment 1 Morten Welinder 2008-06-10 13:35:46 UTC
Likely a dupe of bug 537555.
Comment 2 Andrew Cowie 2009-02-01 04:44:38 UTC
I have not observed this in many many months. Perhaps Morten's speculation was correct. In any case, I'm going to close this for now as no one else has reported any problems here.

[Hooray]

AfC