Re: Non-aligned pointer errors on Mac OS X

["alex.mania@..." <alex.mania@...>]

Lua (like any well-behaving application) only frees what it is allocated -
So I'm baffled as to how attempts to free unaligned pointers are being caught
unless malloc itself is returning unaligned blocks in the first place.

What baffles me even more is that "object 0x40fa4" is in fact 4 byte aligned,
which is usually sufficient. It's possible that your memory allocator always uses
8 or 16 byte aligned pointers, but in that case malloc should be returning 8 or 16 byte
aligned pointers in the first place.

I've heard that OS X requires that the stack be 16 byte aligned,
but that's different.

This is on a completely unmodified lua core right?

It could be an incorrect error message, and the real problem could be related to some
other form of heap corruption - say overwriting the header/footer of a pointer elsewhere
in your code, but it seems weird that you would get an unaligned pointer error from that.

It's also possible that you're mixing allocators - but very unlikely. This would only be
possible if you're using a module that redefines malloc/realloc/free for faster variants;
and somehow Lua is allocating memory before the new memory allocator is loaded
but before it attempts to free the same memory. Very unlikely though, as you would know
if you are using a non-default memory allocator.

If you're really stuck scratching your head, you could perform a quick sanity test of your
allocator by filling an array with mallocs, then freeing them all. (Obviously should not get
any errors by doing this).  If all the pointers are 8 or 16 byte aligned (easy to tell just
by running your eye over the debug window) aligned then your problem is that somehow
lua has ended up getting a 4 byte aligned pointer.

How I do not know =(.

-confused-

P.S. very quick and dirty explanation of data alignment:
The pointer remainder the size of what it is trying to store is 0 in an aligned pointer.
Eg if you're trying to store a 32 bit integer, the pointer should end in a: $0; $4; $8; $C;
Or a 64 bit double: $0, $8
Or a 128 bit SSE register: $0
Aligned data access is not required for integers or doubles on x86 (and -64), but will
increase performance. (Very very marginally for integers, but a large amount for doubles.)
For 128 bit SSE registers it's required whenever using memory as a second operand;
eg multiplying one SSE register by a memory location requires that memory location
to be 128 bit aligned, and is also required for fast loading of an SSE register (otherwise
the much slower movups command has to be used).

On Wed Jan 16 9:35 , Scott Weeks sent:

> Hello,
>
>
> I'm new here :-)
>
>
> Anyway, I've been doing some development with Lua and OS X and have  
>
> noticed that when I use some C libraries I get the following error (or  
>
> something like it)
>
>
> lua(8680) malloc: *** error for object 0x40fa4: Non-aligned pointer  
>
> being freed
>
> *** set a breakpoint in malloc_error_break to debug
>
>
> This has occured for me with the luasqlite3 library as well as with a  
>
> C module that I've been writing. It occurs for me when I create a new  
>
> table from within C.
>
>
> Adding a lua_newtable(L) call or a luaL_newmetatable(L,"blah") call  
>
> will get me these errors and they stop when I comment them out.
>
>
> Now, I am very much a novice when it comes to C and memory management  
>
> and am particularly baffled with things like pointer alignement,  
>
> etc... I fired up gdb and managed to get the following stack when I  
>
> ran my program with malloc_error_break set
>
>
> Breakpoint 1, 0x94e9b9f1 in malloc_error_break ()
>
> (gdb) where
>
> #0  0x94e9b9f1 in malloc_error_break ()
>
> #1  0x94e969df in szone_error ()
>
> #2  0x94dbbb83 in szone_free ()
>
> #3  0x94dbb9ed in free ()
>
> #4  0x00015c94 in l_alloc ()
>
> #5  0x0000c4fc in luaM_realloc_ ()
>
> #6  0x00010a3b in luaH_free ()
>
> #7  0x0000a71d in sweeplist ()
>
> #8  0x0000ab4f in singlestep ()
>
> #9  0x0000ae68 in luaC_step ()
>
> #10 0x000140ea in luaV_execute ()
>
> #11 0x00008e30 in luaD_call ()
>
> #12 0x00004951 in f_call ()
>
> #13 0x0000833b in luaD_rawrunprotected ()
>
> #14 0x00009152 in luaD_pcall ()
>
> #15 0x000049c5 in lua_pcall ()
>
> #16 0x00016ffa in luaB_xpcall ()
>
> #17 0x000089f3 in luaD_precall ()
>
> #18 0x00013e9e in luaV_execute ()
>
> #19 0x00008e30 in luaD_call ()
>
> #20 0x00004951 in f_call ()
>
> #21 0x0000833b in luaD_rawrunprotected ()
>
> #22 0x00009152 in luaD_pcall ()
>
> #23 0x000049c5 in lua_pcall ()
>
> #24 0x00002833 in docall ()
>
> #25 0x00003024 in pmain ()
>
> #26 0x000089f3 in luaD_precall ()
>
> #27 0x00008dd3 in luaD_call ()
>
> #28 0x00004a90 in f_Ccall ()
>
> #29 0x0000833b in luaD_rawrunprotected ()
>
> #30 0x00009152 in luaD_pcall ()
>
> #31 0x00004ae7 in lua_cpcall ()
>
> #32 0x00003405 in main ()
>
>
>
> I don't know if that's useful but it seems to be right around the  
>
> palce where lua is reallocating memory... Any pointers would be  
>
> greatly appreciated.
>
>
> Cheers,
>
> Scotty Weeks
>
> )