Memory Leak in 'ping' ?

Tue Jul 14 15:49:48 UTC 2015

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