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 424425 - Ghex crashed on closing
Ghex crashed on closing
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Accessibility
unspecified
Other All
: Normal critical
: ---
Assigned To: gtk-bugs
gtk-bugs
: 465127 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-03-30 10:18 UTC by Charles-henri DE BLESSON
Modified: 2014-12-22 15:30 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Charles-henri DE BLESSON 2007-03-30 10:18:37 UTC
Steps to reproduce:
1. Right-click on a file, choose open with GHex
2. GHex is opened, displaying the file content
3. Close the window, crash occured


Stack trace:
Memory status: size: 23838720 vsize: 0 resident: 23838720 share: 0 rss: 12914688 rss_rlim: 0
CPU usage: start_time: 1175248479 rtime: 0 utime: 67 stime: 0 cutime:61 cstime: 0 timeout: 6 it_real_value: 0 frequency: 0

Backtrace was generated from '/usr/bin/ghex2'

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1225426752 (LWP 18974)]
0xffffe410 in __kernel_vsyscall ()

Thread 1 (Thread -1225426752 (LWP 18974))

  • #0 __kernel_vsyscall
  • #1 __waitpid_nocancel
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 libgnomeui_segv_handle
    at gnome-ui-init.c line 874
  • #3 <signal handler called>
  • #4 IA__g_list_index
    at glist.c line 439
  • #5 gail_container_new
    from /usr/lib/gtk-2.0/modules/libgail.so
  • #6 gail_container_get_type
    from /usr/lib/gtk-2.0/modules/libgail.so
  • #7 IA__g_cclosure_marshal_VOID__OBJECT
    at gmarshal.c line 636
  • #8 IA__g_closure_invoke
    at gclosure.c line 490
  • #9 signal_emit_unlocked_R
    at gsignal.c line 2440
  • #10 IA__g_signal_emit_valist
    at gsignal.c line 2199
  • #11 IA__g_signal_emit
    at gsignal.c line 2243
  • #12 IA__gtk_container_remove
    at gtkcontainer.c line 991
  • #13 gtk_widget_dispose
    at gtkwidget.c line 6875
  • #14 IA__g_object_run_dispose
    at gobject.c line 573
  • #15 IA__gtk_object_destroy
    at gtkobject.c line 403
  • #16 IA__gtk_widget_destroy
    at gtkwidget.c line 2168
  • #17 gtk_fixed_forall
    at gtkfixed.c line 453
  • #18 IA__gtk_container_foreach
    at gtkcontainer.c line 1288
  • #19 gtk_container_destroy
    at gtkcontainer.c line 825
  • #20 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #21 g_type_class_meta_marshal
    at gclosure.c line 567
  • #22 IA__g_closure_invoke
    at gclosure.c line 490
  • #23 signal_emit_unlocked_R
    at gsignal.c line 2556
  • #24 IA__g_signal_emit_valist
    at gsignal.c line 2199
  • #25 IA__g_signal_emit
    at gsignal.c line 2243
  • #26 gtk_object_dispose
    at gtkobject.c line 418
  • #27 gtk_widget_dispose
    at gtkwidget.c line 6883
  • #28 IA__g_object_run_dispose
    at gobject.c line 573
  • #29 IA__gtk_object_destroy
    at gtkobject.c line 403
  • #30 IA__gtk_widget_destroy
    at gtkwidget.c line 2168
  • #31 gtk_box_forall
    at gtkbox.c line 670
  • #32 IA__gtk_container_foreach
    at gtkcontainer.c line 1288
  • #33 gtk_container_destroy
    at gtkcontainer.c line 825
  • #34 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #35 g_type_class_meta_marshal
    at gclosure.c line 567
  • #36 IA__g_closure_invoke
    at gclosure.c line 490
  • #37 signal_emit_unlocked_R
    at gsignal.c line 2556
  • #38 IA__g_signal_emit_valist
    at gsignal.c line 2199
  • #39 IA__g_signal_emit
    at gsignal.c line 2243
  • #40 gtk_object_dispose
    at gtkobject.c line 418
  • #41 gtk_widget_dispose
    at gtkwidget.c line 6883
  • #42 IA__g_object_run_dispose
    at gobject.c line 573
  • #43 IA__gtk_object_destroy
    at gtkobject.c line 403
  • #44 IA__gtk_widget_destroy
    at gtkwidget.c line 2168
  • #45 bonobo_dock_new
    from /usr/lib/libbonoboui-2.so.0
  • #46 IA__gtk_container_foreach
    at gtkcontainer.c line 1288
  • #47 gtk_container_destroy
    at gtkcontainer.c line 825
  • #48 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #49 g_type_class_meta_marshal
    at gclosure.c line 567
  • #50 IA__g_closure_invoke
    at gclosure.c line 490
  • #51 signal_emit_unlocked_R
    at gsignal.c line 2556
  • #52 IA__g_signal_emit_valist
    at gsignal.c line 2199
  • #53 IA__g_signal_emit
    at gsignal.c line 2243
  • #54 gtk_object_dispose
    at gtkobject.c line 418
  • #55 gtk_widget_dispose
    at gtkwidget.c line 6883
  • #56 IA__g_object_run_dispose
    at gobject.c line 573
  • #57 IA__gtk_object_destroy
    at gtkobject.c line 403
  • #58 IA__gtk_widget_destroy
    at gtkwidget.c line 2168
  • #59 gtk_box_forall
    at gtkbox.c line 670
  • #60 IA__gtk_container_foreach
    at gtkcontainer.c line 1288
  • #61 gtk_container_destroy
    at gtkcontainer.c line 825
  • #62 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #63 g_type_class_meta_marshal
    at gclosure.c line 567
  • #64 IA__g_closure_invoke
    at gclosure.c line 490
  • #65 signal_emit_unlocked_R
    at gsignal.c line 2556
  • #66 IA__g_signal_emit_valist
    at gsignal.c line 2199
  • #67 IA__g_signal_emit
    at gsignal.c line 2243
  • #68 gtk_object_dispose
    at gtkobject.c line 418
  • #69 gtk_widget_dispose
    at gtkwidget.c line 6883
  • #70 IA__g_object_run_dispose
    at gobject.c line 573
  • #71 IA__gtk_object_destroy
    at gtkobject.c line 403
  • #72 IA__gtk_widget_destroy
    at gtkwidget.c line 2168
  • #73 gtk_bin_forall
    at gtkbin.c line 133
  • #74 IA__gtk_container_foreach
    at gtkcontainer.c line 1288
  • #75 gtk_container_destroy
    at gtkcontainer.c line 825
  • #76 gtk_window_destroy
    at gtkwindow.c line 3954
  • #77 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #78 g_type_class_meta_marshal
    at gclosure.c line 567
  • #79 IA__g_closure_invoke
    at gclosure.c line 490
  • #80 signal_emit_unlocked_R
    at gsignal.c line 2556
  • #81 IA__g_signal_emit_valist
    at gsignal.c line 2199
  • #82 IA__g_signal_emit
    at gsignal.c line 2243
  • #83 gtk_object_dispose
    at gtkobject.c line 418
  • #84 gtk_widget_dispose
    at gtkwidget.c line 6883
  • #85 gtk_window_dispose
    at gtkwindow.c line 1794
  • #86 bonobo_window_remove_popup
    from /usr/lib/libbonoboui-2.so.0
  • #87 IA__g_object_run_dispose
    at gobject.c line 573
  • #88 IA__gtk_object_destroy
    at gtkobject.c line 403
  • #89 IA__gtk_widget_destroy
    at gtkwidget.c line 2168
  • #90 ghex_window_close
  • #91 ghex_window_close
  • #92 _gtk_marshal_BOOLEAN__BOXED
    at gtkmarshalers.c line 84
  • #93 g_type_class_meta_marshal
    at gclosure.c line 567
  • #94 IA__g_closure_invoke
    at gclosure.c line 490
  • #95 signal_emit_unlocked_R
    at gsignal.c line 2478
  • #96 IA__g_signal_emit_valist
    at gsignal.c line 2209
  • #97 IA__g_signal_emit
    at gsignal.c line 2243
  • #98 gtk_widget_event_internal
    at gtkwidget.c line 3911
  • #99 IA__gtk_main_do_event
    at gtkmain.c line 1379
  • #100 gdk_event_dispatch
    at gdkevents-x11.c line 2320
  • #101 IA__g_main_context_dispatch
    at gmain.c line 2045
  • #102 g_main_context_iterate
    at gmain.c line 2677
  • #103 IA

