OpenBSD 7.3 && OpenBSD SnapShot: *Segmentation Fault (core dumped)*
I traced down the actual build command to ninja -f ./compile/ninja/openbsd.ninja, which generated the same message as mentioned in the title. Then the ninja build file was reviewed to see what building entailed. What immediately piqued my curiosity was the specification of gcc as a dependency when the build process will take place in clang. This might prove to be doubly problematic since gcc has been moved to egcc on OpenBSD systems. Why in the name of cheesy tortillas, OpenBSD chose to rename /usr/local/bin/gcc to /usr/local/bin/egcc only the BSD cosmos knows, but if ninja is looking for specifically the gcc binary, it won't find it.
Full output is rather lacking in any specific identification of the cause of the segmentation fault:
$> ninja -d explain -d stats -d keeprsp -d keepdepfile -f ./compile/ninja/openbsd.ninja
ninja explain: output build/openbsd/obj/test.stamp doesn't exist
ninja explain: build/openbsd/obj/test.stamp is dirty
[0/1] Run test.
OS: openbsd 7.3.0
Arch: x86_64
Compiler: Clang 13.0.0
CRT: libc++ 13000
DEBUG: false
............................................................................
..............Segmentation fault (core dumped)
FAILED: build/openbsd/obj/test.stamp
build/openbsd/bin/bootstrap bee.lua/test/test.lua --touch build/openbsd/obj/test.stamp
ninja: build stopped: subcommand failed.
metric count avg (us) total (ms)
.ninja parse 1 910.0 0.9
node stat 177 5.2 0.9
.ninja_log load 1 388.0 0.4
.ninja_deps load 1 325.0 0.3
node stat 175 5.4 0.9
StartEdge 1 857.0 0.9
FinishCommand 1 132.0 0.1
path->node hash load 0.74 (292 entries / 397 buckets)
Now clang will always be used instead of gcc or egcc.
You can try build/openbsd/bin/bootstrap bee.lua/test/test.lua -v to find which test fails.
First to build luamake on OpenBSD current/amd64, I need to patch bee to include OpenBSD files in bee/net/endpoint.cpp, bee/net/socket.cpp and bee/subprocess/subprocess_posix.h => build of luamake OK
I have also a SegmentationFault during tests :
$ build/openbsd/bin/bootstrap bee.lua/test/test.lua -v
OS: openbsd 7.3.0
Arch: x86_64
Compiler: Clang 13.0.0
CRT: libc++ 13000
DEBUG: false
Started on Thu May 4 10:23:11 2023
serialization.test_ok_1 ... Ok
(...)
Ok
subprocess.test_select ... Ok
socket.test_bind ... Ok
socket.test_tcp_connect ... Ok
socket.test_unix_connect ... Ok
socket.test_tcp_accept ... Ok
socket.test_unix_accept ... Ok
socket.test_pair ... Ok
socket.test_tcp_echo_1 ... Ok
socket.test_unix_echo_1 ... Ok
socket.test_tcp_echo_2 ... Ok
socket.test_unix_echo_2 ... Ok
socket.test_tcp_echo_3 ... Ok
socket.test_unix_echo_3 ... Ok
socket.test_dump ... Ok
filewatch.test_1 ... Segmentation fault (core dumped)
filewatch depends on libinotify-kqueue on openbsd. But I don't know much about it.
First to build
luamakeon OpenBSD current/amd64, I need to patchbeeto include OpenBSD files inbee/net/endpoint.cpp,bee/net/socket.cppandbee/subprocess/subprocess_posix.h=> build ofluamakeOK
@lcheylus You can submit a pull request on bee.lua.
Now clang will always be used instead of gcc or egcc.
You can try
build/openbsd/bin/bootstrap bee.lua/test/test.lua -vto find which test fails.
@actboy168 This really really helps. Now, I know how to troubleshoot. | ~~Filewatch can be a bitch with OpenBSD, because OpenBSD's kernel does not allow for the monitoring of changed files the same way Linux does. To my understanding, it doesn't allow for the monitoring of individual files, rather it only allows the monitoring of entire directories. As your highly attuned cranium can conclude, this is technically referred to as "a bummer".~~ 😳
@anoduck The test does not watch a file.
I was in the middle of refactoring and restructuring my NeoVim configuration before I attempted to update lua-language-server, so I tried to run the test as well.
build/openbsd/bin/bootstrap bee.lua/test/test.lua -v
OS: openbsd 7.3.0
Arch: x86_64
Compiler: Clang 13.0.0
CRT: libc++ 13000
DEBUG: false
Started on Sat May 6 02:05:46 2023
serialization.test_ok_1 ... Ok
[...]
subprocess.test_cwd ...
Ok
socket.test_bind ... Ok
socket.test_tcp_connect ... Ok
socket.test_unix_connect ... Ok
socket.test_tcp_accept ... Ok
socket.test_unix_accept ... Ok
socket.test_pair ... Ok
socket.test_tcp_echo_1 ... Ok
socket.test_unix_echo_1 ... Ok
socket.test_tcp_echo_2 ... Ok
socket.test_unix_echo_2 ... Ok
socket.test_tcp_echo_3 ... Ok
socket.test_unix_echo_3 ... Ok
socket.test_dump ... Ok
filewatch.test_1 ... [1] 32798 segmentation fault (core dumped) build/openbsd/bin/bootstrap bee.lua/test/test.lua -v
Same results as before.
Just for reference, as everyone knows, filewatch and OpenBSD were not playing well together previously. #24
And, I was totally off base regarding libinotify-kqueue, but for what it is worth, this is what I was referencing. OpenBSD support for Maestral
With this fix for bee.lua (https://github.com/actboy168/bee.lua/pull/45), build OK on OpenBSD current/amd64 (future version 7.5) and no more crash during tests:
$ build/openbsd/bin/bootstrap bee.lua/test/test.lua -v
OS: openbsd 7.4.0
Arch: x86_64
Compiler: Clang 16.0.6
CRT: libc++ 160006
DEBUG: false
Started on Mon Feb 12 18:31:10 2024
serialization.test_ok_1 ... Ok
serialization.test_err_1 ... Ok
serialization.test_err_2 ... Ok
serialization.test_err_3 ... Ok
serialization.test_ref ... Ok
(...)
filewatch.test_1 ... Ok
filewatch.test_2 ... FAIL
bee.lua/test/test_filewatch.lua:69: expected: nil, actual: <userdata:/tmp/test_bee/temp/test1.txt>
filewatch.test_symlink ... Ok
time.test_now ... Ok
time.test_monotonic ... Ok
=========================================================
Failed tests:
-------------
1) filewatch.test_2
bee.lua/test/test_filewatch.lua:69: expected: nil, actual: <userdata:/tmp/test_bee/temp/test1.txt>
stack traceback:
bee.lua/test/test_filewatch.lua:69: in local 'assertHas'
bee.lua/test/test_filewatch.lua:72: in local 'f'
bee.lua/test/test_filewatch.lua:28: in upvalue 'test'
bee.lua/test/test_filewatch.lua:38: in upvalue 'filewatch.test_2'
Ran 98 tests in 0.290 seconds, 97 successes, 1 failures
@lcheylus Are we still using gcc-11 for this, and if so won't that still result in an incompatibility with blas and lapack? Any word as to when this might make it into the ports tree?
Never used gcc-11 to build luamake, only clang (here version 16.0.6).
I don't need luamake in ports tree. I'm using it to build lua-language-server (project to package it as OpenBSD port) and luamake is imported as submodule.
@lcheylus I mispoke, need some sleep. Although, you did answer my question. So, cool.
I don't know much about openbsd, it looks like filewatch doesn't work on openbsd. In fact, the core code of luamake does not depend on filewatch. I can skip the filewatch test and let luamake build successfully on openbsd.
But if you want to use luamake to build luals, you will still inevitably encounter this problem. I suggested to the author of luals to add an option to make filewatch optional. But he may have other higher priority things to do. I think this is the fastest and easiest way to get luals working in openbsd.
@actboy168 you are correct about filewatch.
I would have to agree, circumvention of filewatch is a supremely more efficient course of action, and your concern for the plight of OpenBSD users is quite considerate. If there is anyway I could contribute to urging the author of luals to provide that option, please allow me to know.
If you need to clear this issue from your todo list, you can close it out whenever you desire.
I build successfully luamake on OpenBSD with the last updates of bee.lua/luamake + tests disabled for filewatch (suppress test_fw:test_2).
I have a lua-language-server port for OpenBSD which works (with also some additional patches), see https://github.com/jasperla/openbsd-wip/tree/master/devel/lua-language-server
@lcheylus Thanks to your comment and Download Directory, I have a copy of it, and will "give it a whirl". I might have to set ~PORTSDIR_PATH and~ PKGPATH so OpenBSD knows what to do with it. ~This should not be a problem.~ I am going to have to study on this for a while.
Going ahead and closing this one out.
@lcheylus Finally got time to run the build process for lua_ls in the OpenBSD-WIP repository, and God, I love OpenBSD. It was like butter on toast. Thanks, buddy.