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 320062 - problems with lsb-release and $distro-release existing side by side
problems with lsb-release and $distro-release existing side by side
Status: RESOLVED FIXED
Product: bug-buddy
Classification: Deprecated
Component: general
unspecified
Other Linux
: High major
: ---
Assigned To: Bug-buddy Maintainers
Bug-buddy Maintainers
critical-warning
Depends on:
Blocks:
 
 
Reported: 2005-10-28 10:08 UTC by Kjartan Maraas
Modified: 2006-01-06 19:41 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Don't assume a certain number of lines exist in the lsb file (675 bytes, patch)
2005-12-28 20:35 UTC, Elijah Newren
none Details | Review
Proposed patch (2.65 KB, patch)
2006-01-05 18:16 UTC, Fernando Herrera
none Details | Review

Description Kjartan Maraas 2005-10-28 10:08:51 UTC
bug-buddy is not handling this case gracefully it seems.

The lsb-release file has one mandatory field: "LSB_RELEASE" which isn't handled
in get_lsb_release() in distributions.c and three optional fields that are
handled. This is causing problems on Fedora Rawhide where we have both
lsb-release and fedora-release in /etc. Firstly it doesn't get any sane release
info and secondly it causes a Glib-CRITICAL warning in g_str_has_prefix()
because there's no DISTRIB_ID field in lsb-release at all on fedora.
Comment 1 Kjartan Maraas 2005-10-28 11:42:04 UTC
After looking at the code it seems to me like get_distro_name_from_file() should
look for both lsb-release and $distro-release before breaking out and then have
the rest handle the combined case?
Comment 2 Kjartan Maraas 2005-12-08 21:21:25 UTC
Here's the backtrace from the CRITICAL warning:

GLib-CRITICAL **: g_str_has_prefix: assertion `str != NULL' failed
aborting...

Program received signal SIGTRAP, Trace/breakpoint trap.

Thread NaN (LWP 2106)

  • #0 IA__g_logv
    at gmessages.c line 503
  • #1 IA__g_log
    at gmessages.c line 517
  • #2 IA__g_return_if_fail_warning
    at gmessages.c line 532
  • #3 IA__g_str_has_prefix
    at gstrfuncs.c line 2687
  • #4 get_lsb_version
    at distribution.c line 106
  • #5 get_distro_name_from_file
    at distribution.c line 193
  • #6 get_distro_name
    at distribution.c line 200
  • #7 generate_email_text
    at bugzilla.c line 1687
  • #8 enter_email
    at united-states-of-bug-buddy.c line 1140
  • #9 on_druid_next_clicked
    at united-states-of-bug-buddy.c line 773
  • #10 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #11 IA__g_closure_invoke
    at gclosure.c line 490
  • #12 signal_emit_unlocked_R
    at gsignal.c line 2519
  • #13 IA__g_signal_emit_valist
    at gsignal.c line 2208
  • #14 IA__g_signal_emit
    at gsignal.c line 2252
  • #15 IA__gtk_button_clicked
    at gtkbutton.c line 834
  • #16 gtk_real_button_released
    at gtkbutton.c line 1369
  • #17 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #18 g_type_class_meta_marshal
    at gclosure.c line 567
  • #19 IA__g_closure_invoke
    at gclosure.c line 490
  • #20 signal_emit_unlocked_R
    at gsignal.c line 2379
  • #21 IA__g_signal_emit_valist
    at gsignal.c line 2208
  • #22 IA__g_signal_emit
    at gsignal.c line 2252
  • #23 IA__gtk_button_released
    at gtkbutton.c line 826
  • #24 gtk_button_button_release
    at gtkbutton.c line 1262
  • #25 _gtk_marshal_BOOLEAN__BOXED
    at gtkmarshalers.c line 83
  • #26 g_type_class_meta_marshal
    at gclosure.c line 567
  • #27 IA__g_closure_invoke
    at gclosure.c line 490
  • #28 signal_emit_unlocked_R
    at gsignal.c line 2487
  • #29 IA__g_signal_emit_valist
    at gsignal.c line 2218
  • #30 IA__g_signal_emit
    at gsignal.c line 2252
  • #31 gtk_widget_event_internal
    at gtkwidget.c line 3735
  • #32 IA__gtk_propagate_event
    at gtkmain.c line 2169
  • #33 IA__gtk_main_do_event
    at gtkmain.c line 1406
  • #34 gdk_event_dispatch
    at gdkevents-x11.c line 2291
  • #35 IA__g_main_context_dispatch
    at gmain.c line 1913
  • #36 g_main_context_iterate
    at gmain.c line 2544
  • #37 IA__g_main_loop_run
    at gmain.c line 2748
  • #38 IA__gtk_main
    at gtkmain.c line 985
  • #39 main
    at bug-buddy.c line 741

Comment 3 Elijah Newren 2005-12-28 20:35:42 UTC
Created attachment 56479 [details] [review]
Don't assume a certain number of lines exist in the lsb file

This was also biting me on RHEL4.  If you look at distribution.c:get_lsb_version(), it reads all lines from the relevant file, and then does a sanity check to ensure that the lines array itself isn't NULL, and that the first and second (lines[0], lines[1]) lines from the file aren't NULL either.  However, it unconditionally tries to read from lines[2] anyway.  This patch just checks lines[2] before trying to read from it.  I'm not sure if you want to also fixup the g_strdup_printf() below it as the codename can be NULL and removing the empty parentheses that would result in name may be worthwhile.
Comment 4 Fernando Herrera 2006-01-05 18:16:57 UTC
Created attachment 56823 [details] [review]
Proposed patch

Can you please test this patch?
It should handle all my know cases correctly
(/etc/fedora-release mandatory over /etc/lsb-release, and /etc/lsb-release mandatory over /etc/debian_version)
Comment 5 Fernando Herrera 2006-01-06 19:41:10 UTC
Committed a fixed version (with i++ :) )