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 163770 - Fix some warnings generated from wncklet applet
Fix some warnings generated from wncklet applet
Status: RESOLVED FIXED
Product: gnome-panel
Classification: Other
Component: window list
git master
Other Linux
: High normal
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-01-12 06:46 UTC by Elijah Newren
Modified: 2005-02-02 09:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Check for window_menu being NULL (844 bytes, patch)
2005-01-12 06:46 UTC, Elijah Newren
needs-work Details | Review
One of the stack traces.... (18.93 KB, text/plain)
2005-01-13 03:32 UTC, Elijah Newren
  Details
A new one not fixed by the patch (20.14 KB, text/plain)
2005-01-13 03:33 UTC, Elijah Newren
  Details

Description Elijah Newren 2005-01-12 06:46:08 UTC
While trying to debug bug 163343, I ran across some related critical warnings
from libwnck (bug 149326).  So, I started running with --g-fatal-warnings.  When
I did so, I also got two more crashes from wncklet that didn't appear to come
from libwnck.  I'll attach a patch in a minute that avoids these
warnings/errors/whatever.
Comment 1 Elijah Newren 2005-01-12 06:46:59 UTC
Created attachment 35882 [details] [review]
Check for window_menu being NULL
Comment 2 Vincent Untz 2005-01-12 08:38:24 UTC
Elijah: how can window_menu be NULL in these functions?
Comment 3 Elijah Newren 2005-01-12 16:18:54 UTC
I don't know.  I just know they were.  (It was the first time I ever looked at
the wncklet code, and I didn't bother to investigate very far since I was really
concentrating on a different problem and was trying to get back to it...)  Would
you like me to try to get a stack trace from the crashes I saw with
--g-fatal-warnings where they were NULL?
Comment 4 Elijah Newren 2005-01-12 16:21:11 UTC
Oh, and in case you want to try to reproduce, here are the circumstances under
which I saw the two different crashes after running with --g-fatal-warnings:

Case 1: Start switching tabs in a gnome-terminal or in mozilla.

Case 2: Go to an workspace with no windows, and open up a terminal.
Comment 5 Vincent Untz 2005-01-12 16:30:02 UTC
Elijah: it'd be great if you can get some stack traces! I'm looking at something
else right now, but I'll try to look at this later.
Thanks
Comment 6 Elijah Newren 2005-01-12 21:34:54 UTC
I can't reproduce at school--I'm suspecting I may messed up something on my home
system.  Let me take a look...
Comment 7 Elijah Newren 2005-01-13 03:32:25 UTC
Created attachment 35923 [details]
One of the stack traces....
Comment 8 Elijah Newren 2005-01-13 03:33:00 UTC
Created attachment 35924 [details]
A new one not fixed by the patch
Comment 9 Elijah Newren 2005-01-13 03:37:52 UTC
Okay, so although I can still repeat this even after updating gnome-menus and
gnome-panel, I think it really just points to something being haywire on my home
machine.  In particular, from the new stack trace:

  • #11 window_menu_set_window_icon
    at window-menu.c line 275
  • #12 window_menu_set_active_window
    at window-menu.c line 325

This makes absolutely no sense.  How can window_menu be non-NULL in
window_menu_set_active_window, get passed to window_menu_set_window_icon, and
then suddenly be NULL?  Something has got to be wrong on this machine, though I
have no clue what it would be...
Comment 10 Vincent Untz 2005-01-26 13:09:39 UTC
Comment on attachment 35882 [details] [review]
Check for window_menu being NULL

Patch doesn't look ok (see previous comments)
Comment 11 Vincent Untz 2005-02-02 09:12:57 UTC
2005-02-02  Vincent Untz  <vincent@vuntz.net>

        * libwnck/selector.c: fix typo
        (wnck_selector_window_icon_changed):
        (wnck_selector_window_name_changed):
        (wnck_selector_window_state_changed):
        (wnck_selector_window_closed): don't do anything if the hash was not
        created yet
        Fix bug #163770