On 26 Jun 2006, Neil Brown said:
> On Tuesday June 20, [EMAIL PROTECTED] wrote:
>> For some time, mdadm's been dumping core on me in my uClibc-built
>> initramfs. As you might imagine this is somewhat frustrating, not least
>> since my root filesystem's in LVM on RAID. Half an hour ago I got around
>> to debugging this.
>>
>> Imagine my surprise when I found that it was effectively guaranteed to
>> crash: map_dev() in util.c is stubbed out for uClibc builds, and
>> returns -1 at all times. That means that code in, among other places,
>> config.c:load_partitions() is guaranteed to segfault, which is a bit
>> tough if you're using the (sane) default `DEVICE partitions' in your
>> mdadm.conf.
>
> I'm confused. map_dev doesn't return -1, it returns NULL.
Yes, that was a typo on my part.
> And the code in load_partitions() handles a NULL return.
Er, what?
The code in load_partitions() in mdadm 2.5.1 and below says
,----[ config.c:load_partitions() ]
| name = map_dev(major, minor, 1);
|
| d = malloc(sizeof(*d));
| d->devname = strdup(name);
`----
So if map_dev() returns NULL, we do a strdup(NULL) -> crash inside
uClibc.
> So I cannot see why it would be core dumping.
> If you have more details, I'd be really interested.
Backtrace (against uClibc compiled with debugging symbols, tested
against a temporary RAID array on a loopback device):
(gdb) run
Starting program: /usr/packages/mdadm/i686-loki/mdadm.uclibc --assemble
--uuid=572aeae1:532641bf:49c9aec5:6036454d /dev/md127
Program received signal SIGSEGV, Segmentation fault.
0x080622f8 in strlen (s=0x0) at libc/string/i386/strlen.c:40
40 libc/string/i386/strlen.c: No such file or directory.
in libc/string/i386/strlen.c
(gdb) bt
#0 0x080622f8 in strlen (s=0x0) at libc/string/i386/strlen.c:40
#1 0x08062d1d in strdup (s1=0x0) at libc/string/strdup.c:30
#2 0x0804b0df in load_partitions () at config.c:247
#3 0x0804b77c in conf_get_devs (conffile=0x0) at config.c:715
#4 0x0804d685 in Assemble (st=0x0, mddev=0xbf9c753e "/dev/md127", mdfd=6,
ident=0xbf9c630c, conffile=0x0, devlist=0x0, backup_file=0x0, readonly=0,
runstop=0, update=0x0, homehost=0x0,
verbose=0, force=0) at Assemble.c:184
#5 0x08049d62 in main (argc=4, argv=0xbf9c6514) at mdadm.c:958
(gdb) frame 2
#2 0x0804b0df in load_partitions () at config.c:247
247 d->devname = strdup(name);
(gdb) info locals
name = 0x0
mp = 0xbf9c5a34 " 0 9873360 hda\n"
f = (FILE *) 0x807b018
buf = " 3 0 9873360 hda\n", '\0' <repeats 546 times>,
"1\000\000\000\000\000((ÿÿÿ\177\021", '\0' <repeats 15 times>,
"\021\000\000\000\231\231\231\031Z]\234¿\000\000(\005ÿÿÿ\177¼\\\234¿ÓU\006\bZ]\234¿\000\000\000\000\n",
'\0' <repeats 15 times>,
"d^\234¿ÏÈ\004\bX]\234¿\000\000\000\000\n\000\000\000\000\000Linux", '\0'
<repeats 60 times>, "loki\000)", '\0' <repeats 43 times>, "\006", '\0' <repeats
15 times>, "2.6.17-s\000\000\000\000à]\234¿ßÉ\005\b|]\234¿ð]\234¿", '\0'
<repeats 12 times>...
rv = (mddev_dev_t) 0x0
I hope the bug's more obvious now :)
> That said: utils doesn't handle the case for 'ftw not available' as
> well as it could. I will fix that.
The __UCLIBC_HAS_FTW__ macro in <features.h> is the right way to do that
for uClibc, as Luca noted.
--
`NB: Anyone suggesting that we should say "Tibibytes" instead of
Terabytes there will be hunted down and brutally slain.
That is all.' --- Matthew Wilcox
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
