Memory Leak in 'ping' ?
Isaac Gutekunst
isaac.gutekunst at vecna.com
Tue Jul 14 15:18:51 UTC 2015
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.
I believe the wkspace command hang is unrelated.
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
More information about the users
mailing list