Bug 443332 - nash segfaults updating kernel
nash segfaults updating kernel
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
8
All Linux
low Severity high
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
: 446720 447976 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-20 15:58 EDT by Scott R. Godin
Modified: 2009-05-06 11:01 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 01:24:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
log produced by the aforementioned command requested by #fedora-devel (2.29 KB, application/x-gzip)
2008-04-20 15:58 EDT, Scott R. Godin
no flags Details
tgz of 1 of the 82 corefiles produced by aforementioned command (134.34 KB, application/x-gzip)
2008-04-20 16:03 EDT, Scott R. Godin
no flags Details
Full output of "yum update" (2.14 KB, text/plain)
2008-05-07 16:43 EDT, Steven P. Ulrick
no flags Details
Full output of "yum update": kernel-2.6.24.7-92.fc8 (2.28 KB, text/plain)
2008-05-14 20:50 EDT, Steven P. Ulrick
no flags Details
patch to fix a buffer overrun which is a potential crash source (1.03 KB, patch)
2008-07-02 01:46 EDT, Kuba Ober
no flags Details | Diff

  None (edit)
Description Scott R. Godin 2008-04-20 15:58:39 EDT
Description of problem: nash segfaults massively dropping 82 coredumpfiles in / 


Version-Release number of selected component (if applicable):
nash-6.0.19-4.fc8/
mkinitrd-6.0.19-4.fc8

How reproducible: every time


Steps to Reproduce:
1. updated via yum from kernel-2.6.23.15-137.fc8 to kernel-2.6.24.4-64.fc8
2. nash crashed/segfaulted during the update process

per questions from #fedora-devel I set coredumpsize to unlimited and manually 
ran 
export KERNEL_VERSION=2.6.24.4-64.fc8
mkinitrd -v -f /boot/initrd-$KERNEL_VERSION.img $KERNEL_VERSION > log 2>&1
with similar and/or exact same results
  
Actual results:
attaching log and coredumps as tgz 

Expected results:
clean update

Additional info:
Comment 1 Scott R. Godin 2008-04-20 15:58:39 EDT
Created attachment 303068 [details]
log produced by the aforementioned command requested by #fedora-devel
Comment 2 Scott R. Godin 2008-04-20 16:03:37 EDT
Created attachment 303069 [details]
tgz of 1 of the 82 corefiles produced by aforementioned command
Comment 3 Steven P. Ulrick 2008-05-07 16:42:06 EDT
I have a similar situation: whenever I attempt to run "yum update", the result
is that "nash" segfaults:

<snip>
nash received SIGSEGV!  Backtrace (11):
<snip>
error: %post(kernel-2.6.24.5-85.fc8.i686) scriptlet failed, signal 2
<snip>

The thing that makes this "similar" in my opinion, and not "identical" is that
as far as I know, I am not receiving masses of coredumpfiles.  I just receive
the error that I am going to create an attachment for.

This is reproducible 100% of the time that I try to run "yum update" on the
kernel referred to above.
Comment 4 Steven P. Ulrick 2008-05-07 16:43:56 EDT
Created attachment 304809 [details]
Full output of "yum update"
Comment 5 Zdenek Kabelac 2008-05-12 08:03:07 EDT
I've also seen this problem  (with Linus's git tree)

# make modules_install install
  INSTALL arch/x86/ia32/ia32_aout.ko
  INSTALL arch/x86/kernel/cpu/cpufreq/p4-clockmod.ko
....
  INSTALL sound/synth/emux/snd-emux-synth.ko
  INSTALL sound/synth/snd-util-mem.ko
  DEPMOD  2.6.26-rc2
