SOLVED: [SLOEBER] program crashes

Development environment specific, Arduino, Eclipse, VS2013,Em::Blocks etc
Post Reply
User avatar
RogerClark
Posts: 7171
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Libmaple problem, program crashes with call to malloc.

Post by RogerClark » Wed Aug 16, 2017 9:46 am

Bill


I don't know the details of this, as I didnt write the original code. It was written my Leaflabs but they abandoned it 3 or 4 years ago.
Unfortunately Leaflabs don't answer questions e.g. as issues on their github repo which still contains the original libmaple code.
So we can only speculate on these sorts of design decisions

User avatar
Pito
Posts: 1593
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Libmaple problem, program crashes with call to malloc.

Post by Pito » Wed Aug 16, 2017 10:40 am

You seem to misunderstand how community / open software development works

The process is that you submit a fix via a PR to github, this is then reviewed by the community via a thread on the forum
This may work in a community of Experts who deal with the code at almost expert level.
"Arduino" community is not such a community.

This is not a community of STM32 core software developers.

The vast majority of people here are the USERS of MapleMinis and BluePills.

It would be great if this would be understood by our Experts as well.

For example:
When User Bill has got some issues "around" malloc(), and an another User e.g. Pito will try him to help (best how he can do), for example he will try to run a test and publish a result to compare ie. the versions, environments. Pito even asked a third person to verify.

When the problem is well understood and replicated by the Users, the Experts may dig into and issue a PR, and the Experts may discuss at github how it should be implemented in very detail in their cores or libraries.

Again, try to understand this community.

Also you cannot expect an User will identify the issues/bugs in their sketches/libraries or cores immediately.
In 80% of cases the Name of a thread is not precise and reveals the issue is different. That is normal in this community. The name of the Bill's thread changed 3x. And it could be it changes itself a fourth time. That is normal in this community.

Pito created 2 threads:
[STM32GENERIC] - Latest Issues
[Libmaple] - Latest Issues
which may work as aggregates for issues close to this 2 popular cores used. Thus the Experts may react faster as they usually do not mess too much with threads which Names are weird.

Also mind the USERS will always ask help and questions which duplicates another threads and posts. You cannot avoid that if you understand this community.

Look at Arduino forum, similar to this. There are hundreds of thousands duplicated posts with the same (few) questions. And another User or Expert is answering them again and again. No problem.

That is how the community of Users usually work..
Pukao Hats Cleaning Services Ltd.

victor_pv
Posts: 1681
Joined: Mon Apr 27, 2015 12:12 pm

Re: Libmaple problem, program crashes with call to malloc.

Post by victor_pv » Wed Aug 16, 2017 1:36 pm

kostbill wrote:
Wed Aug 16, 2017 8:04 am
Roger,

What I see from your repository is that you are acquiring the _lm_heap_start and _lm_heap_end from the linker.
I didn't find a hardcoded definition, so I assume it is embedded in the toolchain, in some binary file.
https://github.com/rogerclarkmelbourne/ ... common.inc:

Code: Select all

/* Heap boundaries, for libmaple */
EXTERN(_lm_heap_start);
EXTERN(_lm_heap_end);
...
Bill it is not in some binary file, it's all in the linker script.
The top of stack is the symbol msp_init, which takes the value of RAM(origin) +RAM(size):
https://github.com/rogerclarkmelbourne/ ... on.inc#L43

The heap starts where global variables finish, and the end is made equal to the top of the stack. There is no hard limit between heap and stack, so it is possible thru memory leaks with the heap to corrupt the stack.
Here is how the bottom and top of stack are calculated.
Bottom:
https://github.com/rogerclarkmelbourne/ ... n.inc#L167
The bottom allows for another value to be defined somewhere in C, but is not, so that comparison results in the head_start taking the value of _end
_end takes the value of bss_end, and bss_end takes the value of the first address after the BSS area:
https://github.com/rogerclarkmelbourne/ ... n.inc#L181

Heap end takes the value of _msp_init in this line, and _msp_init is the last position of RAM as I showed in the link above:
https://github.com/rogerclarkmelbourne/ ... n.inc#L168

That script has been unchanged for the longest time, and malloc() worked before, so the problem is most likely not related to the value of the heap start and end. But since there is a copy of that in each board folder, I advise you to check the version for the specific board you are using, just in case there was an unintentioanl change to common.inc / jtag.ld / flash.ld

If you don't find any problem with the linker script of the ram/flash definitions being changed in those files for the board you use, then I think as suggested before that you should try a version of the repo from 1 or 2 months ago at least.

EDIT:
BTW, to see how those symbols are used (_msp_init, lm_heap_start, etc) do a search in the repo.
There is a function that does the malloc (not sure if called malloc or something else and then a define to malloc) that uses the heap_start and end.
The file startS.S (or something like it) is the one that loads msp_init to the SP register (in asssembler).
I don't remember the name of the file that does the malloc part, but a serach in github should show you.

Post the minimal sketch that causes the failure in Eclipse and the MCU you select and I'll try the same in my old version of the core when I have some time.

victor_pv
Posts: 1681
Joined: Mon Apr 27, 2015 12:12 pm

