Description of problem: Running fcoeadm -i ethx before loading the fcoe module stack results in a backtrace getting dumped to the screen calling out "fcoeadm: free(): invalid pointer:". This occurs if fcoe does not get loaded during boot and an attempt to view the interface with fcoeadm is made. It also occurs if the module stack is unloaded all the way down through scsi_transport_fc. Version-Release number of selected component (if applicable): Fedora 11 preview, fcoeadm v1.0.7 How reproducible: Steps to Reproduce: # rmmod fcoe # rmmod libfc # fcoeadm -i eth2 # lsmod # rmmod scsi_transport_fc # fcoeadm -i eth2 Actual results: A call trace referenced invalid pointer is printed to console. Expected results: Should provide a useful error message rather then a backtrace. Additional info: The calltrace is as follows: [root@k24-64 iozone]# fcoeadm -i eth2 *** glibc detected *** fcoeadm: free(): invalid pointer: 0x000000351c6c71ab *** ======= Backtrace: ========= /lib64/libc.so.6[0x351c676716] fcoeadm[0x40389d] fcoeadm[0x403ddc] /lib64/libc.so.6(__libc_start_main+0xfd)[0x351c61e9dd] fcoeadm[0x401449] ======= Memory map: ======== 00400000-00406000 r-xp 00000000 08:05 164400 /usr/sbin/fcoeadm 00605000-00606000 rw-p 00005000 08:05 164400 /usr/sbin/fcoeadm 00606000-00608000 rw-p 00606000 00:00 0 00805000-00807000 rw-p 00005000 08:05 164400 /usr/sbin/fcoeadm 00b28000-00b49000 rw-p 00b28000 00:00 0 [heap] 351c200000-351c21f000 r-xp 00000000 08:05 547 /lib64/ld-2.9.90.so 351c41e000-351c41f000 r--p 0001e000 08:05 547 /lib64/ld-2.9.90.so 351c41f000-351c420000 rw-p 0001f000 08:05 547 /lib64/ld-2.9.90.so 351c600000-351c767000 r-xp 00000000 08:05 11498 /lib64/libc-2.9.90.so 351c767000-351c966000 ---p 00167000 08:05 11498 /lib64/libc-2.9.90.so 351c966000-351c96a000 r--p 00166000 08:05 11498 /lib64/libc-2.9.90.so 351c96a000-351c96b000 rw-p 0016a000 08:05 11498 /lib64/libc-2.9.90.so 351c96b000-351c970000 rw-p 351c96b000 00:00 0 351ca00000-351ca06000 r-xp 00000000 08:05 164399 /usr/lib64/libHBAAPI.so.2.0.2 351ca06000-351cc05000 ---p 00006000 08:05 164399 /usr/lib64/libHBAAPI.so.2.0.2 351cc05000-351cc06000 rw-p 00005000 08:05 164399 /usr/lib64/libHBAAPI.so.2.0.2 351ce00000-351ce02000 r-xp 00000000 08:05 117721 /lib64/libdl-2.9.90.so 351ce02000-351d002000 ---p 00002000 08:05 117721 /lib64/libdl-2.9.90.so 351d002000-351d003000 r--p 00002000 08:05 117721 /lib64/libdl-2.9.90.so 351d003000-351d004000 rw-p 00003000 08:05 117721 /lib64/libdl-2.9.90.so 3528000000-352801a000 r-xp 00000000 08:05 61008 /lib64/libgcc_s-4.4.0-20090427.so.1 352801a000-3528219000 ---p 0001a000 08:05 61008 /lib64/libgcc_s-4.4.0-20090427.so.1 3528219000-352821a000 rw-p 00019000 08:05 61008 /lib64/libgcc_s-4.4.0-20090427.so.1 7fdcd7a65000-7fdcd7a67000 rw-p 7fdcd7a65000 00:00 0 7fdcd7a7e000-7fdcd7a80000 rw-p 7fdcd7a7e000 00:00 0 7fffdfa6b000-7fffdfa80000 rw-p 7ffffffea000 00:00 0 [stack] 7fffdfbff000-7fffdfc00000 r-xp 7fffdfbff000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted [root@k24-64 iozone]#
A similar backtrace occurs if I use the -r, -s or -t flags with fcoeadm and an eth interface when the module stack is not loaded. The -c and -d however provide a useful message: [root@k24-64 iozone]# fcoeadm -c eth2 fcoeadm: Please make sure FCoE driver module is loaded! fcoeadm: Failed to create FCoE instance on eth2! [root@k24-64 iozone]#
Issue has been fixed in both rawhide and F11 (it will be available in updates after release).