Bug 190938 - kudzu - sefault in module_upgrade
kudzu - sefault in module_upgrade
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kudzu (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
:
: 193112 193472 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-06 17:43 EDT by Michal Jaegermann
Modified: 2014-03-16 22:59 EDT (History)
3 users (show)

See Also:
Fixed In Version: 1.2.35-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-08 15:37:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace output for 'module_upgrade' (43.67 KB, text/plain)
2006-05-06 17:43 EDT, Michal Jaegermann
no flags Details
patch for this issue (867 bytes, application/octet-stream)
2006-05-08 15:31 EDT, Bill Nottingham
no flags Details

  None (edit)
Description Michal Jaegermann 2006-05-06 17:43:58 EDT
Description of problem:

The last kernel update caused the following:

/var/tmp/rpm-tmp.82525: line 6:  6771 Segmentation fault
/usr/sbin/module_upgrade 2.6.16-1.2111_FC5

Running the last line by itself indeed consistently segfaults.
Tail of 'strace' output shows this:

open("/etc/modprobe.conf", O_RDONLY)    = 3
stat64("/etc/modprobe.conf", {st_mode=S_IFREG|0644, st_size=956, ...}) = 0
read(3, "# Note: for use under 2.4, chang"..., 956) = 956
close(3)                                = 0
open("/etc/sysconfig/network-scripts/ifcfg-eth0", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0600, st_size=99, ...}) = 0
read(3, "DEVICE=eth0\nBOOTPROTO=static\n# B"..., 99) = 99
close(3)                                = 0
open("/etc/sysconfig/network-scripts/ifcfg-eth0:0", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0600, st_size=100, ...}) = 0
read(3, "DEVICE=eth0:0\nBOOTPROTO=static\n#"..., 100) = 100
close(3)                                = 0
open("/etc/sysconfig/network-scripts/ifcfg-eth1", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0600, st_size=83, ...}) = 0
read(3, "DEVICE=eth1\nBOOTPROTO=static\nIPA"..., 83) = 83
close(3)                                = 0
open("/etc/sysconfig/network-scripts/ifcfg-lo", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=254, ...}) = 0
read(3, "DEVICE=lo\nIPADDR=127.0.0.1\nNETMA"..., 254) = 254
close(3)                                = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

The system in question is updated through few generations and
/etc/sysconfig/network-scripts/ifcfg-lo looks as follows:

DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
# If you're having problems with gated making 127.0.0.0/8 a martian,
# you can change this to something else (255.255.255.255, for example)
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback

Whatever is in that file segfaulting looks a tad extreme.
A full strace output attached.

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

How reproducible:
every time
Comment 1 Michal Jaegermann 2006-05-06 17:43:59 EDT
Created attachment 128696 [details]
strace output for 'module_upgrade'
Comment 2 Bill Nottingham 2006-05-08 14:31:11 EDT
Can you get a gdb backtrace?
Comment 3 Michal Jaegermann 2006-05-08 15:24:44 EDT
> Can you get a gdb backtrace?
I was afraid that you will ask. :-)

(gdb) r
Starting program: /usr/sbin/module_upgrade
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xd87000

Program received signal SIGSEGV, Segmentation fault.
0x00acbaba in strcmp () from /lib/libc.so.6
(gdb) bt
#0  0x00acbaba in strcmp () from /lib/libc.so.6
#1  0x0804ae1c in main (argc=1768122485, argv=0x6463682d)
    at module_upgrade.c:252
#2  0x00a777e4 in __libc_start_main () from /lib/libc.so.6
#3  0x0804a4b1 in _start ()
(gdb) f 1
#1  0x0804ae1c in main (argc=1768122485, argv=0x6463682d)
    at module_upgrade.c:252
252                                         if (!strcmp(l->newnames[i],
tmpdev->driver)) {
(gdb) l
247                                       snprintf(alias, 64, "usb-controller%d",x);
248                                     else
249                                       snprintf(alias, 64,
"usb-controller");250                                     for (tmpdev = devs[0];
tmpdev; tmpdev = tmpdev->next)
251                                       for (i=0; l->newnames[i]; i++)
252                                         if (!strcmp(l->newnames[i],
tmpdev->driver)) {
253                                                 addAlias(cf,alias,
tmpdev->driver, CM_REPLACE);
254                                                 changed++;
255                                                
openlog("kudzu",0,LOG_USER);256                                                
syslog(LOG_NOTICE,"changed %s alias from %s to %s",
(gdb) print l
$1 = (struct listent *) 0x8bfa0a8
(gdb) print i
No symbol "i" in current context.
(gdb) p tmpdev
$2 = (struct device *) 0x8c20758
(gdb) p l->newnames[0]
$3 = 0x8bfa0e0 "uhci-hcd"
(gdb) p l->newnames[1]
$4 = 0x0
(gdb) p tmpdev->driver
$5 = 0x0
(gdb) p devs[0]
$6 = (struct device *) 0x8c20758
(gdb) p *$6
$11 = {next = 0x8c20500, index = 0, type = CLASS_OTHER, bus = BUS_PCI,
  device = 0x0, driver = 0x0,
  desc = 0x8c207b8 "Promise Technology, Inc. PDC20265 (FastTrak100
Lite/Ultra100)", detached = 0, classprivate = 0x0, newDevice = 0x804fda0
<pciNewDevice>,
  freeDevice = 0x804fc90 <pciFreeDevice>,
  writeDevice = 0x804ff60 <pciWriteDevice>,
  compareDevice = 0x804fe80 <pciCompareDevice>}

Hm, looks like that there is no provision for tmpdev->driver ending up
as NULL.  Legitimate?
Comment 4 Bill Nottingham 2006-05-08 15:31:35 EDT
Created attachment 128761 [details]
patch for this issue

Wow, you've got a really old alias there. The check is in the code for
everything but usb; not sure why it was left out (nor why this would suddenly
trigger on the new kernel).
Comment 5 Bill Nottingham 2006-05-08 15:37:47 EDT
Fixed in 1.2.35-1.
Comment 6 Michal Jaegermann 2006-05-08 15:43:59 EDT
> Wow, you've got a really old alias there.

You mean in /etc/modprobe.conf?  I really cannot tell you why.  This is
a system which went through a number of updates.  The most recent one from
FC3 to FC5.
Comment 7 Bill Nottingham 2006-05-08 15:45:39 EDT
Just to confirm, you did have:

alias usb-controllerX {usb-uhci|uhci|usb-ohci}?
Comment 8 Michal Jaegermann 2006-05-08 15:54:18 EDT
Yes, indeed, there is a line

alias usb-controller usb-uhci

in /etc/modprobe.conf
Comment 9 Bill Nottingham 2006-05-25 12:31:01 EDT
*** Bug 193112 has been marked as a duplicate of this bug. ***
Comment 10 Bill Nottingham 2006-05-30 02:26:35 EDT
*** Bug 193472 has been marked as a duplicate of this bug. ***

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