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 622068 - [gtk-module] unsave calling of logging handlers
[gtk-module] unsave calling of logging handlers
Status: RESOLVED WONTFIX
Product: bug-buddy
Classification: Deprecated
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Fernando Herrera
Bug-buddy Maintainers
gnome[unmaintained]
: 631315 (view as bug list)
Depends on: 622433
Blocks:
 
 
Reported: 2010-06-19 12:21 UTC by Sven Herzberg
Modified: 2018-07-16 08:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test case for this bug (1.48 KB, application/x-compressed-tar)
2010-06-22 20:09 UTC, Fernando Herrera
Details

Description Sven Herzberg 2010-06-19 12:21:35 UTC
In mango-lassi we have a logging handler that requires a valid pointer to be passed to the logging handler of our application. However, bug-buddy's gtk-module insists on calling our logging handler with a NULL pointer leading to a crash in our application.

Please make sure you only call a logging handler with user_data=NULL if you know what you do (e.g. when you know it's glib's default handler). Or please make sure you get the appropriate user_data for the logging handler that way there before you attach yours (which requires new API in glib AFAIT).
Comment 1 Fernando Herrera 2010-06-22 20:09:53 UTC
Created attachment 164343 [details]
Test case for this bug
Comment 2 Fernando Herrera 2010-06-22 20:23:38 UTC
Fixed on master, however I am keeping this bug open because we really want to call original log handlers from applications. I opened a glib bug to request a new function that would return also original user_data.
Comment 3 Vincent Untz 2010-10-04 13:46:09 UTC
*** Bug 631315 has been marked as a duplicate of this bug. ***
Comment 4 Vincent Untz 2010-10-04 13:48:22 UTC
So, hrm, this makes gnome-session really verbose by default. How can we work around this, either in bug-buddy or gnome-session?
Comment 5 Pacho Ramos 2010-12-09 21:49:46 UTC
Should we try to use:
http://git.gnome.org/browse/bug-buddy/commit/?id=475fa5697d0aad6883318e9c51af81f51c9030e4

on 2.32 also?
Comment 6 Sven Herzberg 2010-12-10 09:22:50 UTC
(In reply to comment #5)
> Should we try to use:
> http://git.gnome.org/browse/bug-buddy/commit/?id=475fa5697d0aad6883318e9c51af81f51c9030e4
> 
> on 2.32 also?

Yes please. Maybe we should open a bug on glib about this, so we can do something like this:

> GLogFunc* old_handler = NULL;
> gpointer  old_data = NULL;
>
> old_handler = g_log_override_default_handler (new_handler, new_data, &old_data);

Opinions?
Comment 7 Pacho Ramos 2010-12-10 19:01:42 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Should we try to use:
> > http://git.gnome.org/browse/bug-buddy/commit/?id=475fa5697d0aad6883318e9c51af81f51c9030e4
> > 
> > on 2.32 also?
> 
> Yes please. Maybe we should open a bug on glib about this, so we can do
> something like this:
> 

Looks like it's still applied on 2.32 but gnome-session is still using debug mode :-(
Comment 8 André Klapper 2018-07-16 08:24:36 UTC
bug-buddy is not under active development anymore and had its last code changes
many years ago. Its codebase has been archived:
https://gitlab.gnome.org/Archive/bug-buddy/commits/master

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality (see bug 796784). Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.