It is a bug in our stack. We are going to fix it soon so you should see an email that discusses the issue and fix. Thanks for catching this!
Will > On Jul 7, 2016, at 6:37 PM, Simon Ratner <[email protected]> wrote: > > So, the assert being where it is, would your bet be on a controller bug, a > host bug, or the app corrupting os memory in some way? (I've certainly done > my fair share of the latter ;) > > > > On Thu, Jul 7, 2016 at 6:06 PM, will sanfilippo <[email protected]> wrote: > >> There are a few of them actually. Note that we returned an error code when >> the block being freed was not part of the memory pool or either the block >> or pool is NULL. There was some debate on whether to return an error in the >> latter two cases, but not any debate about the former. >> >> What does being part of the pool mean? It means that the address of the >> block being freed is within the memory range of the memory pool and also >> that the address is on a “block boundary”. For example, say you have 100, >> 20 byte memory blocks and the memory block is at address 0x1000. If you >> attempt to free something that is at an address that is less than 0x1000 or >> greater than 0x1000 + (100*20) an error will be returned. Also, if the >> address is not on a 20-byte boundary (starting from the beginning address >> of the memory pool) an error will be returned. >> >> Will >> >> NOTE: the “true block size” is based on the value of OS_ALIGNMENT. >> Currently this is 4 for our architectures but if you change it the block >> size may change as all memory blocks are padded to “OS_ALIGNMENT” >> boundaries (for example, you allocate a 21 byte block, you get a 24 byte >> block). >> >>> On Jul 7, 2016, at 5:52 PM, Simon Ratner <[email protected]> wrote: >>> >>> I've been seeing this semi-regularly lately, can't make sense of it. >>> >>> 66490:Assert ; failed in ble_ll_hci.c:999 >>> 66490:Unhandled interrupt (2), exception sp 0x20001788 >>> 66490: r0:0x00000000 r1:0x2000179c r2:0x80000000 r3:0xe000ed00 >>> 66490: r4:0x00000000 r5:0x000003e7 r6:0x00021fec r7:0x20001823 >>> 66490: r8:0xffffffff r9:0xffffffff r10:0x1fff8000 r11:0x00000000 >>> 66490:r12:0x00000000 lr:0x0000e2fd pc:0x0001fd60 psr:0x81000000 >>> 66490:ICSR:0x00411002 >>> >>> The line points to >>> >> https://github.com/apache/incubator-mynewt-core/blob/develop/net/nimble/controller/src/ble_ll_hci.c#L998 >>> (I am on the tip of develop). Under what circumstances would returning a >>> memblock to the pool fail? >>> >>> Cheers, >>> simon >> >>
