Memory Leak in 'ping' ?

Gedare Bloom gedare at rtems.org
Tue Jul 14 16:44:16 UTC 2015 

On Tue, Jul 14, 2015 at 12:16 PM, Isaac Gutekunst
<isaac.gutekunst at vecna.com> wrote:
>
>
> 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?
>
No. You would have to write the driver for libbsd, so "switch over"
really means invest time to improve performance. Perhaps it would be
easier to optimize lwip, but I can't say for sure.

> What's a good starting point for learning about the FreeBSD network stack,
> specifically writing a new device driver?
>
see the libbsd.txt file in the rtems-libbsd.git repo.

> 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.
Appreciated.

>
>> 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