Data Access Violation in smalloc_do_crash


Well-known member

Sorry for not providing any source-code, as I have no clue where in my thousands line of code that might happen. With Serial.print debugging I was not able to locate at least an area of it happening...

I am having weird random crashes in my project. To find where that (and after being unable to find something by debugging my code) I added the -g to the build and ran a addr2line on that CrashReport:

  A problem occurred at (system time) 12:9:10
  Code was executing from address 0x23A0E
  CFSR: 82
        (DACCVIOL) Data Access Violation
        (MMARVALID) Accessed Address: 0x0 (nullptr)
          Check code at 0x23A0E - very likely a bug!
          Run "addr2line -e mysketch.ino.elf 0x23A0E" for filename & line number.
  Temperature inside the chip was 48.59 °C
  Startup CPU clock speed is 600MHz
  Reboot was caused by auto reboot after fault or bad interrupt detected
  Breadcrumb #2 was 692347259 (0x2944617B)
  Breadcrumb #4 was 2547643817 (0x97D9F5A9)

addr2line responded with:
arm-none-eabi-addr2line -e firmware.elf 0x23A0E                           

sm_utils.c in line 44 is:

static void smalloc_do_crash(struct smalloc_pool *spool, const void *p)
        char *c = NULL;
        *c = 'X';
That assignment line that obviously would crash.
So does anyone might be able to give me hint what might be wrong here?
Did I ran out of memory and the fallback of the smalloc is to call this method to let the app crash?

Edit: build-summary, if it is from interest:
teensy_size: Memory Usage on Teensy 4.1:
teensy_size:   FLASH: code:219684, data:45348, headers:9012   free for files:7852420
teensy_size:    RAM1: variables:55072, code:214576, padding:14800   free for local variables:239840
teensy_size:    RAM2: variables:18400  free for malloc/new:505888
teensy_size:  EXTRAM: variables:32448
Last edited:
I was just checking my PSRAM accessing (having 2 chips installed), because it seems, that extmem_malloc and extmem_free are based on that smalloc library
As I already do all creating and freeing of the EXTMEM objects inside my own little functions (to be able to rework that, if I have to, without touching all of the code), I am able to track my memory allocation and freeing quite good. I am now printing out Pointers after creating and freeing them.
Just a short example. This starting up the sequencer, creating a Track (7f8c), creating a pattern (807c), as its type Polyphonic, that has its own container (80dc), and as I am using a multiset to sort and lookup events, I precreate one event as child of the grid for that lookup requests (8154). Than I added 7 notes to that Pattern.. After a while I went to the project page, and cleared it. freeing seems to be in a different order, because the events were not created in the same direction that they are sorted in the set.
But as I can see: Every single Memory I create, I free. I can repeat that process again and again, the addresses, when created in the same order without doing something else, are the same.
If I let that sequencer running for some time, it crashes (between half a minute and several minutes) always at the exact same memory location, that is this do_crash function.
The sequencer does access the the memory up to 384 times a second (120bpm, 192ppqn), if notes are playing (to determine when note has to be stopped). The Multiset is accessed every step, that is 8 times a second at 120bpm. In my test scenario I have everything left out, that adds to those (notes timed in the future, more than 1 track, more than this 7 events, only one playing at a time).

Maybe someone has an idea, when it comes to that do_crash call (that is set as smalloc_ub_handler per default in that sm_util.c file).

Creating object at 0x70007f8c
Creating object at 0x7000807c
Creating object at 0x700080dc
Creating object at 0x70008154

Creating object at 0x70008184
Creating object at 0x700081b4
Creating object at 0x700081e4
Creating object at 0x70008214
Creating object at 0x70008244
Creating object at 0x70008274
Creating object at 0x700082a4

Deleting object at 0x70008214
Deleting object at 0x700082a4
Deleting object at 0x700081e4
Deleting object at 0x70008274
Deleting object at 0x700081b4
Deleting object at 0x70008244
Deleting object at 0x70008184

Deleting object at 0x70008154
Deleting object at 0x700080dc
Deleting object at 0x7000807c
Deleting object at 0x70007f8c
Some more informations acquired:
According to the smalloc library and its comments, the do_crash is called, because it is the default assignment to smalloc_UB. the Comment on smalloc_UB tells me, that it is called and handler for undefined behavior.
I looked up calls on smalloc_UB and I also found, that I am able to set my own function onto that method. That way I can add some Logging messages, see, how often in occurs and if I can point out better, when it exactly happens.