Memory Leak in 'ping' ?
Isaac Gutekunst
isaac.gutekunst at vecna.com
Tue Jul 14 16:00:29 UTC 2015
We are using 4.11 with
--enable-networking. Is the libbsd? It is using mbufs, so I'm guessing so.
lwip might be the path of least resistance, especially since I have bare
metal example for this target using lwip.
We may need full performance, but it's hard to say at this point.
Isaac
On 07/14/2015 11:49 AM, Gedare Bloom wrote:
> What version of RTEMS are you using, and what networking stack?
>
> For 4.10 there is the libnetworking or port lwip, for 4.11 there is
> libnetworking, libbsd, and lwip.
>
> I'd recommend 4.11 with libbsd or lwip. for a small target, lwip is a
> good option unless you need full performance which can be hard to
> squeeze out of lwip.
>
> -Gedare
>
>
>
> On Tue, Jul 14, 2015 at 11:44 AM, Isaac Gutekunst
> <isaac.gutekunst at vecna.com> wrote:
>> 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
>>>>
>>>
>>
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
More information about the users
mailing list