Other information:
I'm not sure this the right place for this bug, I didn't find an entry for libgail.

Do not hesitate to contact me if I can provide more information.

Kind Regards,
Charlie.
Comment 1 Rodney Dawes 2007-08-08 20:24:55 UTC
Looks like a crash in gail rather than ghex.
Comment 2 Rodney Dawes 2007-08-09 21:52:11 UTC
*** Bug 465127 has been marked as a duplicate of this bug. ***
Comment 3 Thorsten Leemhuis 2007-08-10 04:46:05 UTC
As written in Bug 465127 -- it's likely a problem with a misplaced GDK_THREADS_ENTER. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227828#c10 and the
comments below it for some more details on the issue. 

Li Yuan, could you confirm this so we can move this bug back to ghex, where it afaics belongs?
Comment 4 Li Yuan 2007-08-10 05:30:03 UTC
From https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246560#c1, the trace is very similar to this bug. Unfortunately it doesn't get any gail symbols in it :(
I think it maybe a bug in gail. I don't find any clue points to GDK_THREADS_ENTER...
Comment 5 Rodney Dawes 2007-08-10 12:34:27 UTC
I don't think an additional call to GDK_THREADS_ENTER in every app using gail is an appropriate solution. I grepped through the ghex source for thread, and it calls only GDK_THREADS_ENTER/GDK_THREADS_LEAVE in one function, which appears to be unrelated to the crash.

