Memory leak in NDK / DHCPClose

Hi,

a little more details. Using this code in a separate thread:

printf("Before adding DCHP");
_mmCheck(MMCHECK_MAP, &printf);

CfgAddEntry(obj->stackConfig, CFGTAG_SERVICE, CFGITEM_SERVICE_DHCPCLIENT, 0, sizeof(dhcp), (UINT8*)&dhcp, 0);

printf("After adding DCHP");
_mmCheck(MMCHECK_MAP, &printf);

TaskSleep(3000);

if (CfgGetEntry(obj->stackConfig, CFGTAG_SERVICE, CFGITEM_SERVICE_DHCPCLIENT, 1, &dhcpService) > 0)
{
	CfgRemoveEntry(obj->stackConfig, dhcpService);
}

printf("After removing DCHP");
_mmCheck(MMCHECK_MAP, &printf);

I get this output (cleaned up):

Before adding DCHP
(9216/49152 mmAlloc: 26/0/1, mmBulk: 0/0/0)

After adding DCHP
(9216/49152 mmAlloc: 27/0/1, mmBulk: 1/0/0)

dhcpPacketReceive 0

After removing DCHP
(12288/49152 mmAlloc: 30/0/2, mmBulk: 1/0/1)

The 

dhcpPacketReceive 0

is from dhcpsock.c, dhcpPacketReceive:

printf("dhcpPacketReceive 0\n");
pLease->ReceivedSize = (int)recv( pLease->Sock, pLease->Buffer,BUFFER_SIZE, 0 );
printf("dhcpPacketReceive 1\n");

so I know the DHCP state machine is in the dhcpPacketReceive call.

You can see three calls of mmFree() are missing. 

In DHCPClose, there is fdCloseSession( pLease->dhcpTASK ); which (as far as I understand) should also close the socket but when you set a breakpoint in DHCPClose before the dhcpSocketClose you can clearly see that the LockCount is 1.

Btw. the DHCP server was not running! Otherwise there would be a DHCP answer and so the DHCP state machine would not stay in dhcpPacketReceive long enough to hit the leak.

Hi,

you can find a test case here:

When running this I get this output (cleaned):

Before adding DCHP
(9216/49152 mmAlloc: 13/0/0, mmBulk: 0/0/0)

After adding DCHP
(9216/49152 mmAlloc: 14/0/0, mmBulk: 1/0/0)

After removing DCHP
(12288/49152 mmAlloc: 17/0/1, mmBulk: 1/0/1)

Please note that the DHCP server was not running.

Hi Murat,

any news on that? Can you confirm this issue?

Robert

Hi Robert,

Sorry for late reply on this, one of the issues is that the dropbox doc you shared is not accessible from our corporate network due to IT policy, so it has been a hassle to get to it. Do you mind attaching or pasting it on this thread? We will take a look and investigate the issue from there,

Murat

Hi,

sorry, I did not found a way how to do this. Now I did :-)

Robert

5241.helloWorld.c

Hi Robert,

Which version of the NDK and BIOS are you using?  Also, which hardware platform?

Thanks,

Steve

Hi Robert,

I've been looking at this issue.  First off, I had a question for you regarding this:

Robert Kuhn said:

The 

dhcpPacketReceive 0

is from dhcpsock.c, dhcpPacketReceive:

?

1 2 3

printf("dhcpPacketReceive 0\n"); pLease->ReceivedSize = (int)recv( pLease->Sock, pLease->Buffer,BUFFER_SIZE, 0 ); printf("dhcpPacketReceive 1\n");

so I know the DHCP state machine is in the dhcpPacketReceive call.

Are you positive that this is the only printout that exists?  (I'm referring to the "dhcpPacketReceive 0").

In my test, in the console in CCS, I do see a single print, just as you show.  But, when I look at the SysMin buffer in ROV, I see that there are many of these prints happening.  Can you please confirm that you don't see any other prints in the SysMin buffer?

--------

Looking more closely at the output of the memory dump:

Before adding DCHP
(9216/49152 mmAlloc: 13/0/0, mmBulk: 0/0/0)

--> the above shows that there have been a total of 13 calls to mmAlloc, 0 calls to mmFree. It also shows 0 calls to mmBulkAlloc and 0 calls for mmBulkFree.

-----------

After adding DCHP
(9216/49152 mmAlloc: 14/0/0, mmBulk: 1/0/0)

--> at this point, there has been one additional call to mmAlloc (as 13 incremented to 14).  And, 1 call to mmBulkAlloc.  No calls to either free function.

So, adding DHCP client resulted in 1 mmAlloc, and 1 mmBulkAlloc.

-----------

After removing DCHP
(12288/49152 mmAlloc: 17/0/1, mmBulk: 1/0/1)

--> here, we see that the number of mmAlloc calls increased to 17, but there was also a call to mmFree, as that stat got incremented.  It also shows that the mmBulkAlloc was cleaned up as the calls to mmBulkFree is now 1.

It seems that there were 3 additional calls to mmAlloc in the time between the last two calls to mmCheck().  From this info, it seems that the one mmFree call could have been the one from DHCP, but it also could have been corresponding to one of the 3 additional calls to mmAlloc.

Can you print the socket table out, in addition to the mmCheck?  I'm curious if you see the same DHCP socket left open.  You can print out the socket tables using the code in this thread.

-------------

Note that I also ran the same experiment as you did. However, I'm not sure that I'm hitting the lock count > 0 issue you are seeing:

Before adding DCHP
(12288/18432 mmAlloc: 23/0/3, mmBulk: 2/0/2)

--> 23 mmAllocs, 3 mmFree calls, zero net mmBulkAlloc calls

After adding DCHP
(12288/18432 mmAlloc: 27/0/3, mmBulk: 3/0/2)

--> 4 additional mmAllocs, no additional mmFree calls, 1 additional mmBulkAlloc, no additional mmBulkFree

(looks like adding DHCP resulted in 4 additional mmAllocs and 1 bulk alloc)

After removing DCHP
(12288/18432 mmAlloc: 27/0/7, mmBulk: 3/0/3)

--> closing DHCP resulted in 4 additional calls to mmFree, and all bulk allocations have been deallocated.

So, I'm seeing all allocations taken care of, but again, I'm not sure I'm hitting the same lock count issue.

Steve

Hi Steven,

you will only see the leak when there is no DHCP server running. So printing the sockets makes (as far as I see) no sense then. I did as advised but the output was only:

Local IP LPort Foreign IP FPort State
--------------- ----- --------------- ----- -----------

as expected. So did you had a DHCP server running while testing? 

Hi Robert,

Robert Kuhn said:

So did you had a DHCP server running while testing?

No, there was no DHCP server present. In fact, I ran the test with the Ethernet cable unplugged ... now I'm just trying to think if that could have caused any different behavior.

I wanted to see a print out of the sockets to see if the socket create/used by DHCP was deleted or left hanging around.  Note that the DHCP client creates a UDP socket and tries to communicate with the DHCP server, regardless of whether or not any such DHCP server actually exists on the network or not.  Or maybe I'm misunderstanding why you think there would be no socket ...

Steve