Re: Libmaple problem, program crashes with call to malloc.

Post by victor_pv » Wed Aug 16, 2017 1:48 pm

Pito wrote:
Wed Aug 16, 2017 10:40 am
Pito, with all due respect, I think Roger's comment was correct for that Bill had suggested (I will wait until Roger resolves it).
Doesn't work like that here, there is no waiting for anyone else to resolve it no one here should think someone else is going to resolve anything. Roger may as well take his repo offline tomorrow if he wishes so and stop working on this altogether.

This is a community to discuss and help each other, but no expectation should ever be had that someone is going to do something. It's all volunteer in our spare time. When I have time I help what I can, when I dont have time I have not help on something. Doesn't mean anything other than I have time or I don't have time, and is the same for Roger.

With the size of the forum Roger spends already quite a lot of time policying it and answering the questions he can. He also check almost every PR that is submitted in github that makes any sense (and many that do not), so I think is right for him to ask that people submit the PRs, and he will help review, test and approve them, with the help of the community.

I believe the right expectation is that when people finds issues they try to work toward resolution and not wait on someone else to resolve them, be it Roger or anyone else.

If Bill will rather wait than test things like he has been suggested, then he may wait for a long time. Perhaps someone resolves it, but there is a chance that doesn't happen or not for a long time, so for everyone's benefit, specially him, it is better to put some effort on testing what's suggested, and investigate etc.

I believe from Bill's reply afterwards that he understand that, and his comment about waiting for the solution was taken too literally and he is in the same page that this a joint effort with no expectations of what someone else will be able to do.

kostbill
Posts: 51
Joined: Mon Aug 07, 2017 7:56 am

Re: Libmaple problem, program crashes with call to malloc.

Post by kostbill » Wed Aug 16, 2017 5:08 pm

Victor, thanks for the very helpful comments on understanding the linker script.
victor_pv wrote:
Wed Aug 16, 2017 1:36 pm
That script has been unchanged for the longest time, and malloc() worked before, so the problem is most likely not related to the value of the heap start and end. But since there is a copy of that in each board folder, I advise you to check the version for the specific board you are using, just in case there was an unintentioanl change to common.inc / jtag.ld / flash.ld
I am looking at these files but I don't know if they are good. What am I searching for?
If you don't find any problem with the linker script of the ram/flash definitions being changed in those files for the board you use, then I think as suggested before that you should try a version of the repo from 1 or 2 months ago at least.
I tested a simple malloc program:

Code: Select all

void setup() {
	uint32_t n = 100, * vec;
	Serial.begin(9600);
	vec = (uint32_t*) malloc(n * sizeof(uint32_t));
	if (vec == NULL) {
		Serial.println("Not enough space.");
	}
	else {
		Serial.print("malloc was successful.");
	}
}
void loop(){}
and both versions crashed! I also tested the same program with Daniel's repository and it worked.
EDIT:
BTW, to see how those symbols are used (_msp_init, lm_heap_start, etc) do a search in the repo.
There is a function that does the malloc (not sure if called malloc or something else and then a define to malloc) that uses the heap_start and end.
The file startS.S (or something like it) is the one that loads msp_init to the SP register (in asssembler).
I don't remember the name of the file that does the malloc part, but a serach in github should show you.
Are you talking about this function:

Code: Select all

/*
 * _sbrk -- Increment the program break.
 *
 * Get incr bytes more RAM (for use by the heap).  malloc() and
 * friends call this function behind the scenes.
 */
void *_sbrk(int incr) {
    static void * pbreak = NULL; /* current program break */
    void * ret;

    if (pbreak == NULL) {
        pbreak = CONFIG_HEAP_START;
    }

    if ((CONFIG_HEAP_END - pbreak < incr) ||
        (pbreak - CONFIG_HEAP_START < -incr)) {
        errno = ENOMEM;
        return (void *)-1;
    }

    ret = pbreak;
    pbreak += incr;
    return ret;
}
? EDIT: While debugging, I cannot see the C code of this function, just the assembly code. No idea why.
Last edited by kostbill on Wed Aug 16, 2017 5:13 pm, edited 1 time in total.

kostbill
Posts: 51
Joined: Mon Aug 07, 2017 7:56 am

Re: Libmaple problem, program crashes with call to malloc.

Post by kostbill » Wed Aug 16, 2017 5:12 pm

Here is what I found from the debugger, I have no idea what it means, it is just the snapshot of the registers at the very instruction that causes the crash. However since there is a pipeline involved and there is no C code in there, I don't which assembly line is the problematic one.

Here is the assembly code block:

Code: Select all

