Hi, I assume I am writing to the correct address. I would like to report a memory leak in libdat2.so.2.0.0 that I noticed while using valgrind.
I isolated it to an application that does not actually make any calls on libdat2. All it does is link it in with g++ using -ldat2. I am running on Fedora 12 and using export LD_DEBUG="libs" I could see that when my program ran, the loader was calling init on the library at startup and fini at the end. Again, I am not making any calls on the library, merely linking it in (as a test, I linked it into an application that did not previously use it). Even so, I see the following: ==14551== 14 bytes in 14 blocks are definitely lost in loss record 47 of 285 ==14551== at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==14551== by 0x6FE49B2: dat_sr_get_token (dat_osd.h:226) ==14551== by 0x6FE5206: dat_sr_parse_entry (udat_sr_parser.c:706) ==14551== by 0x6FE5508: dat_sr_load (udat_sr_parser.c:268) ==14551== by 0x6FE7FB5: dat_sr_init (dat_sr.c:84) ==14551== by 0x6FE74E9: dat_init (dat_init.c:117) ==14551== by 0x6FE7FF5: ??? (in /usr/lib64/libdat2.so.2.0.0) ==14551== by 0x6FE3B1A: ??? (in /usr/lib64/libdat2.so.2.0.0) ==14551== ==14551== 4,944 (4,592 direct, 352 indirect) bytes in 14 blocks are definitely lost in loss record 270 of 285 ==14551== at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==14551== by 0x6FE7D4E: dat_sr_insert (dat_osd.h:226) ==14551== by 0x6FE547E: dat_sr_parse_entry (udat_sr_parser.c:343) ==14551== by 0x6FE5508: dat_sr_load (udat_sr_parser.c:268) ==14551== by 0x6FE7FB5: dat_sr_init (dat_sr.c:84) ==14551== by 0x6FE74E9: dat_init (dat_init.c:117) ==14551== by 0x6FE7FF5: ??? (in /usr/lib64/libdat2.so.2.0.0) ==14551== by 0x6FE3B1A: ??? (in /usr/lib64/libdat2.so.2.0.0) I assume this is happening when libdat2.so is initialized, but no corresponding free is happening when the loader calls its fini function (or destructor). So I thought I would report it. Thank you, Perry King -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
