Bug 118733 - [PATCH] xscreensaver coredumps with an older .xscreensaver file
[PATCH] xscreensaver coredumps with an older .xscreensaver file
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: xscreensaver (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Depends On:
Blocks: 113479
  Show dependency treegraph
Reported: 2004-03-19 12:04 EST by Pancrazio `ezio' de Mauro
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-01 22:26:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
When copied to $HOME, this causes xscreensaver to dump core (8.00 KB, text/plain)
2004-03-19 12:05 EST, Pancrazio `ezio' de Mauro
no flags Details
xscreensaver-dont-trash-hack-list-when-hack-not-existant.patch (573 bytes, patch)
2004-06-10 12:33 EDT, Bastien Nocera
no flags Details | Diff

  None (edit)
Description Pancrazio `ezio' de Mauro 2004-03-19 12:04:15 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20031007 Firebird/0.7 StumbleUpon/1.89

Description of problem:
The attached .xscreensaver file causes xscreensaver to dump core

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. copy the attached .xscreensaver to $HOME
2. start xscreensaver
3. watch it dump core :-)

Actual Results:  segmentation fault, a backtrace of the core shows:

#0  0xb6e5416e in malloc_consolidate () from /lib/tls/libc.so.6
#1  0xb6e53769 in _int_malloc () from /lib/tls/libc.so.6
#2  0xb6e52b0d in malloc () from /lib/tls/libc.so.6
#3  0x0804f185 in write_init_file ()
#4  0x0805543b in restart_menu_cb ()
#5  0x08056a26 in run_prev_cb ()
#6  0x08057737 in switch_page_cb ()
#7  0xb711bc87 in g_cclosure_marshal_VOID__VOID () from
#8  0xb7108ef7 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#9  0xb711b89e in g_signal_emit_by_name () from
#10 0xb711a8e8 in g_signal_emit_valist () from
#11 0xb711ab24 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#12 0xb74f9b0a in _gtk_tree_selection_internal_select_node () from
#13 0xb74f88c0 in gtk_tree_selection_select_path () from
#14 0xb74f8b30 in gtk_tree_selection_select_iter () from
#15 0x08055829 in manual_cb ()
#16 0x080580c0 in settings_ok_cb ()
#17 0x0805bf39 in main ()

Expected Results:  xscreensaver should simply warn that the
configuration file is invalid or, even better, fix it, but it
shouldn't silently dump core.
Comment 1 Pancrazio `ezio' de Mauro 2004-03-19 12:05:32 EST
Created attachment 98688 [details]
When copied to $HOME, this causes xscreensaver to dump core
Comment 2 Bill Nottingham 2004-03-19 12:24:10 EST
This looks like #85205, which randomly resolved itself. :/
Comment 3 Bastien Nocera 2004-06-10 11:13:02 EDT
Better backtrace:
#0  0xb6e6334e in malloc_consolidate () from /lib/tls/libc.so.6
#1  0xb6e62949 in _int_malloc () from /lib/tls/libc.so.6
#2  0xb6e61ced in malloc () from /lib/tls/libc.so.6
#3  0x0804f185 in write_init_file (p=0xbfffcf38,
    version_string=0x7c <Address 0x7c out of bounds>, verbose_p=0)
    at prefs.c:704
#4  0x0805543b in demo_write_init_file (s=0xbfffcee0, p=0x7c)
    at demo-Gtk.c:894
#5  0x08056a26 in flush_dialog_changes_and_save (s=0xbfffcee0)
    at demo-Gtk.c:1449
#6  0x08057737 in list_select_changed_cb (selection=0x7c, data=0xbfffcee0)
    at demo-Gtk.c:1664
#7  0xb712ac87 in g_cclosure_marshal_VOID__VOID ()
   from /usr/lib/libgobject-2.0.so.0
#8  0xb7117ef7 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#9  0xb712a89e in g_signal_emit_by_name () from
#10 0xb71298e8 in g_signal_emit_valist () from
#11 0xb7129b24 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#12 0xb7502b0a in _gtk_tree_selection_internal_select_node ()
   from /usr/lib/libgtk-x11-2.0.so.0
#13 0xb75018c0 in gtk_tree_selection_select_path ()
   from /usr/lib/libgtk-x11-2.0.so.0
#14 0xb7501b30 in gtk_tree_selection_select_iter ()
   from /usr/lib/libgtk-x11-2.0.so.0
#15 0x08055829 in force_list_select_item (s=0x7c, list=0x8118b98,
    list_elt=124, scroll_p=1) at demo-Gtk.c:994
#16 0x080580c0 in scroll_to_current_hack (s=0xbfffcee0) at demo-Gtk.c:2042
#17 0x0805bf39 in main (argc=1, argv=0xbfffd0a4) at demo-Gtk.c:4386
Comment 4 Bastien Nocera 2004-06-10 11:55:39 EDT
This is the only interesting thing so far with my friend Valgrind:
==14815== Invalid write of size 4
==14815==    at 0x8058BCB: initialize_sort_map (demo-Gtk.c:2969)
==14815==    by 0x805A789: main (demo-Gtk.c:4285)
==14815==    by 0xB6BC7BC6: __libc_start_main (in /lib/libc-2.3.2.so)
==14815==    by 0x804E0B8: (within
==14815==    Address 0xB481C00C is 4 bytes before a block of size 800
==14815==    at 0xB74D3B2A: calloc (vg_replace_malloc.c:284)
==14815==    by 0x8058A80: initialize_sort_map (demo-Gtk.c:2908)
==14815==    by 0x805A789: main (demo-Gtk.c:4285)
==14815==    by 0xB6BC7BC6: __libc_start_main (in /lib/libc-2.3.2.so)
Comment 5 Bastien Nocera 2004-06-10 12:33:50 EDT
Created attachment 101038 [details]

The problem was caused by some memory trashing when building the initial list
of hacks, and the reverse list. Hacks that wouldn't be available would get the
ID of "-1" and try to access the array at -1, corrupting the memory (in this
case the configuration struct).
Comment 6 Bastien Nocera 2004-06-10 12:46:07 EDT
Adding to the errata candidate list.
Comment 7 Ray Strode [halfline] 2004-06-17 11:09:18 EDT
Marking MODIFIED while QA tests the fix.
Comment 8 Jay Turner 2004-09-01 22:26:13 EDT
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.