08002b4e:   ldr     r2, [r3, #0]
08002b50:   cmp     r1, r2
08002b52:   it      hi
08002b54:   strhi   r1, [r3, #0]
08002b56:   ldr     r3, [pc, #108]  ; (0x8002bc4 <_malloc_r+824>)
08002b58:   ldr     r2, [r3, #0]
08002b5a:   cmp     r1, r2
08002b5c:   ldr     r2, [r4, #4]
08002b5e:   it      hi
08002b60:   strhi   r1, [r3, #0]
08002b62:   bic.w   r2, r2, #3
08002b66:   cmp     r6, r2
08002b68:   sub.w   r3, r2, r6
08002b6c:   bhi.n   0x8002b72 <_malloc_r+742>
08002b6e:   cmp     r3, #15
08002b70:   bgt.n   0x8002b7c <_malloc_r+752>
08002b72:   mov     r0, r5
08002b74:   bl      0x8002ddc <__malloc_unlock>
Code crashes at 08002b68: sub.w r3, r2, r6

And the snapshot of the registers is:

Code: Select all

General Registers	General Purpose and FPU Register Group	
	r0	0x1001 (Hex)	
	r1	0x1000 (Hex)	
	r2	0x8000194 (Hex)	
	r3	0x20000c94 (Hex)	
	r4	0x0 (Hex)	
	r5	0x20000358 (Hex)	
	r6	0x198 (Hex)	
	r7	0x20000780 (Hex)	
	r8	0x0 (Hex)	
	r9	0xe58 (Hex)	
	r10	0x20000780 (Hex)	
	r11	0x1a8 (Hex)	
	r12	0x10320000 (Hex)	
	sp	0x20004fb8 (Hex)	
	lr	0x8002df9 (Hex)	
	pc	0x8002b68 (Hex)	
	xpsr	0x81000000 (Hex)	
	msp	0x20004fb8 (Hex)	
	psp	0x47e16490 (Hex)	
	primask	0x0 (Hex)	
	basepri	0x0 (Hex)	
	faultmask	0x0 (Hex)	
	control	0x0 (Hex)
And I cannot find the fault registers except from the fault mask which is zero.
It is kind of driving me nuts.

User avatar
Pito
Posts: 1593
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Libmaple problem, program crashes with call to malloc.

Post by Pito » Wed Aug 16, 2017 5:21 pm

I ran the test sketch

http://www.stm32duino.com/viewtopic.php ... 839#p27839

on BlackF407 and the malloc Allocates the memory "successfully" and returns the address of the start of the array

Code: Select all

    /* EXRAM32 Initial memory allocation */
    uint32_t* EXRAM32 =  (uint32_t*) malloc(n * sizeof(uint32_t));
    if (NULL == EXRAM32) {
        Serial.println("      ############### EXRAM32 MALLOC FAILED..");
         //return -1;
        }
    Serial.println((uint32_t)EXRAM32);  // We print here the address of the EXRAM32[0]
Libmaple F407:

Code: Select all

Allocating EXRAM32 memory..
8
********
STM32Generic F407

Code: Select all

Allocating EXRAM32 memory..
536874104                                                  == 0x20000C78
********
Last edited by Pito on Wed Aug 16, 2017 5:36 pm, edited 3 times in total.
Pukao Hats Cleaning Services Ltd.

victor_pv
Posts: 1681
Joined: Mon Apr 27, 2015 12:12 pm

Re: Libmaple problem, program crashes with call to malloc.

Post by victor_pv » Wed Aug 16, 2017 5:23 pm

What version of the core is the oldest you have tried? (like the date, or link on github)
and can you post the simplest sketch that causes the crash for you and the board you select?

About what to look at the ld files, just check if for the board you are using the flash and ram start addresses and size are correct, and then check in the repo the history for those files for that board to see when was the last change and what was it.

I have used that sbrk function recently to get the top of the heap and my code did not crash, but the compiler optimizes a bunch of things away and I don't think I was getting runtime heap, but rather a value calculated at compile time.

Pito you said it crashed for you too in a previous post, was that with the F1 libmaple core?

User avatar
Pito
Posts: 1593
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Libmaple problem, program crashes with call to malloc.

Post by Pito » Wed Aug 16, 2017 5:33 pm

Victor, above is with Libmaple F4, the Libmaple allocates from address 8 here, Daniel's from 0x20000C78.
The Libmaple F1 crashes such I cannot get the address printed out. ( I do not have debugger handy these days).
Try to run the above sketch on MMini/BluePill or any other board (sketch prepared for you already, just compile and run) what you get.
UPDATE:
I downloaded 5mins back the latest Roger's Libmaple repo - result as above, address 8.
Last edited by Pito on Wed Aug 16, 2017 6:08 pm, edited 1 time in total.
Pukao Hats Cleaning Services Ltd.

User avatar
Rick Kimball
Posts: 1040
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Libmaple problem, program crashes with call to malloc.

Post by Rick Kimball » Wed Aug 16, 2017 6:07 pm

I want to lock this thread it is so out of control.

I read back through all the posts by kostbill. He seems to be using a bluepill. He seems to be using Sloeber. He seems to be using all different cores so trying to answer a question about which one has issues is just an exercise in futility.

Before I delete this whole thread. Please answer this question.

Have you tried Roger's core (stm32duino the libmaple one) with your blue pill running in the Arduino IDE? This core:
https://github.com/rogerclarkmelbourne/Arduino_STM32

I just tried the lastest core with a malloc test program and it works fine.

@kostbill Please explain your current setup and the problem with it or this thread will be deleted.
-rick

Post Reply