LuaLanes on Ubuntu 11.10, kernel 3.0

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

LuaLanes on Ubuntu 11.10, kernel 3.0

Thijs Koerselman-2
Trying to use LuaLanes on a the new Ubuntu with kernel 3.0 I'm getting the following error on both 32 and 64bit systems.

lua51-lanes.so: undefined symbol: pthread_mutexattr_settype

Here are the libraries that are linked to:

 ldd sandbox/lib/lua/5.1//lua51-lanes.so
linux-vdso.so.1 =>  (0x00007fff6e34d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9394d0d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f93952df000)

Any ideas how to fix this? I installed lualanes using luarocks.

Thijs
Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Benoit Germain-2

2011/11/2 Thijs Koerselman <[hidden email]>
Trying to use LuaLanes on a the new Ubuntu with kernel 3.0 I'm getting the following error on both 32 and 64bit systems.

lua51-lanes.so: undefined symbol: pthread_mutexattr_settype

Here are the libraries that are linked to:

 ldd sandbox/lib/lua/5.1//lua51-lanes.so
linux-vdso.so.1 =>  (0x00007fff6e34d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9394d0d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f93952df000)

Any ideas how to fix this? I installed lualanes using luarocks.

Thijs

Unfortunately, none at all. This looks like a pre-built rock that depends on something that changed in the pthread library. The only rockspecs I provide build Lanes from sources. I suppose that would get you a build error instead. But since I have no Ubuntu handy, all this is wild speculation...

--
Benoit.

Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Hisham Muhammad
On Wed, Nov 2, 2011 at 11:36 AM, Benoit Germain <[hidden email]> wrote:

>
> 2011/11/2 Thijs Koerselman <[hidden email]>
>>
>> Trying to use LuaLanes on a the new Ubuntu with kernel 3.0 I'm getting the
>> following error on both 32 and 64bit systems.
>> lua51-lanes.so: undefined symbol: pthread_mutexattr_settype
>> Here are the libraries that are linked to:
>>  ldd sandbox/lib/lua/5.1//lua51-lanes.so
>> linux-vdso.so.1 =>  (0x00007fff6e34d000)
>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9394d0d000)
>> /lib64/ld-linux-x86-64.so.2 (0x00007f93952df000)
>> Any ideas how to fix this? I installed lualanes using luarocks.
>> Thijs
>
> Unfortunately, none at all. This looks like a pre-built rock that depends on
> something that changed in the pthread library. The only rockspecs I provide
> build Lanes from sources. I suppose that would get you a build error
> instead. But since I have no Ubuntu handy, all this is wild speculation...

Yes, the official LuaRocks repositories contain only source rocks (not
binary rocks) for Linux.

I don't know how things work in the recent Ubuntu, but in my system I
just built Lanes with LuaRocks and I have libpthread.so.0 listed in
the output of `ldd lua51-lanes.so` (and I did spot "-lpthread" in the
gcc command during compilation).

You may want to try to `luarocks remove lanes` and then `luarocks
build lanes` again and see if you notice anything strange.

-- Hisham
http://hisham.hm/ - http://luarocks.org/

Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Thijs Koerselman-2
On Wed, Nov 2, 2011 at 3:46 PM, Hisham <[hidden email]> wrote:

Yes, the official LuaRocks repositories contain only source rocks (not
binary rocks) for Linux.

I don't know how things work in the recent Ubuntu, but in my system I
just built Lanes with LuaRocks and I have libpthread.so.0 listed in
the output of `ldd lua51-lanes.so` (and I did spot "-lpthread" in the
gcc command during compilation).

You may want to try to `luarocks remove lanes` and then `luarocks
build lanes` again and see if you notice anything strange.


Thanks I'll give it a shot tomorrow and see how it goes, but I think I've already tried something similar by removing everything. Can I access the makefile somewhere to set these flags? I looked for it but couldn't find it yet.

Thijs
Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Benoit Germain-2
2011/11/6 Thijs Koerselman <[hidden email]>:
> On Wed, Nov 2, 2011 at 3:46 PM, Hisham <[hidden email]> wrote:
>>
>
> Thanks I'll give it a shot tomorrow and see how it goes, but I think I've
> already tried something similar by removing everything. Can I access the
> makefile somewhere to set these flags? I looked for it but couldn't find it
> yet.
> Thijs

