I can reproduce this on latest fcoe-utils-1.0.17-3.el6:


# fcoeadm -i eth0
*** glibc detected *** fcoeadm: double free or corruption (out): 0x000000300000df00 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3000475676]
fcoeadm[0x403cf7]
fcoeadm[0x403d41]
fcoeadm[0x401d54]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x300041ec5d]
fcoeadm[0x401519]
======= Memory map: ========
00400000-00406000 r-xp 00000000 fd:00 2382238                            /usr/sbin/fcoeadm
00605000-00606000 rw-p 00005000 fd:00 2382238                            /usr/sbin/fcoeadm
01485000-014a6000 rw-p 00000000 00:00 0                                  [heap]
3000000000-300001e000 r-xp 00000000 fd:00 2228619                        /lib64/ld-2.12.so
300021d000-300021e000 r--p 0001d000 fd:00 2228619                        /lib64/ld-2.12.so
300021e000-300021f000 rw-p 0001e000 fd:00 2228619                        /lib64/ld-2.12.so
300021f000-3000220000 rw-p 00000000 00:00 0 
3000400000-3000575000 r-xp 00000000 fd:00 2228620                        /lib64/libc-2.12.so
3000575000-3000775000 ---p 00175000 fd:00 2228620                        /lib64/libc-2.12.so
3000775000-3000779000 r--p 00175000 fd:00 2228620                        /lib64/libc-2.12.so
3000779000-300077a000 rw-p 00179000 fd:00 2228620                        /lib64/libc-2.12.so
300077a000-300077f000 rw-p 00000000 00:00 0 
3000800000-3000802000 r-xp 00000000 fd:00 2228622                        /lib64/libdl-2.12.so
3000802000-3000a02000 ---p 00002000 fd:00 2228622                        /lib64/libdl-2.12.so
3000a02000-3000a03000 r--p 00002000 fd:00 2228622                        /lib64/libdl-2.12.so
3000a03000-3000a04000 rw-p 00003000 fd:00 2228622                        /lib64/libdl-2.12.so
7fa45150b000-7fa451521000 r-xp 00000000 fd:00 2228252                    /lib64/libgcc_s-4.4.5-20110117.so.1
7fa451521000-7fa451720000 ---p 00016000 fd:00 2228252                    /lib64/libgcc_s-4.4.5-20110117.so.1
7fa451720000-7fa451721000 rw-p 00015000 fd:00 2228252                    /lib64/libgcc_s-4.4.5-20110117.so.1
7fa451721000-7fa451724000 rw-p 00000000 00:00 0 
7fa451724000-7fa45172a000 r-xp 00000000 fd:00 2382216                    /usr/lib64/libHBAAPI.so.2.0.2
7fa45172a000-7fa451929000 ---p 00006000 fd:00 2382216                    /usr/lib64/libHBAAPI.so.2.0.2
7fa451929000-7fa45192a000 rw-p 00005000 fd:00 2382216                    /usr/lib64/libHBAAPI.so.2.0.2
7fa45193b000-7fa45193c000 rw-p 00000000 00:00 0 
7fff6f097000-7fff6f0ac000 rw-p 00000000 00:00 0                          [stack]
7fff6f178000-7fff6f179000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted (core dumped)

I cannot reproduce this issue with fcoe-utils-1.0.17-3.el6.x86_64.
I'm removing the dependency on bug #503165 since even if I could reproduce this, it wouldn't be related.

It was reproduced. Acked.

Fixed in CVS tag fcoe-utils-1.0.17-4.el6

Created attachment 479502 [details]
Do not free if scandir() fails

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause
    Running 'fcoeadm' without FCoE stack loaded.
Consequence
    'fcoeadm' tool tries to free an unallocated pointer, normally used to
    store sysfs directory structure.
Fix
    Only free the pointer if it was successfully allocated.
Result
    'fcoeadm' now free()'s its memory properly.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0743.html