lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 16/01/2008, at 5:28 PM, Rob Barris wrote:

On OS X all calls to malloc() will return something aligned in 16 byte boundary unless its size is less than 16 bytes or maybe 8 bytes.

So, the runtime is trying to let us know that some code path is possibly freeing a bogus pointer. Frame #4 in your crawl shows the point in Lua code where the call to free() is made.. I wonder if you have found a bug.

I wondered about this but unfortunately I don't really know what I'd be looking for. Like I said, I don't know enough about memory allocation to spot anything that might be problematic. Here's the function calls from Frame #4 and #5

from lauxlib.c:

static void *l_alloc (void *ud, void *ptr, size_t osize, size_t nsize) {
  if (nsize == 0) {
    return NULL;
    return realloc(ptr, nsize);

and from lmem.c

void *luaM_realloc_ (lua_State *L, void *block, size_t osize, size_t nsize) {
  global_State *g = G(L);
  lua_assert((osize == 0) == (block == NULL));
  block = (*g->frealloc)(g->ud, block, osize, nsize);
  if (block == NULL && nsize > 0)
    luaD_throw(L, LUA_ERRMEM);
  lua_assert((nsize == 0) == (block == NULL));
  g->totalbytes = (g->totalbytes - osize) + nsize;
  return block;

I would imagine that it is most likely something in my code but the fact that the same errors occur in presumably well written and/or debugged modules like luasqlite make me wonder if there's some OS X specific issue with Lua memory allocation. As it certainly seems that the vast majority of Lua development happens on Windows and Linux.