You can grab a snapshot at https://github.com/LuaLanes/lanes. I don't
know where to access it when it is retrieved by LuaRocks though.


--
Benoit.

Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Thijs Koerselman-2
On Sun, Nov 6, 2011 at 8:22 PM, Benoit Germain <[hidden email]> wrote:

You can grab a snapshot at https://github.com/LuaLanes/lanes. I don't
know where to access it when it is retrieved by LuaRocks though.

I tried compiling manually and I don't see anything weird but it keeps linking to the same libraries. I added -lpthread but that didn't make a difference.

$ make LUAROCKS=1 CFLAGS="-O2 -fPIC -lpthread -I/home/me/sandbox/include" LIBFLAG="-shared" LUA=/home/me/sandbox/bin/lua LUAC=/home/me/sandbox/bin/luac
/home/me/sandbox/bin/lua ../tools/bin2c.lua keeper.lua -o keeper.lch
cc -O2 -fPIC -lpthread -I/home/me/sandbox/include   -c -o lanes.o lanes.c
cc -O2 -fPIC -lpthread -I/home/me/sandbox/include   -c -o threading.o threading.c
cc -O2 -fPIC -lpthread -I/home/me/sandbox/include   -c -o tools.o tools.c
cc -O2 -fPIC -lpthread -I/home/me/sandbox/include   -c -o keeper.o keeper.c
cc -shared -lpthread lanes.o threading.o tools.o keeper.o  -o lua51-lanes.so


$ ldd lua51-lanes.so 
linux-gate.so.1 =>  (0xb78d2000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7729000)
/lib/ld-linux.so.2 (0xb78d3000)

Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Philipp Janda
Hi!

On 07.11.2011 12:07, Thijs Koerselman wrote:

> On Sun, Nov 6, 2011 at 8:22 PM, Benoit Germain<[hidden email]>wrote:
>>
>>
>> You can grab a snapshot at https://github.com/LuaLanes/lanes. I don't
>> know where to access it when it is retrieved by LuaRocks though.
>>
>
> I tried compiling manually and I don't see anything weird but it keeps
> linking to the same libraries. I added -lpthread but that didn't make a
> difference.
>

The correct commandline switch is -pthread (no l, see 'man gcc'). This
takes care of preprocessor *and* linker settings.

The luarocks build of lanes on my Ubuntu 11.10 is broken as well.
Compiling manually (using -pthread in CFLAGS and LIBS and replacing
-Werror with -Wextra) gives some warnings:
lanes.c: In function ‘LG_set_debug_threadname’:
lanes.c:1208:14: warning: variable ‘threadName’ set but not used
[-Wunused-but-set-variable]
lanes.c: In function ‘LG_wakeup_conv’:
lanes.c:1918:12: warning: missing initializer [-Wmissing-field-initializers]
lanes.c:1918:12: warning: (near initialization for ‘tm.tm_min’)
[-Wmissing-field-initializers]
threading.c: In function ‘THREAD_WAIT’:
threading.c:663:33: warning: unused parameter ‘ref’ [-Wunused-parameter]
tools.c: In function ‘inter_copy_func’:
tools.c:932:14: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
tools.c:945:14: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]

