depmod segfaulting

[Lonni J Friedman]

Anyone else seeing depmod segfault with the latest Fedora 7 kernel?
Every time it runs, it segfaults.

I ran it through strace, but this is what it shows before dying:

open("/lib/modules/2.6.22.4-65.fc7/updates",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
fstat64(4, {st_mode=S_IFDIR|0755, st_size=6, ...}) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
getdents(4, /* 2 entries */, 4096)      = 32
getdents(4, /* 0 entries */, 4096)      = 0
close(4)                                = 0
open("/lib/modules/2.6.22.4-65.fc7/weak-updates",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
fstat64(4, {st_mode=S_IFDIR|0755, st_size=6, ...}) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
getdents(4, /* 2 entries */, 4096)      = 32
getdents(4, /* 0 entries */, 4096)      = 0
close(4)                                = 0
getdents(3, /* 0 entries */, 4096)      = 0
close(3)                                = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

[Development discussions related to Fedora]

Lonni J Friedman wrote:
>  Anyone else seeing depmod segfault with the latest Fedora 7 kernel?
>  Every time it runs, it segfaults.
>  
>  I ran it through strace, but this is what it shows before dying:
>  
>  open("/lib/modules/2.6.22.4-65.fc7/updates",
>  O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4 
...
I'm on:
Linux davidtdesktop 2.6.22.4-65.fc7 #1 SMP Tue Aug 21 22:36:56 EDT 2007 
i686 athlon i386 GNU/Linux
since Sun 26th, uptime up 3 days,  3:42, no problems at all.

What exactly where you doing when you saw the SF ?

DaveT.

[Lonni J Friedman]

On 8/29/07, David Timms <dtimms(a)iinet.net.au&gt; wrote:
>  Lonni J Friedman wrote:
>  > Anyone else seeing depmod segfault with the latest Fedora 7 kernel?
>  > Every time it runs, it segfaults.
>  >
>  > I ran it through strace, but this is what it shows before dying:
>  >
>  > open("/lib/modules/2.6.22.4-65.fc7/updates",
>  > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
>  ...
>  I'm on:
>  Linux davidtdesktop 2.6.22.4-65.fc7 #1 SMP Tue Aug 21 22:36:56 EDT 2007
>  i686 athlon i386 GNU/Linux
>  since Sun 26th, uptime up 3 days,  3:42, no problems at all.
>
>  What exactly where you doing when you saw the SF ? 
Running "depmod -aq".

[Andy Green]

Somebody in the thread at some point said:

>  Anyone else seeing depmod segfault with the latest Fedora 7 kernel?
>  Every time it runs, it segfaults.
>  
>  I ran it through strace, but this is what it shows before dying: 
The strace just shows it peering into directories and then closing the
handle.

If you install the debuginfo RPM

# yum --enablerepo=fedora-debuginfo install module-init-tools-debuginfo

and gdb

# yum install gdb

and run it through gdb

# gdb --args depmod -a
... blah blah...
(gdb) run

and see if you get a nice backtrace

-Andy

[Lonni J Friedman]

On 8/29/07, Andy Green <andy(a)warmcat.com&gt; wrote:
>  Somebody in the thread at some point said:
>
>  > Anyone else seeing depmod segfault with the latest Fedora 7 kernel?
>  > Every time it runs, it segfaults.
>  >
>  > I ran it through strace, but this is what it shows before dying:
>
>  The strace just shows it peering into directories and then closing the
>  handle.
>
>  If you install the debuginfo RPM
>
>  # yum --enablerepo=fedora-debuginfo install module-init-tools-debuginfo
>
>  and gdb
>
>  # yum install gdb
>
>  and run it through gdb
>
>  # gdb --args depmod -a
>  ... blah blah...
>  (gdb) run
>
>  and see if you get a nice backtrace
>
>  -Andy 
########
(gdb) run
Starting program: /sbin/depmod -a

Program received signal SIGSEGV, Segmentation fault.
0x0059aee8 in strcmp () from /lib/libc.so.6
(gdb) bt
#0  0x0059aee8 in strcmp () from /lib/libc.so.6
#1  0x0804ba7c in load_section32 (hdr=0xb1601b8, secname=0x8059c47
"__ksymtab_strings", size=0xbf9510e8,
    conv=0) at moduleops_core.c:18
#2  0x0804c064 in load_symbols32 (module=0xadbfe88) at moduleops_core.c:34
#3  0x0804ae48 in main (argc=2, argv=Cannot access memory at address 0x5aadd37c
) at depmod.c:687
#4  0x00542f70 in __libc_start_main () from /lib/libc.so.6
#5  0x08048ea1 in _start ()
#######

I'm guessing that #3 is the problem (cannot access memory at address).
 I guess I could file a bug if no one else has any suggestions?
thanks

[Andy Green]

Somebody in the thread at some point said:

>  0x0059aee8 in strcmp () from /lib/libc.so.6
>  (gdb) bt
>  #0  0x0059aee8 in strcmp () from /lib/libc.so.6
>  #1  0x0804ba7c in load_section32 (hdr=0xb1601b8, secname=0x8059c47
>  "__ksymtab_strings", size=0xbf9510e8,
>      conv=0) at moduleops_core.c:18
>  #2  0x0804c064 in load_symbols32 (module=0xadbfe88) at moduleops_core.c:34
>  #3  0x0804ae48 in main (argc=2, argv=Cannot access memory at address 0x5aadd37c
>  ) at depmod.c:687
>  #4  0x00542f70 in __libc_start_main () from /lib/libc.so.6
>  #5  0x08048ea1 in _start ()
>  #######
>  
>  I'm guessing that #3 is the problem (cannot access memory at address).
>   I guess I could file a bug if no one else has any suggestions? 
__ksymtab_strings seems to be a section in vmlinux / z... is it possible
that the /boot/vmlinuz-2.6.blah file is unhappy?  Or /boot is not
mounted, /tmp is full, anything like that?

-Andy

[Lonni J Friedman]

On 8/29/07, Andy Green <andy(a)warmcat.com&gt; wrote:
>  Somebody in the thread at some point said:
>
>  > 0x0059aee8 in strcmp () from /lib/libc.so.6
>  > (gdb) bt
>  > #0  0x0059aee8 in strcmp () from /lib/libc.so.6
>  > #1  0x0804ba7c in load_section32 (hdr=0xb1601b8, secname=0x8059c47
>  > "__ksymtab_strings", size=0xbf9510e8,
>  >     conv=0) at moduleops_core.c:18
>  > #2  0x0804c064 in load_symbols32 (module=0xadbfe88) at moduleops_core.c:34
>  > #3  0x0804ae48 in main (argc=2, argv=Cannot access memory at address 0x5aadd37c
>  > ) at depmod.c:687
>  > #4  0x00542f70 in __libc_start_main () from /lib/libc.so.6
>  > #5  0x08048ea1 in _start ()
>  > #######
>  >
>  > I'm guessing that #3 is the problem (cannot access memory at address).
>  >  I guess I could file a bug if no one else has any suggestions?
>
>  __ksymtab_strings seems to be a section in vmlinux / z... is it possible
>  that the /boot/vmlinuz-2.6.blah file is unhappy?  Or /boot is not
>  mounted, /tmp is full, anything like that? 
Nope, none of those are the case.  I booted into
/boot/vmlinuz-2.6.22.4-65.fc7 and saw this problem immediately after
the first boot (when I built/installed a new module).  /tmp is not
full.  /boot is definitely mounted.

thanks.