The redhat bug seems to imply that calling GDK_THREADS_ENTER before gnome_program_init is a new gail requirement. Perhaps gail_init should be making the call to GDK_THREADS_ENTER, or do what it's doing some other way, so as to avoid crashing applications. GHex isn't even calling any of the _threads_init methods, so I don't see why it should be adding those just to satisfy a new requirement of gail. And it seems as if this issue affects multiple applications, so rather than requiring all of those applications to add all of the thread init calls, it seems best to fix the problem at the source, than duplicating a workaround in all the apps.
Comment 6 Thorsten Leemhuis 2007-08-10 12:47:03 UTC
(In reply to comment #5)
> I don't think an additional call to GDK_THREADS_ENTER in every app using gail
> is an appropriate solution. 

AFAIK there is no "additional call" needed (at least in the mail-notification case there was no additional one needed). It just needs to be called right after "gdk_threads_init ();" afaik (but my programming skills are limited and that is only based on the comments I heard on this issue).
Comment 7 Rodney Dawes 2007-08-10 14:18:06 UTC
(In reply to comment #6)
> AFAIK there is no "additional call" needed (at least in the mail-notification
> case there was no additional one needed). It just needs to be called right
> after "gdk_threads_init ();" afaik (but my programming skills are limited and
> that is only based on the comments I heard on this issue).

Where does the _LEAVE get called for that _ENTER though? I understand there may have been a threading issue in the mail notifier, but then that is an issue for the mail notifier. GHex doesn't directly call gdk_threads_init (). If the suggestion is that all apps need to do this, then it is additional work, that should probably actually be done by the dependent library that is requiring it to be done, rather than all the apps.
Comment 8 Li Yuan 2007-08-12 01:05:26 UTC
(In reply to comment #5)
First I don't know why we discuss thread problem here.:) From the trace:
  • #4 IA__g_list_index
    at glist.c line 439
  • #5 gail_container_new

> I don't think an additional call to GDK_THREADS_ENTER in every app using gail
> is an appropriate solution. I grepped through the ghex source for thread, and
> it calls only GDK_THREADS_ENTER/GDK_THREADS_LEAVE in one function, which
> appears to be unrelated to the crash.
Accessibility never suggestion any program makes additional call to GDK_THREADS_ENTER. Program written under GNOME documents should work. Please refer to http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html:
"As always, you must also surround any calls to GTK+ not made within a signal handler with a gdk_threads_enter()/gdk_threads_leave() pair."
Gail just assumes it is always called under GDK lock. 

> The redhat bug seems to imply that calling GDK_THREADS_ENTER before
> gnome_program_init is a new gail requirement. 
This is not gail requirement, this is GNOME requirement, if the application is multi-threads.

> Perhaps gail_init should be
> making the call to GDK_THREADS_ENTER, or do what it's doing some other way, so
> as to avoid crashing applications. GHex isn't even calling any of the
> _threads_init methods, 
You said GHex calls GDK_THREADS_ENTER/GDK_THREADS_LEAVE once. It doesn't initialize threads before using it?

> so I don't see why it should be adding those just to
> satisfy a new requirement of gail. And it seems as if this issue affects
> multiple applications, 
Maybe because these applications don't do what GNOME requires. If an application is written under GNOME document and have such a problem, it should be A11Y's bug.

> so rather than requiring all of those applications to
> add all of the thread init calls, it seems best to fix the problem at the
> source, than duplicating a workaround in all the apps.
A11Y should not require any other application calling thread_init if there are only one thread in the application. If the application is multi-threads, please call it under GNOME documents.

Comment 9 Li Yuan 2007-08-12 01:11:50 UTC
(In reply to comment #7)
> Where does the _LEAVE get called for that _ENTER though? 
The example is from http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html :
int
main (int argc, char *argv[])
{
  GtkWidget *window;

  g_thread_init (NULL);
  gdk_threads_init ();
  gdk_threads_enter ();

  gtk_init (&argc, &argv);

  window = create_window ();
  gtk_widget_show (window);

  gtk_main ();
  gdk_threads_leave ();

  return 0;
}

> I understand there may
> have been a threading issue in the mail notifier, but then that is an issue for
> the mail notifier. GHex doesn't directly call gdk_threads_init (). 
Is GHex thread enabled?

Comment 10 Li Yuan 2007-08-12 01:40:03 UTC
I'm a little confused what we discussed here...
What problem does GHex have in this conversation? Only this crash? It should not be a problem relative to thread but a bug in gail I think. If it is relative to thread_init and the first call to thread_enter, the crash probably cannot wait until the close :-)

To clarify, A11Y never *require* applications to do anything which is not the normal GNOME requirement). If GHex is not thread enabled, it is OK, it should work with A11Y. If GHex is thread enabled, just do what GNOME requirement, then if should work with A11Y.
Comment 11 Rodney Dawes 2007-08-12 02:05:35 UTC
GHex does not appear to me to be using threads. It doesn't create mutexes and lock them. It doesn't call any of the _thread_init methods. It does call _THREAD_ENTER/LEAVE in one single function in the entire source. However, not using threads for anything, I'm not sure that it even has any effect. It should already be in the main thread, and under a GDK lock if any.

I'm inclined to believe this is a valid gail bug. Thorsten keeps bringing up the thread issue because it seemed to work around a similar, if not the same, problem in mail-notifier.
Comment 12 Matthias Clasen 2014-12-22 15:30:55 UTC
I don't think this is a problem anymore - ghex starts and stops without any problems nowadays