... and an assertion failure during make test:
lua5.1: lanes.c:869: selfdestruct_remove: Assertion `found' failed.
Aborted (core dumped)

This is for the source rock from the luarocks repository. A current
download from github gives some more warnings and no assertion failure
during 'make test', but it freezes instead:
*** glibc detected *** /usr/bin/lua5.1: double free or corruption
(!prev): 0x096eaab8 ***


Philipp


Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Benoit Germain-2
2011/11/7 Philipp Janda <[hidden email]>:
> Hi!
>
>
> This is for the source rock from the luarocks repository. A current download
> from github gives some more warnings and no assertion failure during 'make
> test', but it freezes instead:
> *** glibc detected *** /usr/bin/lua5.1: double free or corruption (!prev):
> 0x096eaab8 ***
>

Thanks for the report.
I'll update the code soon to get rid of all those warnings. Is it
possible to have a callstack to see what's wrong about this double
free? It doesn't seem to exist on win32.


--
Benoit.

Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Philipp Janda
On 07.11.2011 16:25, Benoit Germain wrote:

> 2011/11/7 Philipp Janda<[hidden email]>:
>> This is for the source rock from the luarocks repository. A current download
>> from github gives some more warnings and no assertion failure during 'make
>> test', but it freezes instead:
>> *** glibc detected *** /usr/bin/lua5.1: double free or corruption (!prev):
>> 0x096eaab8 ***
>>
>
> Thanks for the report.
> I'll update the code soon to get rid of all those warnings. Is it
> possible to have a callstack to see what's wrong about this double
> free? It doesn't seem to exist on win32.
Well, not from glibc. It freezes before printing the stack trace:
make irayo_closure
make[1]: Entering directory
`/home/siffiejoe/downloads/LuaLanes-lanes-0e9d9c3'
LUA_CPATH="./src/?.so" LUA_PATH="./src/?.lua;./tests/?.lua"
/usr/bin/lua5.1 tests/irayo_closure.lua
using the closure
true
Killed 1 lane(s) at process end.
*** glibc detected *** /usr/bin/lua5.1: double free or corruption
(!prev): 0x08ddacb0 ***
======= Backtrace: =========

It doesn't always crash on the same test (so far I have seen crashes on
'irayo_closure' and 'func_is_string'). When using valgrind I only get
errors for the 'atexit' test. Interesting part of log is attached.

HTH,
Philipp


err.txt (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Benoit Germain-2
2011/11/7 Philipp Janda <[hidden email]>:
> On 07.11.2011 16:25, Benoit Germain wrote:
>
> It doesn't always crash on the same test (so far I have seen crashes on
> 'irayo_closure' and 'func_is_string'). When using valgrind I only get errors
> for the 'atexit' test. Interesting part of log is attached.
>


I believe I see what's going on. This is timing-specific. I'll submit
a fix soon.

--
Benoit.

Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Hisham Muhammad
On Mon, Nov 7, 2011 at 3:23 PM, Benoit Germain <[hidden email]> wrote:

> 2011/11/7 Philipp Janda <[hidden email]>:
>> On 07.11.2011 16:25, Benoit Germain wrote:
>>
>> It doesn't always crash on the same test (so far I have seen crashes on
>> 'irayo_closure' and 'func_is_string'). When using valgrind I only get errors
>> for the 'atexit' test. Interesting part of log is attached.
>>
>
> I believe I see what's going on. This is timing-specific. I'll submit
> a fix soon.

Great, once you get things sorted out, please feel encouraged to
submit an updated rockspec to the luarocks-developers list, so we can
get builds with LuaRocks fixed as well.

Cheers,

-- Hisham
http://hisham.hm/ - http://luarocks.org/

Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Taj Khattra
In reply to this post by Thijs Koerselman-2
On Mon, Nov 7, 2011 at 3:07 AM, Thijs Koerselman
<[hidden email]> wrote:
> I tried compiling manually and I don't see anything weird but it keeps
> linking to the same libraries. I added -lpthread but that didn't make a
> difference.
> ...
> cc -shared -lpthread lanes.o threading.o tools.o keeper.o  -o lua51-lanes.so

try moving -lpthread to the end of the command line
    cc -shared lanes.o threading.o tools.o keeper.o -lpthread -o lua51-lanes.so

