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 344137 - Document that wnck objects are owned by libwnck
Document that wnck objects are owned by libwnck
Status: RESOLVED FIXED
Product: libwnck
Classification: Core
Component: docs
2.14.x
Other All
: Normal normal
: 2.20.x
Assigned To: libwnck maintainers
libwnck maintainers
Depends on:
Blocks:
 
 
Reported: 2006-06-07 11:54 UTC by Sven Herzberg
Modified: 2011-02-18 17:12 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
testcase (1.34 KB, text/x-csrc)
2006-06-07 11:55 UTC, Sven Herzberg
Details

Description Sven Herzberg 2006-06-07 11:54:39 UTC
Steps to reproduce:
1. download the attached file
2. compile it (gcc -o demo main.c `pkg-config --cflags --libs libwnck-1.0`)
3. run it, open a window, close it
4. take a look at the application, it has crashed


Stack trace:
  • #0 wnck_workspace_is_virtual
    from /usr/lib/libwnck-1.so.18
  • #1 wnck_window_get_icon
    from /usr/lib/libwnck-1.so.18
  • #2 wnck_workspace_is_virtual
    from /usr/lib/libwnck-1.so.18
  • #3 gdk_event_apply_filters
    at gdkevents-x11.c line 328
  • #4 gdk_event_translate
    at gdkevents-x11.c line 874
  • #5 _gdk_events_queue
    at gdkevents-x11.c line 2225
  • #6 gdk_event_dispatch
    at gdkevents-x11.c line 2285
  • #7 IA__g_main_context_dispatch
    at gmain.c line 1916
  • #8 g_main_context_iterate
    at gmain.c line 2547
  • #9 IA__g_main_loop_run
    at gmain.c line 2751
  • #10 IA__gtk_main
    at gtkmain.c line 1026
  • #11 main

Other information:
An attachment, will attach it...
Comment 1 Sven Herzberg 2006-06-07 11:55:33 UTC
Created attachment 66906 [details]
testcase

Here's the attachment.
Comment 2 Elijah Newren 2006-06-08 21:43:07 UTC
Remove the g_object_unref() and it seems to work just fine.  :)  The g_object_unref() doesn't look like it can be right since libwnck/screen.c keeps a static WnckScreen **screens around, and just returns the ith member of it whenever someone asks for a screen.  By unrefing it, it looks like you're freeing the memory, but you aren't fixing up the screens array and thus the next person who comes along would get a pointer to free'd data.

But, somewhat embarrassingly, I've never bothered to figure out how all the gobject stuff interacts, so you'll have to take what I say with a grain of salt.  And get someone else to look over it for what, if anything, needs to actually be done in wnck.  It looks like the screens struct is never freed/cleared, so it appears we need to at least do that somewhere (at least for valgrind cleanness).
Comment 3 Benjamin Otte (Company) 2006-06-17 08:55:07 UTC
From my understanding, Wnck is completely static in the sense that it creates all objects itself and keeps all references for itself. So no Wnck object ever needs to be reffed/unreffed. I don't even know what happens if you keep a reference to a WnckFoo struct and access it after it was already "destroyed" by Wnck.

This is btw how I'd expect it to behave, but it probably needs to be documented.
Comment 4 Mariano Suárez-Alvarez 2006-10-29 01:10:23 UTC
Should this be moved to the docs component (it does not exist ;-) )?
Comment 5 Sven Herzberg 2006-11-22 12:56:01 UTC
Other point: I'm using libwnck to provide a window selection. Shouldn't it be possible to wnck_shutdown() when I'm done?
Comment 6 Vincent Untz 2007-06-08 18:54:55 UTC
Moving to shiny new docs component.

(In reply to comment #5)
> Other point: I'm using libwnck to provide a window selection. Shouldn't it be
> possible to wnck_shutdown() when I'm done?

Hrm, interesting idea. I've nothing against it, except that it should be filed as a new bug of course :-)
Comment 7 Vincent Untz 2011-02-18 17:12:18 UTC
I split the part about wnck_shutdown() in bug 642692. And I finally added some documentation.