Memory Leak in 'ping' ?
Gedare Bloom
gedare at rtems.org
Tue Jul 14 16:06:26 UTC 2015
On Tue, Jul 14, 2015 at 12:00 PM, Isaac Gutekunst
<isaac.gutekunst at vecna.com> wrote:
> We are using 4.11 with
>
> --enable-networking. Is the libbsd? It is using mbufs, so I'm guessing so.
>
This is libnetworking, and it should be avoided really, unless it
already works for your board. I'd suggest you switch your effort to
either libbsd or lwip.
libbsd: https://git.rtems.org/rtems-libbsd/
The libbsd is an updated port from freebsd, and if there are drivers
for your boards available in freebsd9+ then this is a good option.
> lwip might be the path of least resistance, especially since I have bare
> metal example for this target using lwip.
>
Yep.
> We may need full performance, but it's hard to say at this point.
>
Ideally you can switch over to libbsd if you find lwip is insufficient.
Gedare
>
> 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