Greatest Hits from Tech Support!

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
You guys might appreciate this, received almost 2 months after posting a bug:
https://community.nxp.com/message/878673?commentID87%8673

Yikes.

Customer is suggesting we shouldn't use Freescale (NXP?) in future;
Kinetis parts may go away in product rationalization...

See ya, Dave

Re: Greatest Hits from Tech Support!
On 2/17/2017 8:57 AM, Dave Nadler wrote:
Quoted text here. Click to load it

(sigh)  Clearly folks who don't understand the question(s) being asked/issues
being presented -- ditto the referenced SO post  :<.  (/caveat emptor/)

"In no case is returning a pointer outside the heap acceptable"
+42

"NXP examples should set sensible default heap size"
Meh... heap size should be appropriate for the *example*, nothing more.

"a trap on out-of-memory would be better"
Not possible with all platforms.  I'm not fond of having to rewrite
code because it relies on specific "undocumented" behavior.

My _DEBUG version of malloc/free aggressively examine all I/O's.
I rely on dynamic allocation extensively (e.g., support multiple
arenas, allocation strategies, etc. concurrently).  So:

      ptr = malloc(...)
      free(ptr)

is ALWAYS safe -- even if ptr == NULL.  But, attempting:

      ptr = malloc(...)
      free(ptr)
      free(ptr)

will trigger an invariant and stop the program in its tracks
(because the memory free'd in the second call isn't allocated
at the time of the call -- an extra condition I impose on free()
that the standard library doesn't)

Likewise:

       ptr = malloc(HEAP_SIZE+1)

is guaranteed to return NULL (and tickle another invariant in -DEBUG) and:

       ptr = malloc(0)

provides an effective way of knowing that the heap *is* exhausted.

[This is subtle as it relies on the caller knowing the memory available for
their use, for a non-NULL return value, is constrained to [ptr,ptr+size) ]

The standard allows no other way of "returning an error" so if you don't
like the arguments, you have to return NULL.

Quoted text here. Click to load it

Why?  Because they are wary of the quality of the support available?
Farming your tech support out to users is always a dubious business strategy!

Quoted text here. Click to load it

Because the expected support will be better?

Quoted text here. Click to load it


Re: Greatest Hits from Tech Support!
On Friday, February 17, 2017 at 12:54:16 PM UTC-5, Don Y wrote:
Quoted text here. Click to load it

Don, sorry if the context wasn't entirely clear.
Freescale/NXP provide many dozens of examples.
Typically a good place to start when using a new tool chain!
I pared down one of their examples show that they've misconfigured
memory management and heap size for their examples...

In the context of their examples, typically run under a debugger,
traps would be very helpful to sort out configuration issues.

I'm quite astonished at the answer though:

"It's really OK that malloc returns a pointer outside the heap,
because in my blinky example it didn't cause a problem..."

It gets worse though.
Their examples for FreeRTOS are misconfigured so that:
- they will blow the heap,
- the FreeRTOS-aware debugger crashes,
- newlib isn't set up compatibly with FreeRTOS memory management,
- etc.

See ya, Dave



Site Timeline