(re: https://wiki.ubuntu.com/OneiricOcelot/ReleaseNotes#GCC_4.6_Toolchain)

Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Benoit Germain-2
In reply to this post by Hisham Muhammad
2011/11/7 Hisham <[hidden email]>:
>
> Great, once you get things sorted out, please feel encouraged to
> submit an updated rockspec to the luarocks-developers list, so we can
> get builds with LuaRocks fixed as well.
>

I just got this when I did:

Delivery to the following recipient failed permanently:

    [hidden email]

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the
recipient domain. We recommend contacting the other email provider for
further information about the cause of this error. The error that the
other server returned was: 554 554 5.7.1
<[hidden email]>: Recipient address rejected:
Access denied (state 14).

I've attached the rockspec here instead.


--
Benoit.

lanes-3.0-beta.rockspec (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Benoit Germain-2
In reply to this post by Taj Khattra
2011/11/7 Taj Khattra <[hidden email]>:
>
> try moving -lpthread to the end of the command line
>    cc -shared lanes.o threading.o tools.o keeper.o -lpthread -o lua51-lanes.so
>
> (re: https://wiki.ubuntu.com/OneiricOcelot/ReleaseNotes#GCC_4.6_Toolchain)
>
>

MinGW compilation remains happy if I change the makefile as follows:

lua51-$(MODULE)$(_SO): $(OBJ)
- $(CC) $(LIBFLAG) $(LIBS) $^ $(LUA_LIBS) -o $@
+ $(CC) $(LIBFLAG) $^ $(LIBS) $(LUA_LIBS) -o $@

Tell me if Ubuntu 11.10 is happy with this change too, so that I can commit it.

--
Benoit.

Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Thijs Koerselman-2


On Wed, Nov 9, 2011 at 9:51 AM, Benoit Germain <[hidden email]> wrote:

MinGW compilation remains happy if I change the makefile as follows:

lua51-$(MODULE)$(_SO): $(OBJ)
-       $(CC) $(LIBFLAG) $(LIBS) $^ $(LUA_LIBS) -o $@
+       $(CC) $(LIBFLAG) $^ $(LIBS) $(LUA_LIBS) -o $@

Tell me if Ubuntu 11.10 is happy with this change too, so that I can commit it.


Great, this is getting somewhere. I have my hands on the 11.10 machine tomorrow and I'll give it a try then. 
Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Philipp Janda
In reply to this post by Benoit Germain-2
Hi!

On 09.11.2011 09:51, Benoit Germain wrote:

> 2011/11/7 Taj Khattra<[hidden email]>:
>>
>> try moving -lpthread to the end of the command line
>>     cc -shared lanes.o threading.o tools.o keeper.o -lpthread -o lua51-lanes.so
>>
>> (re: https://wiki.ubuntu.com/OneiricOcelot/ReleaseNotes#GCC_4.6_Toolchain)
>>
>>
>
> MinGW compilation remains happy if I change the makefile as follows:
>
> lua51-$(MODULE)$(_SO): $(OBJ)
> - $(CC) $(LIBFLAG) $(LIBS) $^ $(LUA_LIBS) -o $@
> + $(CC) $(LIBFLAG) $^ $(LIBS) $(LUA_LIBS) -o $@
>
> Tell me if Ubuntu 11.10 is happy with this change too, so that I can commit it.
>

LuaLanes builds on Ubuntu 11.10 with this fix. But note that in general
linking with libpthread is not enough to compile multithreaded programs,
and it is not equivalent to the -pthread compiler flag[1], which on
Linux also sets -D_REENTRANT (which is required by POSIX for all
multithreaded code). But I guess it only makes a difference if you
compile Lua and all your C extensions yourself, since I doubt that this
flag is used in most makefiles by default. Lanes itself currently does
not use any feature that depends on _REENTRANT in Ubuntu 11.10. So let's
hope for the best.
Btw, there is also a -mthread gcc option for MinGW ...

   [1]:
http://stackoverflow.com/questions/875789/gcc-do-i-need-d-reentrant-with-pthreads

While you are at it, there are still two warnings which break the build
if -Werror is set:
lanes.c: In function ‘LG_set_debug_threadname’:
lanes.c:1361:14: warning: variable ‘threadName’ set but not used
[-Wunused-but-set-variable]
tools.c: In function ‘populate_func_lookup_table_recur’:
tools.c:291:17: warning: variable ‘fqnString’ set but not used
[-Wunused-but-set-variable]

... and two more if using -Wextra:lanes.c:
In function ‘LG_wakeup_conv’:
lanes.c:2206:12: warning: missing initializer [-Wmissing-field-initializers]
lanes.c:2206:12: warning: (near initialization for ‘t.tm_gmtoff’)
[-Wmissing-field-initializers]
threading.c: In function ‘THREAD_WAIT’:
threading.c:666:33: warning: unused parameter ‘ref’ [-Wunused-parameter]

The glibc memory corruption is gone, but now I get an assertion failure
on 'make test' (not always on the first test, but I don't get far):
lua5.1: lanes.c:1018: selfdestruct_remove: Assertion `found' failed.
Aborted (core dumped)

Philipp



Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Benoit Germain-2
2011/11/9 Philipp Janda <[hidden email]>:
> Hi!
>

I've submitted the Makefile fix and (hopefully) the last warnings.

> The glibc memory corruption is gone, but now I get an assertion failure on
> 'make test' (not always on the first test, but I don't get far):
> lua5.1: lanes.c:1018: selfdestruct_remove: Assertion `found' failed.
> Aborted (core dumped)
>


Just inspecting the code leaves me stumped. This assertion means that
the lane structure 's' thinks itself inside the self-destruct chain,
but when looking for it we don't find it. The strange thing is, all
insertions and removals happen under lock, so there must be something
I do wrong, but I don't know what yet... and that leaves me wondering
why I don't ever raise it with win32 builds.

--
Benoit.

Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

David Given
Benoit Germain wrote:
[...]
> Just inspecting the code leaves me stumped. This assertion means that
> the lane structure 's' thinks itself inside the self-destruct chain,
> but when looking for it we don't find it. The strange thing is, all
> insertions and removals happen under lock, so there must be something
> I do wrong, but I don't know what yet...

I don't know the code so I have no idea whether this is at all relevant,
but I ran into a problem like this a few years ago, and it turned out to
be a problem with fork() and pthreads; the behaviour of a semaphore or
mutex is undefined if it goes through a fork, and the particular Linux
variant I was using was silently unlocking all mutexes in the child process.

That took me about nine months to diagnose.

--
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup

Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Benoit Germain-2
2011/11/9 David Given <[hidden email]>:

> Benoit Germain wrote:
> [...]
>>
>
> I don't know the code so I have no idea whether this is at all relevant, but
> I ran into a problem like this a few years ago, and it turned out to be a
> problem with fork() and pthreads; the behaviour of a semaphore or mutex is
> undefined if it goes through a fork, and the particular Linux variant I was
> using was silently unlocking all mutexes in the child process.
>
> That took me about nine months to diagnose.

Lanes doesn't create processes, only threads, so I'll assume this is
not the case :-).


--
Benoit.

Reply | Threaded
Open this post in threaded view
|

Re: LuaLanes on Ubuntu 11.10, kernel 3.0

Philipp Janda
In reply to this post by Benoit Germain-2
On 09.11.2011 17:31, Benoit Germain wrote:
> 2011/11/9 Philipp Janda<[hidden email]>:
>> Hi!
>>
>
> I've submitted the Makefile fix and (hopefully) the last warnings.

Works now.

>
>> The glibc memory corruption is gone, but now I get an assertion failure on
>> 'make test' (not always on the first test, but I don't get far):
>> lua5.1: lanes.c:1018: selfdestruct_remove: Assertion `found' failed.
>> Aborted (core dumped)
>>
>
> Just inspecting the code leaves me stumped. This assertion means that
> the lane structure 's' thinks itself inside the self-destruct chain,
> but when looking for it we don't find it. The strange thing is, all
> insertions and removals happen under lock, so there must be something
> I do wrong, but I don't know what yet... and that leaves me wondering
> why I don't ever raise it with win32 builds.
>

A quick and dirty fix is to remove the 'free( s)' at lanes.c:1156. The
problem is a race condition between the actual thread killing in
selfdestruct_atexit and selfdestruct_remove and accessing free'd memory.
pthread_cancel - which is used for thread killing under Linux - only
sends cancellation requests, but the thread runs until it reaches a
cancellation point which is one of about 60 functions defined by POSIX.
In this case the thread reads from a Linda structure that has been
free'd after the pthread_cancel call and finds something in the
selfdestruct_next pointer that has been left there by the heap manager.

A proper solution would probably involve using pthread_cleanup_push to
free the Lane's memory on actual cancellation.

Now I get a SIGSEGV in tests/atexit.lua :-)

Philipp



12