Date: Thu, 24 Jan 2019 02:02:22 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 235158] lang/lua53 no longer linked against pthread Message-ID: <bug-235158-7788-WwQWkDNbxM@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-235158-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-235158-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235158 --- Comment #3 from i+fbsd@amlegion.org --- Hiya, For as long as I can remember, back before I came to FreeBSD around 2012, I= was dealing with having to compile my own lua to link against pthreads to stop = some pet projects from hanging on creating a new thread. I'm still reading the review you linked but figured it would be okay to go ahead and reply with some history and an idea of the issue and how I came to the conclusion that caused me to report this. I don't think any ports in the FreeBSD repos use lua with threading, nor do= any lua libraries in ports, so it would be a fairly difficult issue to catch. Of course, I may not be looking hard enough because I've only looked for lua lanes, llthread2, and cqueues, which are not in ports that I can see. As to requiring pthread when building... cqueues and llthreads2 both hang on thread creation with lua53 built from ports, or installed from FreeBSD package repos. I only have one example test for cqueues. The way I came to this conclusion was to bang my head at it all night, make tons of changes to the lua source, cqueues source, sprinkling in fprintf's, and finding that luaL_newstate failed. When I started editing the lua source code I put the fprintfs around the alloc and found that it print= ed before the allocation in the new thread, but never after, so was at that po= int, hung. I didn't realize that night that not being linked against pthreads was the issue. Then this morning I started looking at the bugzilla for lua and pthreads an= d so forth, then the svnweb to see if it still had the pthreads link flag in the patch and couldn't see it in the patch so felt that this might be the probl= em. I then built lua, with -pthread, and ran the same test, and it worked, then proceeded to try against my pet project and found it worked correctly again instead of hanging after several log lines. Debugging malloc is out of my depth, I definitely would be at a loss there.= If you have the time and want to try duplicating the issue, install lua from ports, and (not using luarocks, it'll break it) install cqueues. Dealing wi= th cqueues you need either openssl111 or base openssl (libressl and other open= ssl yield a broken cqueues). If you have any other ssl library you can build cqueues with 'ALL_LDFLAGS=3D"-L/usr/lib" make all' and that seems to make it select base openssl. At that point copy the following into a file and lua53 $file. It'll hang, be prepared to have another terminal open to pkill -9 lu= a53. To see it then work, get lua source, and build it with "make MYLIBS=3D-pthr= ead freebsd" and then run "src/lua $file" and it'll finish out fine. file contents below: local cqueues =3D require 'cqueues' local thread =3D require 'cqueues.thread' local function print_data(sock, data) print(data) end local function start() thread.start(print_data, 'data') end local loop =3D cqueues.new() loop:wrap(start) loop:loop() While building without pthreads enabled may work on other operating systems, I'd be interested to see if when running "ldd `which lua`" does their lua s= how itself linked against libthr or not (I'll see if I can get a hold of some people to check this on their non-FreeBSD systems, or see about spinning up= a VM here/there to check that out too). If more is needed in the form of a way to test this outside of what I've li= sted above, or perhaps a test for llthreads2, I can work towards that as well. If you need a test to run to validate things in the future as to threads and l= ua I can work with you on that, though I might need some input and probably would need to update the test at each lua version (or just depend on a test for l= ua 5.3 giving the results needed for knowing if such still needs to be done for other lua versions). If you have any other ideas on how to look deeper into this I'll help where I can. I don't currently possess the knowledge to debug malloc and friends but with some guidance can probably look although I doubt I'd be useful in that regard. Let me know if testing on non-FreeBSD systems (checking ldd, and running the test) is unecessary so I don't venture too far into that and find that I've done it for naught, otherwise, I'll update this report with that info as so= on as I can. Thanks --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235158-7788-WwQWkDNbxM>