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 728337 - [bisected] Maps gets segmentation fault at start
[bisected] Maps gets segmentation fault at start
Status: RESOLVED FIXED
Product: libchamplain
Classification: Core
Component: General
unspecified
Other Linux
: Normal critical
: ---
Assigned To: libchamplain-maint
libchamplain-maint
: 732503 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-04-16 12:24 UTC by Jonas Danielsson
Modified: 2014-07-02 11:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ChamplainView: Sink initial MapSource reference (1.13 KB, patch)
2014-04-19 21:54 UTC, Jonas Danielsson
committed Details | Review

Description Jonas Danielsson 2014-04-16 12:24:44 UTC
Hi,

When starting Maps I almost at once get a segmentation fault, the window is drawn, but after that it goes.

I bisected gjs and found:

commit 5719e781e95e8f693db616ef0f7b77cbc730186d
Author: Cosimo Cecchi <cosimoc@gnome.org>
Date:   Thu Feb 27 14:05:41 2014 -0800

    all: schedule a full GC check after executing JS code
    
    After we return from JS::Call* or JS::Evaluate*, schedule a GC check
    for the next idle iteration, to prevent memory consumption skyrocketing.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=725099

This was the first bad commit. Reverting it on master made Maps work again.

Running through gdb gives this:

Program received signal SIGSEGV, Segmentation fault.
0xb7941d5e in g_object_steal_qdata (object=0x86b71c8, quark=657)
    at gobject.c:3361
3361	  g_return_val_if_fail (G_IS_OBJECT (object), NULL);
(gdb) bt
  • #0 g_object_steal_qdata
    at gobject.c line 3361
  • #1 cancel_toggle_idle
    at gi/object.cpp line 838
  • #2 object_instance_finalize
    at gi/object.cpp line 1421
  • #3 finalize
    at /home/jonas/checkout/gnome/js24-24.2.0/js/src/jsobjinlines.h line 213
  • #4 finalize<JSObject>
    at /home/jonas/checkout/gnome/js24-24.2.0/js/src/jsgc.cpp line 331
  • #5 FinalizeTypedArenas<JSObject>
    at /home/jonas/checkout/gnome/js24-24.2.0/js/src/jsgc.cpp line 395
  • #6 FinalizeArenas
    at /home/jonas/checkout/gnome/js24-24.2.0/js/src/jsgc.cpp line 432
  • #7 finalizeNow
    at /home/jonas/checkout/gnome/js24-24.2.0/js/src/jsgc.cpp line 1306
  • #8 js::gc::ArenaLists::queueObjectsForSweep
    at /home/jonas/checkout/gnome/js24-24.2.0/js/src/jsgc.cpp line 1402

Any ideas?
Comment 1 Giovanni Campagna 2014-04-16 16:10:27 UTC
The G_IS_OBJECT() call is failing, which means it is very likely a memory management bug in maps (in the C libraries or in the GIR annotations), that was just uncovered by the new GC in gjs.

You should try to understand what object is supposed to be there (you can look at the gtype and GIObjectInfo in ObjectInstance *priv, at object_instance_finalize()), and see where it is freed.
A valgrind run would also give you some hint on where to look.
Comment 2 Jonas Danielsson 2014-04-19 21:52:02 UTC
The problem is in libchamplain, Champlain uses a GObject called MapSource that is GInitiallyUnowned. When you set a map source on a ChamplainView it will do the correct thing and call g_object_ref_sink to remove the floating reference.

But in the champlain_view_init where an initial default map source is created there is no g_object_ref_sink call. So when Maps sets a MapSource on start there will be a call to g_object_unref on a floating reference.
Comment 3 Jonas Danielsson 2014-04-19 21:54:14 UTC
Created attachment 274743 [details] [review]
ChamplainView: Sink initial MapSource reference

We need to call g_object_ref_sink on the initial MapSource otherwise
we will call g_object_unref on a floating reference when a new
MapSource is set.
Comment 4 Jiri Techet 2014-04-22 19:03:01 UTC
Review of attachment 274743 [details] [review]:

Thanks for looking into this.
Comment 5 Zeeshan Ali 2014-07-02 11:42:04 UTC
*** Bug 732503 has been marked as a duplicate of this bug. ***