lua-users home
lua-l archive

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

Thanks!  Got it working now, compiling Lua 5.1.2 with:

    gmake freebsd
    rm lua.o luac.o liblua.a
    gcc -shared -lm -Wl,-E -o *.o
gcc -O2 -Wall -DLUA_USE_LINUX -lm -Wl,-E -lpthread -lreadline - L. -llua.5.1.2 lua.c -o lua

In other words, the 'lua' executable needs to be linked with 'pthread' if _any_ module is going to be doing the same. Leaving '- lpthread' away causes the free/realloc recursiveness trouble (not only warnings).

The build system is anyways suggested changes for 5.2, this one would be worth at least a notion?

Otherwise, case closed.


eugeny gladkih kirjoitti 19.5.2007 kello 20:07:

"AK" == Asko Kauppi <> writes:

 AK> It reproduces steadily.

 AK> I'm begining to wonder if something special needs to be done in
AK> FreeBSD to create a multithreaded program, maybe in the phase when
 AK> Lua itself is compiled.

you should specify -lpthread linking Lua on FreeBSD >= 5.3
(-lc_r for FreeBSD prior 5.3) in multithread environment.

 AK> man pages have this to say:

 AK> "  recursive call  A process has attempted to call an allocation
 AK> function
 AK>      recursively.  This is not permitted.  In particular, signal
 AK> handlers
 AK>      should not attempt to allocate memory."

AK> It does not say about multithreaded programs, maybe the particular AK> malloc is _not_ multithreading capable? My Lanes module links with -
 AK> lpthread, but Lua itself does not.

 AK> -asko

 AK> Gerhard Sittig kirjoitti 19.5.2007 kello 14:34:

On Sat, May 19, 2007 at 01:48 +0300, Asko Kauppi wrote:

Testing Lua Lanes on FreeBSD gives the above error. Does anyone have
an idea what might be the cause?

$ uname -a
Fri Jan 12 11:05:30 UTC 2007
obj/usr/src/sys/SMP  i386

Can you reproduce it?

The PHK implementation of the memory allocator has a very nice
Have a look at the malloc(3) manpage, search for "malloc.conf". This
"file" is a symlink and its content lists options to tune malloc()'s
behaviour.  Alternatively -- or to influence an individual process
-- you could set the MALLOC_CONF environment variable. A third option is to change the program's source and adjust a global _malloc_options
variable in the process.

All of the above methods allow you to instruct malloc(3) to not just
issue the message, but to abort() the process and generate a core dump
so you can do a post mortem analysis and see what happened.

virtually yours
Gerhard Sittig
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.

Yours sincerely, Eugeny.
Doctor Web, Ltd.