[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: FreeBSD: "lua in realloc(): warning: recursive call"
- From: Asko Kauppi <askok@...>
- Date: Sun, 20 May 2007 01:18:26 +0300
Thanks! Got it working now, compiling Lua 5.1.2 with:
rm lua.o luac.o liblua.a
gcc -shared -lm -Wl,-E -o liblua.5.1.2.so *.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
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 <email@example.com> 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
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> recursively. This is not permitted. In particular, signal
AK> should not attempt to allocate memory."
AK> It does not say about multithreaded programs, maybe the
AK> malloc is _not_ multithreading capable? My Lanes module links
AK> lpthread, but Lua itself does not.
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
an idea what might be the cause?
$ uname -a
FreeBSD td152.testdrive.hp.com 6.2-RELEASE FreeBSD 6.2-RELEASE #0:
Fri Jan 12 11:05:30 UTC 2007 firstname.lastname@example.org:/usr/
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".
"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
is to change the program's source and adjust a global
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
so you can do a post mortem analysis and see what happened.
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. http://www.drweb.com