OK I already saw that simply increasing the heap is no solution, because it's already maximum size: mm_initialize: Heap: start=0x20008924 size=227036 mm_addregion: Region 1: base=0x20008924 size=227024
-- Florian Wehmeyer TFW Tech-Solutions On Seg, 2020-05-11 at 14:31 -0300, Florian Wehmeyer wrote: > looking more into the memory allocation debug, there is a lot more > dynamic allocation (obviously) when loading the elf program than > when loading the same program as built-in.. > So, seems the problem is due to a high heap fragmentation, what > explains that a call to dmesg can also make the system crash.. > So, maybe my question should be, is increasing the heap a solution > for > that? If yes, how do I increase it? > BR, > Florian > prints of debug output with my comments: > calling the Elf program (Neo_Ledtest): > PID PRI POLICY TYPE NPX STATE EVENT SIGMASK STACK > COMMAND > 0 0 FIFO Kthread N-- Ready 00000000 000000 > Idle > Task > 1 224 FIFO Kthread --- Waiting Signal 00000000 002028 > hpwork > 2 100 FIFO Task --- Running 00000000 002028 > init > 3 80 RR pthread --- Waiting Semaphore 00000000 001564 > netinit 0x0 > 4 100 FIFO Task --- Waiting Semaphore 00000000 002004 > Telnet daemon0 > 6 100 FIFO Task --- Waiting Semaphore 00000000 006116 > Neo_Ledtest > nsh> cat > /proc/6/stack > > StackBase: 0x0x200214b0 > > > StackSize: 6116 > StackEnd = 0x200214b0 - 6116d = 0x2001FCCC > nsh> dmesg //called right after calling the elf program, > after flushing the > syslog.. > mm_free: Freeing > 0x2001d010 > mm_malloc: Allocated 0x2000cbd0, size > 64 > mm_malloc: Allocated 0x20009710, size > 32 > mm_malloc: Allocated 0x2000cc10, size > 48 > mm_malloc: Allocated 0x2001d010, size > 48 > mm_malloc: Allocated 0x2001d040, size > 528 > mm_malloc: Allocated 0x2001d250, size > 448 > mm_malloc: Allocated 0x2001d410, size > 6624 > mm_malloc: Allocated 0x2001edf0, size > 528 > mm_malloc: Allocated 0x2001f000, size > 2064 > mm_malloc: Allocated 0x2001f810, size > 48 > mm_malloc: Allocated 0x2001f840, size > 48 > mm_malloc: Allocated 0x2001f870, size > 48 > mm_malloc: Allocated 0x2001f8a0, size > 48 > mm_malloc: Allocated 0x2001f8d0, size > 48 > mm_malloc: Allocated 0x2001f900, size > 48 > mm_malloc: Allocated 0x2001f930, size > 48 > mm_malloc: Allocated 0x2001f960, size > 48 > mm_malloc: Allocated 0x2001f990, size > 48 > mm_malloc: Allocated 0x2001f9c0, size > 48 > mm_malloc: Allocated 0x2001f9f0, size > 48 > mm_malloc: Allocated 0x2001fa20, size > 48 > mm_malloc: Allocated 0x2001fa50, size > 48 > mm_malloc: Allocated 0x2001fa80, size > 48 > mm_malloc: Allocated 0x2001fab0, size > 48 > mm_malloc: Allocated 0x2001fae0, size > 48 > mm_malloc: Allocated 0x2001fb10, size > 48 > mm_malloc: Allocated 0x2001fb40, size > 48 > mm_malloc: Allocated 0x2001fb70, size > 48 > mm_malloc: Allocated 0x2001fba0, size > 48 > mm_malloc: Allocated 0x2001fbd0, size > 48 > mm_malloc: Allocated 0x2001fc00, size > 48 > mm_malloc: Allocated 0x2001fc30, size > 48 > mm_malloc: Allocated 0x2001fc60, size > 48 > mm_malloc: Allocated 0x2001fc90, size > 48 > mm_malloc: Allocated 0x2001fcc0, size > 48 > mm_malloc: Allocated 0x2001fcf0, size > 48 > mm_malloc: Allocated 0x2001fd20, size > 48 > mm_malloc: Allocated 0x2001fd50, size > 48 > mm_malloc: Allocated 0x2001fd80, size > 48 > mm_malloc: Allocated 0x2001fdb0, size > 48 > mm_malloc: Allocated 0x2001fde0, size > 48 > mm_malloc: Allocated 0x2001fe10, size > 48 > mm_malloc: Allocated 0x2001fe40, size > 48 > mm_malloc: Allocated 0x2001fe70, size > 48 > mm_malloc: Allocated 0x2001fea0, size > 48 > mm_malloc: Allocated 0x2001fed0, size > 48 > mm_malloc: Allocated 0x2001ff00, size > 48 > mm_malloc: Allocated 0x2001ff30, size > 48 > mm_malloc: Allocated 0x2001ff60, size > 48 > mm_malloc: Allocated 0x2001ff90, size > 48 > mm_malloc: Allocated 0x2001ffc0, size > 48 > mm_malloc: Allocated 0x2001fff0, size > 48 > mm_malloc: Allocated 0x20020020, size > 48 > mm_free: Freeing > 0x2001f000 > mm_free: Freeing > 0x2001f930 > mm_free: Freeing > 0x2001fd50 > mm_free: Freeing > 0x2001fa50 > mm_free: Freeing > 0x20020020 > mm_free: Freeing > 0x2001fff0 > mm_free: Freeing > 0x2001f840 > mm_free: Freeing > 0x2001f9c0 > mm_free: Freeing > 0x2001ffc0 > mm_free: Freeing > 0x2001ff90 > mm_free: Freeing > 0x2001fab0 > mm_free: Freeing > 0x2001fa80 > mm_free: Freeing > 0x2001fed0 > mm_free: Freeing > 0x2001fd20 > mm_free: Freeing > 0x2001fe70 > mm_free: Freeing > 0x2001fe40 > mm_free: Freeing > 0x2001ff30 > mm_free: Freeing > 0x2001ff60 > mm_free: Freeing > 0x2001fea0 > mm_free: Freeing > 0x2001ff00 > mm_free: Freeing > 0x2001fba0 > mm_free: Freeing > 0x2001fb40 > mm_free: Freeing > 0x2001fae0 > mm_free: Freeing > 0x2001fe10 > mm_free: Freeing > 0x2001fcf0 > mm_free: Freeing > 0x2001fb10 > mm_free: Freeing > 0x2001fde0 > mm_free: Freeing > 0x2001fdb0 > mm_free: Freeing > 0x2001fd80 > mm_free: Freeing > 0x2001fa20 > mm_free: Freeing > 0x2001fcc0 > mm_free: Freeing > 0x2001fc90 > mm_free: Freeing > 0x2001fc60 > mm_free: Freeing > 0x2001fc30 > mm_free: Freeing > 0x2001fc00 > mm_free: Freeing > 0x2001fbd0 > mm_free: Freeing > 0x2001fb70 > mm_free: Freeing > 0x2001f9f0 > mm_free: Freeing > 0x2001f990 > mm_free: Freeing > 0x2001f960 > mm_free: Freeing > 0x2001f900 > mm_free: Freeing > 0x2001f8d0 > mm_free: Freeing > 0x2001f8a0 > mm_free: Freeing > 0x2001f870 > mm_free: Freeing > 0x2001f810 > mm_free: Freeing > 0x2001d250 > mm_free: Freeing > 0x2001edf0 > mm_free: Freeing > 0x2001d040 > mm_free: Freeing > 0x2001d010 > mm_free: Freeing > 0x2000cc10 > mm_free: Freeing > 0x20009710 > mm_malloc: Allocated 0x2001d010, size > 256 > mm_malloc: Allocated 0x2001edf0, size > 2064 > mm_malloc: Allocated 0x2001f600, size > 832 > mm_malloc: Allocated 0x2000cc10, size > 64 > mm_malloc: Allocated 0x2001d110, size > 80 > mm_malloc: Allocated 0x2001d160, size > 80 > mm_malloc: Allocated 0x2001d1b0, size > 80 > mm_malloc: Allocated 0x2001d200, size > 256 > mm_malloc: Allocated 0x2001f940, size > 832 > mm_malloc: Allocated 0x2001d300, size > 64 > mm_malloc: Allocated 0x2001d340, size > 80 > mm_malloc: Allocated 0x2001d390, size > 80 > mm_malloc: Allocated 0x2001fc80, size > 80 > mm_malloc: Allocated 0x2001fcd0, size 6160 //here allocating my > (ELF) > tasks stack, just befor my stack-end 0x2001FCCC > mm_malloc: Allocated 0x20009710, size > 32 > mm_free: Freeing > 0x2001d110 > mm_free: Freeing > 0x2001d160 > mm_free: Freeing > 0x2001d1b0 > mm_free: Freeing > 0x2000cc10 > mm_free: Freeing > 0x2001d410 > mm_free: Freeing > 0x2000cbd0 > mm_free: Freeing > 0x2001edf0 > mm_free: Freeing > 0x2001d010 > mm_free: Freeing > 0x2001f600 > mm_free: Freeing > 0x20009710 > mm_malloc: Allocated 0x2001d3e0, size 1008 //here allocating 1K in > my > task, heap not within my > stack > > > mm_free: Freeing 0x2001d3e0 //after short usage test, > freeing the memory within my task > mm_malloc: Allocated 0x2000cbd0, size 64 //allocation for dmesg: > CONFIG_STDIO_BUFFER_SIZE > mm_malloc: Allocated 0x20009710, size 32 //allocation for dmesg > mm_malloc: Allocated 0x2000a8d0, size > 32 //also > mm_free: Freeing > 0x2000a8d0 > mm_free: Freeing > 0x20009710 > mm_free: Freeing > 0x2000cbd0 > mm_malloc: Allocated 0x2001d3e0, size 528 //also caused by dmesg, > maybe > CONFIG_NSH_IOBUFFER_SIZE > //16K space left to my > stack-end > //all other tasks, > pthreads > etc shown by ps command have stack allocated before this address!! > ---------------------------- > calling the Neo_Ledtest as builtin: > nsh> > ps > > > PID PRI POLICY TYPE NPX STATE EVENT SIGMASK STACK > COMMAND > 0 0 FIFO Kthread N-- Ready 00000000 000000 > Idle > Task > 1 224 FIFO Kthread --- Waiting Signal 00000000 002028 > hpwork > 2 100 FIFO Task --- Running 00000000 002028 > init > 3 80 RR pthread --- Waiting Semaphore 00000000 001564 > netinit 0x0 > 4 100 FIFO Task --- Waiting Semaphore 00000000 002004 > Telnet daemon0 > 6 100 FIFO Task --- Waiting Semaphore 00000000 006116 > Neo_Ledtest > nsh> > > > nsh> > > > nsh> cat > /proc/6/stack > > StackBase: 0x0x20020a50 > > > StackSize: 6116 > StackEnd = 0x200214b0 - 6116d = 0x2001F26C > nsh> > dmesg > > > mm_free: Freeing > 0x2001d010 > mm_malloc: Allocated 0x2000cbd0, size > 64 > mm_malloc: Allocated 0x20009710, size > 32 > mm_malloc: Allocated 0x2000cc10, size > 48 > mm_free: Freeing > 0x2000cc10 > mm_free: Freeing > 0x20009710 > mm_free: Freeing > 0x2000cbd0 > mm_malloc: Allocated 0x2001d010, size > 256 > mm_malloc: Allocated 0x2001d110, size > 832 > mm_malloc: Allocated 0x2000cbd0, size > 64 > mm_malloc: Allocated 0x2000cc10, size > 80 > mm_malloc: Allocated 0x2001d450, size > 80 > mm_malloc: Allocated 0x2001d4a0, size > 80 > mm_malloc: Allocated 0x2001d4f0, size > 6160 > mm_malloc: Allocated 0x2001ed00, size > 256 > mm_malloc: Allocated 0x2001ee00, size > 832 > mm_malloc: Allocated 0x2001f140, size > 64 > mm_malloc: Allocated 0x2001f180, size > 80 > mm_malloc: Allocated 0x2001f1d0, size > 80 > mm_malloc: Allocated 0x2001f220, size > 80 > mm_malloc: Allocated 0x2001f270, size 6160 //here is my builtin task > stack allocated, just before calculated stack- > end > mm_malloc: Allocated 0x20009710, size > 32 > mm_free: Freeing > 0x2000cc10 > mm_free: Freeing > 0x2001d450 > mm_free: Freeing > 0x2001d4a0 > mm_free: Freeing > 0x2000cbd0 > mm_free: Freeing > 0x2001d4f0 > mm_free: Freeing > 0x2001d010 > mm_free: Freeing > 0x2001d110 > mm_free: Freeing > 0x20009710 > mm_malloc: Allocated 0x2001d010, size 7008 //allocating 7000Bytes > in > my task > mm_free: Freeing > 0x2001d010 //freeing > > > mm_malloc: Allocated 0x2000cbd0, size 64 //dmesg > stuff.. > mm_malloc: Allocated 0x20009710, size 32 //dmesg > stuff.. > mm_malloc: Allocated 0x2000a8d0, size 32 //dmesg > stuff.. > mm_free: Freeing > 0x2000a8d0 > mm_free: Freeing > 0x20009710 > mm_free: Freeing > 0x2000cbd0 > mm_malloc: Allocated 0x2001d010, size 528 //dmesg stuff.. > > //8.5K left until my stack-end > > -- > Florian WehmeyerTFW Tech-SolutionsOn Seg, 2020-05-11 at 11:35 -0300, > Florian Wehmeyer wrote: > > > > Hi all, > > > > again a question related to the execution of external / elf > > programs: > > > > When I use malloc within the running elf program, allocating more > > than > > 1K bytes, malloc seems to work (doesn't return NULL), but when I > > use > > that memory (memset) I get a assertion/Kernel panic.. > > > > Funnily this does not happen if I use the same program as built-in > > program (the one which is already in ROM flash).. Here I can > > allocate > > and use 8K or more without any problem.. > > > > So, it seems the binary loader itself consumes a lot of memory, > > decreasing the available heap.. I was not able to solve that > > problem > > even increasing all available and possibly related stacksizes in > > .config > > After loading the elf file, even running dmesg can cause that > > assertion.. (using RAMLOG with 8K buffer and memory debug output) . > > free shows about 130K of free RAM.. > > > > in the memory debug output I can see that the periodical > > allocation > > at > > about 10K of distance of the next stack-end (means stackbase minus > > stacksize, knowing stack decreases), which is my app.. > > so, I thought allocate 2K on the heap should not be a problem. > > > > > > Any ideas about any configuration that's important here? > > > > > > Many thanks & BR, > > > > > > -- > > Florian WehmeyerTFW Tech-Solutions
