On 2012-02-29 17:15, Michael S. Tsirkin wrote: > valgrind run shows a memory leak in slirp: > > ==21745== 360 (168 direct, 192 indirect) bytes in 1 blocks are definitely > lost in loss record 700 of 856 > ==21745== at 0x4A05FDE: malloc (vg_replace_malloc.c:236) > ==21745== by 0x298F01: socreate (socket.c:48) > ==21745== by 0x298FBC: tcp_listen (socket.c:601) > ==21745== by 0x296325: slirp_add_hostfwd (slirp.c:794) > ==21745== by 0x25E7BB: slirp_hostfwd (slirp.c:413) > ==21745== by 0x25F7C6: net_init_slirp (slirp.c:254) > ==21745== by 0x25BC72: net_client_init (net.c:1155) > ==21745== by 0x27C759: qemu_opts_foreach (qemu-option.c:1053) > ==21745== by 0x25AED1: net_init_clients (net.c:1452) > ==21745== by 0x24EC5A: main (vl.c:3277) > > comments?
The socket tcp_listen creates and returns is not handled by slirp_add_hostfwd, but it is part of the tcb queue of the slirp instance. Hmm, maybe we fail to clean up the tcb on slirp destruction, and that is the issue... Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
