Ataraid-list Digest, Vol 42, Issue 15

[Fang, Ying]

>>-----Original Message-----
>>From: ataraid-list-bounces at redhat.com [mailto:ataraid-list-
>>bounces at redhat.com] On Behalf Of Matthias Koenig
>>Sent: Tuesday, August 21, 2007 8:18 AM
>>To: Heinz Mauelshagen; ataraid-list at redhat.com
>>Subject: dmraid segfault with DDF
>>

Hi Mathias,

Currently, dmraid only reads metadata on disks and cannot choose format
handlers. I guess that you have a metadata in ddf format. Could you send
me the dumps of "dmraid -n" and "dmraid -s -ccc"? 

The difference between your commands "dmraid -s -ccc -d" and "dmraid -s
-ccc -d xxxxx" is that the first one lists all raid sets and the latter
only shows the raid set xxxxx. As the first works, I guess something
fishy when the specific raid set name is processed. As far as I know,
dmraid has a special raid set type "t-group" for the isw and ddf
metadata format which may cause the failure of name matching.

I couldn't reproduce your test case without ddf1 metadata but the same
options work fine on isw metadata with a little bit tweak-using the
t-group raid set name other than a real raid name. Also, you may see the
name (p *rs) in you gdb when you set the compiler option to -O0 from
-O2(the default setting).

Thanks,
Ying

>>Hi,
>>
>>we have a report on dmraid segfaulting with a Intel S5000VSA Board.
>>The segfault seems only to happen when given with the raid set
>>argument:
>>dmraid -r -vvv -d
>>or
>>dmraid -s -ccc -d
>>works, but
>>dmraid -s -ccc -d
ddf1_4c534920202020201000005500000000330adc0c00000a28
>>segfaults.
>>
>>I acquired a core file (I do not have the hardware to test this),
>showing
>>the following backtrace:
>>
>>(gdb) bt
>>#0  0x00002b66ceac7a00 in main_arena () from /lib64/libc.so.6
>>#1  0x000000000040b592 in group_set (lc=0x628010,
>>    name=0x7fffdc96288f
>>"ddf1_4c534920202020201000005500000000330adc0c00000a28") at
>>metadata/metadata.c:657
>>#2  0x00000000004049bf in build_sets (lc=0x628010, sets=<value
>optimized
>>out>)
>>    at toollib.c:69
>>#3  0x0000000000404041 in perform (lc=0x628010, argv=0x7fffdc960f48)
>>    at commands.c:648
>>#4  0x0000000000403b23 in main (argc=<value optimized out>,
>>    argv=0x7fffdc960f48) at dmraid.c:34
>>
>>This seems bogus, because main_arena is a symbol from libc
>>(not even a function AFAIK).
>>In the last reasonable frame I get the following info:
>>
>>(gdb) frame 1
>>#1  0x000000000040b592 in group_set (lc=0x628010,
>>    name=0x7fffdc96288f
>>"ddf1_4c534920202020201000005500000000330adc0c00000a28") at
>>metadata/metadata.c:657
>>657             return rd->fmt->group(lc, rd);
>>(gdb) info locals
>>rd = (struct raid_dev *) 0x2b66ceac79c0
>>rs = (struct raid_set *) 0x628540
>>(gdb) p *rs
>>$5 = {list = {next = 0x6377c0, prev = 0x2b6600736b73}, sets = {next =
>0x20,
>>    prev = 0x1011}, devs = {next = 0x732f007366737973,
>>    prev = 0x7366737973007379}, total_devs = 7827968, found_devs =
>3153968,
>>  name = 0x30203000777200 <Address 0x30203000777200 out of bounds>,
>>  stride = 0, type = 0, flags = 0, status = 0}
>>
>>Currently, I am getting out of clue, what's going on here.
>>Possibly this issue might also be related to
>>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180950
>>
>>Matthias
>>