Re: FreeBSD: "lua in realloc(): warning: recursive call"

[Asko Kauppi <askok@...>]

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 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  
only warnings).

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

Otherwise, case closed.

-asko


eugeny gladkih kirjoitti 19.5.2007 kello 20:07:

> > > > > > "AK" == Asko Kauppi <askok@dnainternet.net> 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
> > > > FreeBSD td152.testdrive.hp.com 6.2-RELEASE FreeBSD 6.2-RELEASE #0:
> > > > Fri Jan 12 11:05:30 UTC 2007     root@dessler.cse.buffalo.edu:/usr/
> > > > obj/usr/src/sys/SMP  i386
> > >
> > > Can you reproduce it?
> > >
> > > The PHK implementation of the memory allocator has a very nice
> > > feature:
> > > 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
> > > only
> > > -- 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. http://www.drweb.com