Memory Leak in 'ping' ?
Isaac Gutekunst
isaac.gutekunst at vecna.com
Tue Jul 14 16:16:27 UTC 2015
On 07/14/2015 12:06 PM, Gedare Bloom wrote:
> 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.
>
That's good to know. Luckily only about a day 'wasted'.
> 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.
>
This target is a Cortex-M4 and I can't find an existing driver.
>> 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.
>
Are the driver architectures similar enough?
What's a good starting point for learning about the FreeBSD network
stack, specifically writing a new device driver?
Isaac
P.S. I figured out how to disable signature blocks on replies, so
hopefully there won't be any more confidentiality statements. Sorry for
accidentally sending them.
> 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