Forums

newlib, FreeRTOS, reentrancy, heap and related questions

Started by pozz February 6, 2020
On Friday, February 7, 2020 at 8:31:10 AM UTC-5, pozz wrote:
> After your considerations, why use a printf that uses heap? There are > other good implementations that don't use heap at all and so are > intrinsically thread-safe.
There's a list of alternate printf implementations on my web page you referenced. Other library functions like strtok use malloc and friends. Again, whatever you do, check the map and MAKE SURE you don't accidentally drag in non-thread-safe uses of library malloc family... Hope that helps, Best Regards, Dave
David Brown <david.brown@hesbynett.no> writes:
> The point is that because the compiler knows what malloc and free do - > they are specified in the standards - it can use that knowledge for > optimisation.
In this case it has accessed unallocated memory. I wonder if there is an exploit. Hmm.
On 07/02/2020 17:00, Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes: >> The point is that because the compiler knows what malloc and free do - >> they are specified in the standards - it can use that knowledge for >> optimisation. > > In this case it has accessed unallocated memory. I wonder if there is > an exploit. Hmm. >
No, it hasn't accessed unallocated memory at all. It did not access anything. The compiler could see that either the malloc worked fine and the result would be the value 6, or the malloc would fail (and return 0) in which case the program would have undefined behaviour (accessing a null pointer). The compiler can assume that the programmer doesn't care what happens when executing undefined behaviour, and thus giving a result of 6 is perfectly acceptable there too. So the best code is simply to return 6 without any work at run time. Ironically, if I had checked the result of malloc() for a null pointer, it could not have made this optimisation!
David Brown <david.brown@hesbynett.no> writes:
> No, it hasn't accessed unallocated memory at all. It did not access > anything. The compiler could see that either the malloc worked fine > and the result would be the value 6,
It's a question of how the compiler implemented the compile-time execution. I hope that it didn't really allocate 6 bytes of memory at compile time, and then write past it. But it makes me wonder.
On 09/02/2020 04:42, Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes: >> No, it hasn't accessed unallocated memory at all. It did not access >> anything. The compiler could see that either the malloc worked fine >> and the result would be the value 6, > > It's a question of how the compiler implemented the compile-time > execution. I hope that it didn't really allocate 6 bytes of memory at > compile time, and then write past it. But it makes me wonder. >
I'm lost here. Are you talking about the mistake I made in allocating 4 bytes, rather than 4 * sizeof(int) ? It makes no difference to the code generated when that is corrected, and I don't see where "6 bytes" comes from. The use of "malloc" in the source code bears no direct relation to having to allocate dynamic memory in the compiler. Compile-time execution means figuring out what the effect of the code is, and simulating it at compile time - it does /not/ mean executing it directly. And in particular, baring bugs in the compiler it does not mean executing undefined behaviour in the compiler - though it can mean ignoring it in the source code. (It would have been nice if the compiler had spotted my mistake and told me about it, however.)
On Thursday, February 6, 2020 at 7:26:52 AM UTC-5, pozz wrote:
> [1] http://www.nadler.com/embedded/newlibAndFreeRTOS.html
Pozz, you mentioned you're trying to use ST's RubeMX. Be careful, extremely buggy support libraries and examples!! Latest unbelievable foolishness here: https://community.st.com/s/question/0D50X0000CBmXufSQF/newlibmalloc-locking-mechanism-to-be-threadsafe Avoid the ST suggestions!!! Aaaaarrrrggggg.....