Memory Leak in 'ping' ?
Isaac Gutekunst
isaac.gutekunst at vecna.com
Tue Jul 14 15:44:16 UTC 2015
On 07/14/2015 11:30 AM, Joel Sherrill wrote:
>
>
> On 7/14/2015 10:18 AM, Isaac Gutekunst wrote:
>> Hi All,
>>
>> I'm working on a network driver for the STM32F4, and as part of this
>> process wanted to see if the ping command could ping 127.0.0.1 even with
>> an empty driver.
>>
>> It works a few times, and then fails with 'error: no memory'.
>>
>> This target has 192K of RAM. What would be helpful for me is if a couple
>> people tried running ping, and then wkspace, and reporting whether they
>> see memory leaking.
>>
>> I could also be completely off target in my reasoning. Any other ideas
>> about why I'm seeing this behaviour.
>
> The commands were ported directly from FreeBSD. They ran as processes
> so could not free memory because exit() would clean up. They could also
> get away with leaking since there is more memory.
>
This makes sense. I'll continue working on the driver and figure out how
to test it later.
> But I don't see a malloc() in ping.c. So it might be leaking in a called
> method.
>
I've been looking in cpukit/libmisc/shell/main_ping.c
I've modified it to print the amount of bytes allocated on line 378.
I can't find a corresponding free call, but a few calls freeing 'buf',
which comes from ipsec_set_policy.
> It is also possible since the test is likely running in unified memory
> mode that it has consumed more memory for network stack buffers and this
> memory failure is really sendto() failing to allocate mbufs.
>
My network driver is certainly almost empty and probably not allocating
mbfus, since I'm still learning what those are :)
Aside: Besides the Networking supplement, and BSP development guide (and
source code), are there any good resources for learning about how to
create a network driver for RTEMS? I'm getting a bit caught up in what
part of some of the existing drivers is RTEMS specific and what is MAC
specific.
>> I believe the wkspace command hang is unrelated.
>
> Hard to guess at this point.
>
>> Lots more details below:
>>
>>
>> On startup:
>>
>> [/] # wkspace
>> C Program Heap and RTEMS Workspace are the same.
>> Number of free blocks: 4
>> Largest free block: 14784
>> Total bytes free: 14856
>> Number of used blocks: 119
>> Largest used block: 7832
>> Total bytes used: 49952
>> Size of the allocatable area in bytes: 64808
>> Minimum free size ever in bytes: 13824
>> Maximum number of free blocks ever: 5
>> Maximum number of blocks searched ever: 5
>> Lifetime number of bytes allocated: 57168
>> Lifetime number of bytes freed: 7216
>> Total number of searches: 215
>> Total number of successful allocations: 140
>> Total number of failed allocations: 0
>> Total number of successful frees: 21
>> Total number of successful resizes: 0
>> [/] # ping 127.0.0.1
>> Ping allocating 4536 bytes.
>> PING 127.0.0.1 (127.0.0.1): 56 data bytes
>> 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.770 ms
>> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.728 ms
>> 64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.728 ms
>> 64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.729 ms
>> 64 bytes from 127.0.0.1: icmp_seq=4 ttl=255 time=0.729 ms
>>
>> --- 127.0.0.1 ping statistics ---
>> 5 packets transmitted, 5 packets received, 0.0% packet loss
>> round-trip min/avg/max/stddev = 0.728/0.737/0.770 ms
>>
>>
>>
>>
>> Note: I added the "Ping allocating %d bytes." printf and modified ping
>> to allocate less memory in rtems_shell_globals_t in the outpackhdr and
>> packet.
>>
>>
>>
>>
>> After running ping once, the wkspace command no longer works and hangs
>> after printing "C Program Heap and RTEMS Workspace are the same."
>>
>> The debugger shows the error as RTEMS_FATAL_SOURCE_EXCEPTION.
>>
>> The dissasembly around the_error show it as inside of
>> Console_Configuration_Ports. I haven't investigated further.
>>
>> 2000110c: ldr r7, [pc, #700] ; (0x200013cc
>> <Console_Configuration_Ports+52>)
>> 2000110e: movs r1, r0
>> 20001110: asrs r0, r5, #5
>> 20001112: movs r0, #0
>> 20001114: ldr r3, [sp, #428] ; 0x1ac
>> 20001116: movs r3, r0
>> 20001118: asrs r0, r5, #5
>> 2000111a: movs r0, #0
>> 2000111c: ; <UNDEFINED> instruction: 0xfffdffff
>> 20001120: ldrh r4, [r0, #16]
>> 20001122: movs r0, #1
>> 20001124: ; <UNDEFINED> instruction: 0xf3982000
>> 20001128: lsls r4, r3, #16
>> 2000112a: movs r0, r0
>> 2000112c: ; <UNDEFINED> instruction: 0xf3982000
>> 20001130: ldrb r4, [r3, #22]
>> 20001132: ands r2, r0
>> 20001134: strb r5, [r6, #11]This target has 192K of RAM. What would be
>> helpful for me is if a couple people tried running ping, and then
>> wkspace, and reporting whether they see memory leaking.
>>
>> I believe the wkspace command hang is unrelated.
>>--
Isaac Gutekunst
Embedded Systems Software Engineer
isaac.gutekunst at vecna.com
www.vecna.com
Cambridge Research Laboratory
Vecna Technologies, Inc.
36 Cambridge Park Drive
Cambridge, MA 02140
Office: (617) 864-0636 x3069
Fax: (617) 864-0638
http://vecna.com
Better Technology, Better World (TM)
The contents of this message may be privileged and confidential.
Therefore, if this message has been received in error,
please delete it without reading it. Your receipt of this message is not
intended to waive any applicable privilege.
Please do not disseminate this message without the permission of the
author.
>> 20001136: movs r4, r0
>> 20001138: vrev64.32 d18, d1
>> 2000113c: str r6, [sp, #352] ; 0x160
>> 2000113e: movs r0, #1
>> 20001140: str r6, [sp, #256] ; 0x100
>> 20001142: movs r0, #1
>>
>>
>>
>>
>> Thanks,
>>
>> Isaac Gutekunst
>> Embedded Systems Software Engineer
>> isaac.gutekunst at vecna.com
>> www.vecna.com
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>>
>
More information about the users
mailing list