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 779874 - warning on exit that can lead to a crash.
warning on exit that can lead to a crash.
Status: RESOLVED FIXED
Product: gnome-maps
Classification: Applications
Component: general
3.23.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-maps-maint
gnome-maps-maint
Depends on:
Blocks:
 
 
Reported: 2017-03-10 18:38 UTC by Hussam Al-Tayeb
Modified: 2017-06-25 19:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
userLocationMarker: Don't connect to destroy (2.08 KB, patch)
2017-03-12 21:35 UTC, Marcus Lundblad
committed Details | Review

Description Hussam Al-Tayeb 2017-03-10 18:38:31 UTC
Gnome maps is printing this on exit:

Gjs-Message: JS WARNING: [resource:///org/gnome/Maps/js/placeStore.js 309]: reference to undefined property this._typeTable[place.uniqueID]

(gnome-maps:17403): Gjs-CRITICAL **: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy() or dispose() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.

(gnome-maps:17403): Gjs-CRITICAL **: The offending signal was destroy on Gjs_UserLocationMarker 0x401ee00.

I asked ptomato on irc.
He said:
"you shouldn't connect to the 'destroy' signal in GJS
and it looks like UserLocationMarker does so"
Comment 1 Marcus Lundblad 2017-03-12 21:35:48 UTC
Created attachment 347775 [details] [review]
userLocationMarker: Don't connect to destroy

Instead of connecting to the destoy signal to disconnect from the
MapView zoom-level property, explicitly disconnect the signal handler
when re-creating the marker in the MapView.
Comment 2 Marcus Lundblad 2017-03-12 21:38:20 UTC
I haven't been able to reproduce the actual bug, but the above patch should at least theoretically solve this problem. Also I haven't really been able to excersize this patch, as my development machine is a desktop machine and has no WiFi h/w, and thus by its nature keeps a static location. But it should probably work (but ofcourse testing would be appreciated).
Comment 3 Hussam Al-Tayeb 2017-03-12 21:45:34 UTC
Same here. No wifi hardware. Just a desktop connected to a neighborhood cable provider through an ethernet cable. Pressing 'go to current location' always showed the pin at the address of the cable provider instead of mine.

The patch does however stop the warning. Thank you very much!
Comment 4 Marcus Lundblad 2017-06-25 19:57:10 UTC
Attachment 347775 [details] pushed as b763a33 - userLocationMarker: Don't connect to destroy