Bugzilla – Bug 330615
hal-cups-autoco[21191] general protection rip:2ac8a29d7bd0 rsp:7fff092bc998 error:0
Last modified: 2008-05-09 18:31:20 UTC
Every time I attempt to configure my printer the following crash happends Sep 30 22:59:13 hell kernel: usb 5-2: new device strings: Mfr=1, Product=2, SerialNumber=3 Sep 30 22:59:13 hell kernel: usb 5-2: Product: psc 1300 series Sep 30 22:59:13 hell kernel: usb 5-2: Manufacturer: hp Sep 30 22:59:13 hell kernel: usb 5-2: SerialNumber: BR4782G0DV9F Sep 30 22:59:13 hell kernel: usb 5-2: configuration #1 chosen from 1 choice Sep 30 22:59:14 hell kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 3 if 1 alt 0 proto 2 vid 0x03F0 pid 0x3B11 Sep 30 22:59:14 hell kernel: usbcore: registered new interface driver usblp Sep 30 22:59:14 hell kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver Sep 30 22:59:14 hell kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 Sep 30 22:59:14 hell kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Sep 30 22:59:14 hell kernel: Initializing USB Mass Storage driver... Sep 30 22:59:14 hell kernel: scsi4 : SCSI emulation for USB Mass Storage devices Sep 30 22:59:14 hell kernel: usb-storage: device found at 3 Sep 30 22:59:14 hell kernel: usb-storage: waiting for device to settle before scanning Sep 30 22:59:14 hell kernel: usbcore: registered new interface driver usb-storage Sep 30 22:59:14 hell kernel: USB Mass Storage support registered. Sep 30 22:59:14 hell kernel: hal-cups-autoco[21191] general protection rip:2ac8a29d7bd0 rsp:7fff092bc998 error:0 Sep 30 22:59:15 hell kernel: scsi 4:0:0:0: Direct-Access HP 1.00 PQ: 0 ANSI: 2 Sep 30 22:59:15 hell kernel: sd 4:0:0:0: [sdc] Attached SCSI removable disk Sep 30 22:59:15 hell kernel: sd 4:0:0:0: Attached scsi generic sg3 type 0 Sep 30 22:59:15 hell kernel: usb-storage: device scan complete If you have any hint about how to get any other valuable debug information about this problem, let me to know ;)
*** Bug 334546 has been marked as a duplicate of this bug. ***
*** Bug 335901 has been marked as a duplicate of this bug. ***
Quoting bug#332750 comment#4 : Considering these printers/scanners are probably among the most used in Linux, I increase severity a bit :-)
found an ugly workaround rpm -e cups-autoconfig and configure the printer manually with yast.
I can't reproduce this. Can you give me an strace of 'cups-autoconfig --debug --add --migrate-hal-printers' ?
When I run /usr/lib64/cups-autoconfig/cups-autoconfig --debug --add --migrate-hal-printers I see CUPS printer 'hp:/usb/OfficeJet_G85?serial=SGG15E2RV8VL' - 'officejetg85' Segmentation fault (core dumped) Then I run strace /usr/lib64/cups-autoconfig/cups-autoconfig --debug --add --migrate-hal-printers 1> /tmp/cups-autoconfig_out.txt 2> /tmp/cups-autoconfig_err.txt cups-autoconfig_out.txt is empty I will attach cups-autoconfig_err.txt When I run gdb /usr/lib64/cups-autoconfig/cups-autoconfig core I get GNU gdb 6.6.50.20070726-cvs Copyright (C) 2007 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-suse-linux"... (no debugging symbols found) Using host libthread_db library "/lib64/libthread_db.so.1". Reading symbols from /usr/lib64/libglib-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libglib-2.0.so.0 Reading symbols from /usr/lib64/libhal.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libhal.so.1 Reading symbols from /usr/lib64/libusb-0.1.so.4... (no debugging symbols found)...done. Loaded symbols for /usr/lib64/libusb-0.1.so.4 Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libuuid.so.1... (no debugging symbols found)...done. Loaded symbols for /lib64/libuuid.so.1 Reading symbols from /lib64/libdbus-1.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libdbus-1.so.3 Reading symbols from /usr/lib64/libcups.so.2... (no debugging symbols found)...done. Loaded symbols for /usr/lib64/libcups.so.2 Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2... (no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libssl.so.0.9.8... (no debugging symbols found)...done. Loaded symbols for /usr/lib64/libssl.so.0.9.8 Reading symbols from /usr/lib64/libcrypto.so.0.9.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libcrypto.so.0.9.8 Reading symbols from /lib64/libm.so.6... (no debugging symbols found)...done. Loaded symbols for /lib64/libm.so.6 Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libz.so.1... (no debugging symbols found)...done. Loaded symbols for /lib64/libz.so.1 Core was generated by `/usr/lib64/cups-autoconfig/cups-autoconfig --debug --add --migrate-hal-printers'. Program terminated with signal 11, Segmentation fault. #0 0x00002afc56400bd0 in strlen () from /lib64/libc.so.6 (gdb) where #0 0x00002afc56400bd0 in strlen () from /lib64/libc.so.6 #1 0x00002afc563d084d in vfprintf () from /lib64/libc.so.6 #2 0x00002afc56461680 in __vfprintf_chk () from /lib64/libc.so.6 #3 0x0000000000402864 in g_str_equal () #4 0x0000000000402e5f in g_str_equal () #5 0x0000000000404639 in g_str_equal () #6 0x00002afc563a8b54 in __libc_start_main () from /lib64/libc.so.6 #7 0x0000000000402229 in g_str_equal () #8 0x00007fff55894c18 in ?? () #9 0x0000000000000000 in ?? () I would love to install some debug rpms, but bug #335789 prevents me from doing so. Do you want the core file?
Created attachment 184279 [details] strace output.
The info needed is requested from Chris Rivera <crivera@novell.com>, however I comment #4 he has said he is now using a workaround. As a reporter of a duplicate of this bug (bug #335901), I have provided the needed info. Jarl
I would like to actually fix the problem. Can you reattach he strace output?
(In reply to comment #9 from Chris Rivera) > I would like to actually fix the problem. Can you reattach he strace output? So, precisely what info do you need that is not provided in comment #6 and comment #7 ? Please put me as the info-provider due to comment #8.
(In reply to comment #9 from Chris Rivera) > I would like to actually fix the problem. Can you reattach he strace output? > Chris: I dont have access to the affected system right now, however I will provide you the needed info as soon as I can, next week.
(In reply to comment #11 from Cristian Rodriguez) > (In reply to comment #9 from Chris Rivera) > > I would like to actually fix the problem. Can you reattach he strace output? > > > > Chris: I dont have access to the affected system right now, however I will > provide you the needed info as soon as I can, next week. > And again, what's missing in the info I provided in comment #6 and comment #7 ? Jarl
(In reply to comment #12 from Jarl Friis) > (In reply to comment #11 from Cristian Rodriguez) > > (In reply to comment #9 from Chris Rivera) > > > I would like to actually fix the problem. Can you reattach he strace output? > > > > > > > Chris: I dont have access to the affected system right now, however I will > > provide you the needed info as soon as I can, next week. > > > > And again, what's missing in the info I provided in comment #6 and comment #7 ? > > Jarl > The strace attachment in comment 7 has been removed. Also, you can grab the source packages and build the rpms with rpmbuild -ba. This will give you a debuginfo package that you can install (forcefully if necessary).
(In reply to comment #13 from Chris Rivera) > The strace attachment in comment 7 has been removed. Also, you can grab the > source packages and build the rpms with rpmbuild -ba. This will give you a > debuginfo package that you can install (forcefully if necessary). I see... But why have the strace in comment #7 been removed? strace output would be the same for non-debug and debug packages installed, right? Anyway, I can't install debug packages due to bug 335789 Jarl
Created attachment 187780 [details] patch #0 0x00002b525fc8fbd0 in strlen () from /lib64/libc.so.6 #1 0x00002b525fc5f84d in vfprintf () from /lib64/libc.so.6 #2 0x00002b525fcf0680 in __vfprintf_chk () from /lib64/libc.so.6 #3 0x0000000000402864 in log_it (debug=1, fmt=0x404ebc "CUPS printer '%s' - '%s'\n") at cups-autoconfig.c:90 #4 0x0000000000402e5f in get_cups_printers (list=0x7fff4bfea238) at cups-autoconfig.c:873 #5 0x0000000000404639 in main (argc=1, argv=0x7fff4bfea388) at cups-autoconfig.c:1139 #6 0x00002b525fc37b54 in __libc_start_main () from /lib64/libc.so.6 #7 0x0000000000402229 in _start () g_vfprintf() modifies the va_list pointer so that the second call fails. Proposed patch attached.
g_vfprintf (stderr, fmt, args); g_vfprintf (log_file, fmt, args); if (enable_debug && debug) g_vfprintf (log_file, fmt, args); FWIW, since this looked wrong to me anyway (having the additional print to log_file) I only kept the one in the if statement. Sorry if I missed a reason for the second.
And one more note: http://www.gnu.org/software/libc/manual/html_node/Variable-Arguments-Output.html#Variable-Arguments-Output says " In some other systems, the va_list pointer may become invalid after the call to vprintf, so you must not use va_arg after you call vprintf. Instead, you should call va_end to retire the pointer from service. However, you can safely call va_start on another pointer variable and begin fetching the arguments again through that pointer. Calling vprintf does not destroy the argument list of your function, merely the particular pointer that you passed to it. GNU C does not have such restrictions. You can safely continue to fetch arguments from a va_list pointer after passing it to vprintf, and va_end is a no-op. (Note, however, that subsequent va_arg calls will fetch the same arguments which vprintf previously used.) " That suggests that the crash shouldn't happen with gcc but it still does.
ok, found another post: http://gcc.gnu.org/ml/gcc/2000-11/msg00615.html "No, I think the glibc description is simply out-of-date, it's probably only true for x86 platforms." So that one only breaks for x86-64 obviously and that's why it's not reproducible for Chris?
I've submitted a fix for this to 10.3 and STABLE.
(In reply to comment #19 from Chris Rivera) > I've submitted a fix for this to 10.3 and STABLE. > Since the original reporter is using an "ugly workaround" and I am a reporter on a duplicate bug, I will in the role of the reporter reopen this bug, as it does not solve the problem with todays latest update. I still get a the followin message on my AMD64 installation: hal-cups-autoco[8439] general protection rip:2b03b3021bd0 rsp:7ffff8c556e8 error:0 and no popup letting me configure the printer. Jarl
(In reply to comment #20 from Jarl Friis) > I still get a the followin message on my AMD64 installation: > hal-cups-autoco[8439] general protection rip:2b03b3021bd0 rsp:7ffff8c556e8 > error:0 I see that my version is cups-autoconfig-0.1.0-27 and it has apparently been built sat 22 sep 2007 04:34:32 CEST and installed thu 04 okt 2007 22:28:22 CEST which is before your fix. Could it be that YOU has missed something? or is your fix in another package. Jarl
I submitted fixes for this, but they haven't been release to the public yet. They should be out shortly.
A fix is useless untill it is released. The status "FIXED" is uesless unless it reflects that the fix has been released. I suggest that you mark it fixed, when the fix is released.
Sorry buddy, but you don't determine how our big fixing process works. I mark the bugs as fixed when they're fixed.
(In reply to comment #24 from Chris Rivera) > Sorry buddy, but you don't determine how our big fixing process works. I mark > the bugs as fixed when they're fixed. You are right, I don't determine the bug fixing process flow, I didn't try to do that either. I am sorry if that was what it looked like. By the way: Who do decide the bug process flow for this open community project known as OpenSuSE? Anyway. May I suggest a new state for bugs than has been fixed (development complete) but not yet released (as an online patch)? And in this particular case (this bug): When can expect the fix to be released? And how are we notified so we can test it? Jarl
I filed a (currently internal) bug #362085 "Provide info whether or not a fixed package is available."
Bugzilla provides "keywords" which would fit quite well for that purpose. It would just need to be added to the patch process. Should be simply to automate between SWAMP and Bugzilla I think. (OT but as the other bug is internal...)
FYI: Bug #362085 (Novell-Bugzilla bugs are by default internal) was closed. I was told that "CLOSED" is the right status and I was pointed to https://bugzilla.novell.com/page.cgi?id=fields.html#resolution and to an an internal document which describes our internal workflow.
Any news as of when to see this fix in an online-update? Jarl
(In reply to comment #22 from Chris Rivera) > I submitted fixes for this, but they haven't been release to the public yet. > They should be out shortly. > Does anybody have any idea if/when this fix is ever going to reach the users (your customers)? Jarl