>>-----Original Message----- >>From: ataraid-list-bounces@xxxxxxxxxx [mailto:ataraid-list- >>bounces@xxxxxxxxxx] On Behalf Of Matthias Koenig >>Sent: Tuesday, August 21, 2007 8:18 AM >>To: Heinz Mauelshagen; ataraid-list@xxxxxxxxxx >>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 >> _______________________________________________ Ataraid-list mailing list Ataraid-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ataraid-list
