On Tue, Jan 21, 2020 at 03:57:53PM +0000, Hefty, Sean wrote:
> > 	ch = rdma_create_event_channel();
> > 	if (ch == NULL)
> > 		printf("rdma_create_event_channel failed\n");
> > 
> > 	ret = rdma_create_id(ch, &id, NULL, RDMA_PS_TCP);
> > 	if (ret != 0)
> > 		printf("rdma_create_id failed\n");
> > 
> > 	ret = rdma_bind_addr(id, (struct sockaddr *) &ipoib_addr);
> > 
> > 	if (ret != 0)
> > 		printf("rdma_bind_addr failed\n");
> > 
> > 	rdma_destroy_event_channel(ch);
> 
> This call should fail, since there's still a valid id open on it.

Yes, you are right. After switch rdma_destroy_event_channel and
rdma_destroy_id, the memory leak issue is gone.

But we still observe file descriptor leak.

 cm]$ ip addr show | grep -w inet  | grep mlx4_ib0$
    inet 172.31.0.230/24 brd 172.31.0.255 scope global dynamic noprefixroute mlx4_ib0

 cm]$ ./fd.exe 172.31.0.230
pid = 30530
dlopen/dlclose test: round 0    

cm]$ valgrind -v --trace-children=yes --track-fds=yes --log-fd=2 --error-limit=no --leak-check=full --show-possibly-lost=yes --track-origins=yes --show-reachable=yes --keep-debuginfo=yes ./fd.exe 172.31.0.230 2>&1 | tee trace.log
<== ignore many lines, please see attachment trace.log for details ==>
==30545== FILE DESCRIPTORS: 4 open at exit.
==30545== Open file descriptor 4: /dev/infiniband/uverbs0
==30545==    at 0x53487D2: open (in /usr/lib64/libc-2.28.so)
==30545==    by 0x5632EF8: UnknownInlinedFun (fcntl2.h:53)
==30545==    by 0x5632EF8: open_cdev_internal (open_cdev.c:52)
==30545==    by 0x56331C3: open_cdev (open_cdev.c:141)
==30545==    by 0x562C7F3: verbs_open_device (device.c:345)
==30545==    by 0x50482D1: ucma_open_device (cma.c:325)
==30545==    by 0x50482D1: ucma_init_device.part.2 (cma.c:343)
==30545==    by 0x504855F: ucma_init_device (cma.c:474)
==30545==    by 0x504855F: ucma_get_device (cma.c:469)
==30545==    by 0x50487A9: ucma_query_addr (cma.c:714)
==30545==    by 0x5048883: rdma_bind_addr2 (cma.c:884)
==30545==    by 0x5048F34: rdma_bind_addr (cma.c:901)
==30545==    by 0x400A59: test (fd.c:40)
==30545==    by 0x400B7D: main (fd.c:94)


In this simple program, only one file descriptor leaked. We can trigger
a lot of instance file descriptordescriptor leak with dapl. Please see attachment dapl-librdmacm-leak.txt for details.

Thanks