sh /home/linux-2.6/arch/x86/boot/install.sh 2.6.26-rc2 arch/x86/boot/bzImage
System.map "/boot"
device-mapper: table ioctl failed: No such device or address
device-mapper: deps ioctl failed: No such device or address
nash received SIGSEGV!  Backtrace (22):
/sbin/nash[0x40d093]
/lib64/libc.so.6[0x39bbc322a0]
/lib64/libdevmapper.so.1.02(dm_task_get_deps+0x4)[0x39c380e004]
/usr/lib64/libnash.so.6.0.52[0x326f40ec1b]
/usr/lib64/libnash.so.6.0.52(nashDmDevGetType+0x38)[0x326f40fb60]
/usr/lib64/libnash.so.6.0.52[0x326f411abc]
/usr/lib64/libnash.so.6.0.52[0x326f411b84]
/usr/lib64/libnash.so.6.0.52[0x326f411d23]
/usr/lib64/libnash.so.6.0.52(nash_dev_tree_process_bdev+0x95)[0x326f410a44]
/usr/lib64/libnash.so.6.0.52[0x326f410cfb]
/usr/lib64/libnash.so.6.0.52[0x326f410e0d]
/usr/lib64/libnash.so.6.0.52(nash_dev_tree_add_sysfs_dir+0x3e)[0x326f410c76]
/usr/lib64/libnash.so.6.0.52(nash_dev_tree_populate_from_sysfs+0x1c)[0x326f410ea5]
/usr/lib64/libnash.so.6.0.52(nashBdevIterNewPoll+0x7d)[0x326f40c62a]
/usr/lib64/libnash.so.6.0.52[0x326f40c989]
/usr/lib64/libnash.so.6.0.52(nashFindFsByLabel+0x24)[0x326f40cafe]
/usr/lib64/libnash.so.6.0.52(nashAGetPathBySpec+0x43)[0x326f40cc30]
/sbin/nash[0x4088a1]
/sbin/nash[0x40cf49]
/sbin/nash[0x40d576]
/lib64/libc.so.6(__libc_start_main+0xfa)[0x39bbc1e32a]
/sbin/nash[0x404509]

I've installed mkinitrd-debuginfo package and the problem so far disappeared.
If it will show again I'll add more details.
Comment 6 Steven P. Ulrick 2008-05-14 20:49:29 EDT
This bug is still an issue when attempting to update to the latest updated
Fedora 8 Kernel: 2.6.24.7-92.fc8
Comment 7 Steven P. Ulrick 2008-05-14 20:50:57 EDT
Created attachment 305423 [details]
Full output of "yum update": kernel-2.6.24.7-92.fc8
Comment 8 Zdenek Kabelac 2008-05-22 07:42:37 EDT
Here is what I can get from the debugger:

-----------

#5  strncpy (s1=0x3b4aa1ee7f "", s2=0x0, n=31) at strncpy.c:41
#6  0x0000003b4a80fbbe in nashDmDevGetType (nc=Could not find the frame base for
"nashDmDevGetType".
) at dm.c:988
#7  0x0000003b4a811abc in nash_dev_node_guess_type_from_bdev (nc=Could not find
the frame base for "nash_dev_node_guess_type_from_bdev".
) at devtree.c:980


possible fix:
dm.c:988 - you should add check for if (obj && obj->type != NULL)


-----------
#5  0x0000003b4f80e004 in dm_task_get_deps (dmt=0x829640) at ioctl/libdm-iface.c:977
#6  0x0000003b4a80ec1b in dm_iter_begin (names=Could not find the frame base for
"dm_iter_begin".
) at dm.c:546

possible fix - you should replace call nashDmTaskNew(DM_DEVICE_DEPS,...) with a
similar construct you are using for nashDmGetInfo() - i.e. call
dm_task_get_info() afer dm_task_run to check where device has an info.exist
valid - otherwise the call dm_task_get_deps might fail as some parameters in
task structure could be NULL which gives segfault.
Comment 9 Milan Broz 2008-05-23 08:41:28 EDT
problem is easily reproducible - just create dm-device without table and run
mkinitrd:

# dmsetup create bad --notable

