Memory Leak in 'ping' ?

[Joel Sherrill]

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.

But I don't see a malloc() in ping.c. So it might be leaking in a called
method.

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.

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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985