Bug 254749

Summary: Yast2 printer module crashes saying "y2base: corrupted double-linked"
Product: [openSUSE] SUSE Linux 10.1 Reporter: Carlos Lange <carlosflange>
Component: YaST2Assignee: Michal Zugec <mzugec>
Status: RESOLVED DUPLICATE QA Contact: Jiri Srain <jsrain>
Severity: Major    
Priority: P5 - None CC: carlosflange
Version: Final   
Target Milestone: ---   
Hardware: x86-64   
OS: SuSE Linux 10.1   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Carlos Lange 2007-03-15 00:52:40 UTC
I have version 2.13.19 of yast2-printer and today I noticed that it crashes on 2 x86-64 machines (mine and one from a colleague) during the "database building".
The beginning of the error message says "*** glibc detected *** /usr/lib/YaST2/bin/y2base: corrupted double-linked list: 0x0000000001b32e60 ***" and the end (the simple error message) says "$ybindir/y2base $module "$@" qt "$Y2_GEOMETRY" $Y2QT_ARGS". I have a full backtrace, if it helps. The problem does not occur in our 32 bit machines with Suse 10.1.
Comment 1 Cyril Hrubis 2007-03-16 13:44:21 UTC
Please attach y2logs. If you are in doubt follow:

http://en.opensuse.org/Bugs/YaST

Thanks!
Comment 2 Carlos Lange 2007-03-18 17:41:58 UTC
The large (8MB) y2logs can be found here:
http://www.mece.ualberta.ca/~clange/y2logs.tgz
and the error message with backtrace I got when running "yast2 printer" from the konsole is here:
http://www.mece.ualberta.ca/~clange/yast2-printer.backtrace.txt

Notice that you will find the pertinent error on March 14 in y2logs. The error at the end (March 16) occurred when I had to interrupt my attempt to repeat the problem remotely. I tested it in 2 more machines at home and confirmed 32 bit working and 64 bit crashing.
Comment 3 Michal Zugec 2007-03-21 14:20:08 UTC
try to delete /var/lib/YaST2/ppd_db.ycp file and start yast2 printer again
Comment 4 Carlos Lange 2007-03-21 16:02:30 UTC
OK. It worked. After deleting the database, Yast rebuilt it and it seemed to be all there as before. Also repeated starts afterwards run without errors.

Since I found the same problem on different 64 bit machines in completely different LANs, i.e., different printer configurations, etc. I wonder how prevalent this bug is and if we should advertise the cure more widely. I mean, thesolution is not obvious and I would hesitate to delete the database, even if I knew which one it was. 

Should we consider the bug "fixed", if we advertise the "solution"?
Comment 5 Michal Zugec 2007-03-21 16:22:05 UTC
This is known bug fixed in update for 10.2. It was caused by update CUPS1.1 -> 1.2
What is your cups version?
Comment 6 Carlos Lange 2007-03-21 17:19:35 UTC
My cups is still 1.1.23, since I'm using 10.1. But from the info below it was updated in February. I checked my 32 bit machines and they were also updated, but their database was not corrupted.

pin cups:
Name        : cups                         Relocations: (not relocatable)
Version     : 1.1.23                       Vendor: SUSE LINUX Products GmbH
, Nuernberg, Germany
Release     : 40.12                         Build Date: Fri Jan 26 08:19:34 2007
Install Date: Thu Feb  1 02:35:29 2007      Build Host: lrupp1.suse.de
Comment 7 Michal Zugec 2007-03-22 07:06:48 UTC
Hm, maybe this is some gcc problem (in std library). As I remember I reproduced it also on 64-bit. 
But this bug was fixed in update for 10.2 some months ago.

> Should we consider the bug "fixed", if we advertise the "solution"?
Hm, you're first reproduced this on 10.1 so I don't think it's necessarily

Marked as duplicate 

*** This bug has been marked as a duplicate of bug 214265 ***