# mkinitrd --force-lvm-probe -v /boot/initrd-2.6.26-rc3.img 2.6.26-rc3
Creating initramfs
nash received SIGSEGV!  Backtrace (21):
/sbin/nash[0x40d093]
/lib64/libc.so.6[0x7fed03ce62a0]
/lib64/libc.so.6(strncpy+0x11)[0x7fed03d35201]
/usr/lib64/libnash.so.6.0.52(nashDmDevGetType+0x96)[0x627bbe]
/usr/lib64/libnash.so.6.0.52[0x629abc]
/usr/lib64/libnash.so.6.0.52[0x629b84]
/usr/lib64/libnash.so.6.0.52[0x629d23]
/usr/lib64/libnash.so.6.0.52(nash_dev_tree_process_bdev+0x95)[0x628a44]
/usr/lib64/libnash.so.6.0.52[0x628cfb]
/usr/lib64/libnash.so.6.0.52[0x628e0d]
/usr/lib64/libnash.so.6.0.52(nash_dev_tree_add_sysfs_dir+0x3e)[0x628c76]
/usr/lib64/libnash.so.6.0.52(nash_dev_tree_populate_from_sysfs+0x1c)[0x628ea5]
/usr/lib64/libnash.so.6.0.52(nashBdevIterNewPoll+0x7d)[0x62462a]
/usr/lib64/libnash.so.6.0.52[0x624989]
/usr/lib64/libnash.so.6.0.52(nashFindFsByUUID+0x24)[0x624b24]
/usr/lib64/libnash.so.6.0.52(nashAGetPathBySpec+0x73)[0x624c60]
/sbin/nash[0x4088a1]
/sbin/nash[0x40cf49]
/sbin/nash[0x40d576]
/lib64/libc.so.6(__libc_start_main+0xfa)[0x7fed03cd232a]
/sbin/nash[0x404509]

rpm -q nash
nash-6.0.52-2.fc9.x86_64

Comment 10 Kuba Ober 2008-07-02 01:46:25 EDT
Created attachment 310760 [details]
patch to fix a buffer overrun which is a potential crash source

Fixes the problem for me, at least.
Comment 11 Kuba Ober 2008-07-02 02:12:42 EDT
Note that this patch doesn't necessarily fix this bug, so it probably doesn't 
apply here, even though it seems to be a valid fix for 439600. Sorry for the 
noise.
Comment 12 Alexey Kuznetsov 2008-07-02 05:02:07 EDT
*** Bug 446720 has been marked as a duplicate of this bug. ***
Comment 13 Knut J BJuland 2008-07-02 10:31:23 EDT
It also applies to Fedora 9. please update.
Comment 14 Paul "KK4DUY" Bransford 2008-10-18 11:37:16 EDT
In my case, removing as many USB devices from my system as possible, resolved this.

When it worked, I only had an empty hub, keyboard, and UPS plugged in. Previously, I had a gamepad, external storage media, printer, mouse, MIDI controller, plugged in as well.
Comment 15 Paul "KK4DUY" Bransford 2008-10-18 11:41:00 EDT
Info from /sbin/lsusb:

/sbin/lsusb 
Bus 001 Device 018: ID 0763:0115 Midiman KeyRig 25
Bus 001 Device 017: ID 03f0:2b17 Hewlett-Packard LaserJet 1020
Bus 001 Device 016: ID 1058:1100 Western Digital Technologies, Inc. 
Bus 001 Device 014: ID 1532:000d Razer USA, Ltd 
Bus 001 Device 012: ID 050d:0234 Belkin Components F5U234 USB 2.0 4-Port Hub
Bus 001 Device 011: ID 0424:2504 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 003: ID 046d:c216 Logitech, Inc. Dual Action Gamepad
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 046a:0048 Cherry GmbH 
Bus 002 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

/sbin/lsusb -t
Bus#  5
`-Dev#   1 Vendor 0x1d6b Product 0x0001
Bus#  4
`-Dev#   1 Vendor 0x1d6b Product 0x0001
  `-Dev#   3 Vendor 0x046d Product 0xc216
Bus#  3
`-Dev#   1 Vendor 0x1d6b Product 0x0001
Bus#  2
`-Dev#   1 Vendor 0x1d6b Product 0x0001
  |-Dev#   2 Vendor 0x0764 Product 0x0501
  `-Dev#   3 Vendor 0x046a Product 0x0048
Bus#  1
`-Dev#   1 Vendor 0x1d6b Product 0x0002
  |-Dev#  12 Vendor 0x050d Product 0x0234
  | |-Dev#  17 Vendor 0x03f0 Product 0x2b17
  | |-Dev#  14 Vendor 0x1532 Product 0x000d
  | `-Dev#  18 Vendor 0x0763 Product 0x0115
  |-Dev#  11 Vendor 0x0424 Product 0x2504
  `-Dev#  16 Vendor 0x1058 Product 0x1100
Comment 16 Alexey Kuznetsov 2008-10-18 12:04:55 EDT
duplicate of bug 440661
Comment 17 Bug Zapper 2008-11-26 05:31:45 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 18 Bug Zapper 2009-01-09 01:24:13 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 19 Jeremy Katz 2009-05-06 11:01:58 EDT
*** Bug 447976 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.