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 332405 - gnome-panel crashed after 'apt-get remove' of listed app
gnome-panel crashed after 'apt-get remove' of listed app
Status: RESOLVED DUPLICATE of bug 322983
Product: gnome-panel
Classification: Other
Component: panel
2.12.x
Other other
: High critical
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-02-24 05:22 UTC by Dave Edwards
Modified: 2006-02-25 05:35 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description Dave Edwards 2006-02-24 05:22:41 UTC
Distribution: Ubuntu 5.10 (breezy)
Package: gnome-panel
Severity: normal
Version: GNOME2.12.1 2.12.x
Gnome-Distributor: Ubuntu
Synopsis: gnome-panel crashed after 'apt-get remove' of listed app
Bugzilla-Product: gnome-panel
Bugzilla-Component: Panel
Bugzilla-Version: 2.12.x
BugBuddy-GnomeVersion: 2.0 (2.12.0)
Description:
Description of the crash:
* after doing 'apt-get --purge remove vile' gnome-panel crashed

Steps to reproduce the crash:
1. apt-get install vile
2. never use vile, wonder why you installed it in the first place
3. apt-get --purge remove vile

Expected Results:


How often does this happen?


Additional Information:



Debugging Information:

Backtrace was generated from '/usr/bin/gnome-panel'

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
`system-supplied DSO at 0xffffe000' has disappeared; keeping its
symbols.
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1223960896 (LWP 1745)]
[New Thread -1226925136 (LWP 1770)]
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()

Thread 1 (Thread -1223960896 (LWP 1745))

  • #0 __kernel_vsyscall
  • #1 __waitpid_nocancel
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 libgnomeui_module_info_get
    from /usr/lib/libgnomeui-2.so.0
  • #3 <signal handler called>
  • #4 gmenu_tree_directory_make_path
    from /usr/lib/libgnome-menu.so.2
  • #5 gmenu_tree_directory_make_path
    from /usr/lib/libgnome-menu.so.2
  • #6 g_vasprintf
    from /usr/lib/libglib-2.0.so.0
  • #7 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #8 g_main_context_check
    from /usr/lib/libglib-2.0.so.0
  • #9 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #10 gtk_main
    from /usr/lib/libgtk-x11-2.0.so.0
  • #11 main
  • #0 __kernel_vsyscall




------- Bug created by bug-buddy at 2006-02-24 05:22 -------

Comment 1 Karsten Bräckelmann 2006-02-24 15:43:48 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but the maintainers need more information to fix the bug. Could you please answer the questions in the other report?

Please feel free to report any further bugs you find.


Identical stacktrace as bug 327415, same as bug 322983.

*** This bug has been marked as a duplicate of 322983 ***
Comment 2 Dave Edwards 2006-02-24 18:10:37 UTC
I'm sorry to be intransigent, but this seems to be about a different issue than bug 322983.  Can you explain why they are considered the same?
Comment 3 Dave Edwards 2006-02-24 18:23:04 UTC
N.B.: erratico @ sympatico.ca and  dle @ sympatico.ca are both addresses for Dave Edwards.
Comment 4 Karsten Bräckelmann 2006-02-25 04:07:51 UTC
Dave, the stacktraces show, that the bugs are the same.

The crashing thread (top-most in this case) is identical to the one in bug 322983, and even the entire stacktrace is identical to the one in bug 327415. The stacktraces clearly show, which functions in the code where called, that lead to the crash. In all these bugs, the very same functions where called in order.

It is possible and happens pretty frequently, that the last actions (according to what the user did) don't match the actual crashing application, or that different user actions indeed trigger the very same behavior in the code, that leads to the crash.

You can have a look at the stacktraces yourself, if you want. The important code is in the top most thread, below the "signal handler called" mark. You can see which function() was called and in which library (from) it is. Any function was called directly by the function that appears right below in the stacktrace.

Hope, this explains why I duplicated this bug. :)


We do appreciate any reported bug. So unless you are sure the bug is already known, please feel free to simply report it. Duplicates are a good resource to estimate, how often a bug appears and thus how annoying or severe it is. Different reports how one particular bug can be triggered are useful too, for reproduction and tracking down the bug.

Thanks for caring about your bugs and getting back to us for clarification. It sure is possible, that we closed a bug by mistake.
Comment 5 Dave Edwards 2006-02-25 05:35:19 UTC
(In reply to comment #4)
Thanks for the explanation.  Very nice!