Closed gaultx closed 3 years ago
@gaultx Is that reproducable?
If yes, we have a problem and it will take a while to find and fix this problem.
Error [signal SIGSEGV: segmentation violation code=0x1 addr=0x15 pc=0x7fbce46e80c4]
should not be possible in GO. It can only be genarated in the CGO code used by sqlite3.
It may have to do with this mod: https://mods.factorio.com/mod/Todo-List
The only thing I can think of is that the display name of the mod in the UI has a unicode/emoji in it. Try uploading the mod and see what happens.
EDIT: Nope, failing with other mods too. But still consider using that mod as a test case.
Reproducable, this error does not occure on Ubuntu 18.04LTS.
Update: Using an executable comipled on Ubuntu 20.10 is fixing this. My theory: The glibc version installed on Ubuntu 20.10 (2.32) is not compatible with the one it got compiled with (Ubuntu 18.04 (2.27). Further testing has to be done.
can confirm on 20.04 with the latest docker version of OFSM. On another machine with 20.04 (identical setup) I don't have this crash. I installed and configured this machine a few months ago and doesnt have the sqlite.db yet but the auth.leveldb/ dir.
For me it's when i fill in the credentials on the mods page I get a:
which made me think my credentials were wrong but they do work on the other server.
When I fill in the Token from profile page on Factorio site in serversettings and go to the mods page and do a refresh the page crashes: 404 page not found.
Base factorio server when started is working fine.
Seems like our executable is using one function, that got removed from glibc with version 3.32.
https://abi-laboratory.pro/index.php?view=compat_report&l=glibc&v1=2.31&v2=2.32&obj=04aa0&kind=abi#Removed
pthread_sigmask ( int how, sigset_t const* newmask, sigset_t* oldmask ) @@ GLIBC_2.2.5
objdump -T /home/knox/Desktop/Programme/GO/factorio-server-manager/manager/factorio_server_manager_1_1 | grep pthread
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_create
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_sigmask
I have no idea how to handle such a case, i never knew that things will get removed from glibc :( So if anybody knows how to work with this, tell me :)
New compiled version on Ubuntu 20.10 is using pthread_sigmask @GLIBC 2.32
objdump -T run_manager | grep pthread
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_create
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_detach
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.3.2 pthread_cond_broadcast
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.3.2 pthread_cond_wait
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_mutexattr_destroy
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_mutex_destroy
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_mutexattr_init
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_attr_init
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_attr_getstacksize
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_mutex_unlock
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_mutexattr_settype
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.32 pthread_sigmask
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_join
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_attr_destroy
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_mutex_init
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_mutex_lock
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_mutex_trylock
0000000000947a00 g DF .text 00000000000000b2 Base _cgo_try_pthread_create
In theory it should be automatically handled by the linker: https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility/
readelf --dyn-syms -W /lib/x86_64-linux-gnu/libc-2.32.so | grep pthread_sig
1448: 0000000000091ad0 236 FUNC GLOBAL DEFAULT 16 pthread_sigmask@@GLIBC_2.32
1453: 0000000000091ad0 236 FUNC GLOBAL DEFAULT 16 pthread_sigmask@GLIBC_2.2.5
I suspect a problem, that we force a static linking of CGO.
/tmp/go-link-017964132/000027.o: In function `unixDlOpen':
/home/runner/go/pkg/mod/github.com/mattn/go-sqlite3@v1.14.5/sqlite3-binding.c:39981: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/tmp/go-link-017964132/000004.o: In function `_cgo_26061493d47f_C2func_getaddrinfo':
/tmp/go-build/cgo-gcc-prolog:58: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
So if i understand well installing on 18.04 would work? But 20.04 and 20.10 have the wrong glibc version?
20.04 can still work but it is not save that it works. Some 20.04 installation already have the new glibc, some have the old. When you encounter this problem, you can compile it yourself. I uploaded a build, created on Ubuntu 20.10 to this comment, so you can use this one for now. (i will not create a docker build with it, sorry) factorio-server-manager-linux.zip
If we make a build with Ubuntu 20.04 and the new version of glibc will it be compatible with older versions as well? If so we should update the CI jobs to use Ubuntu 20.04 instead of 18.04.
Another option might be to use the Dockerfile-build container to generate the build artifacts, I'd have to test if the binary's generated in that container would work with Ubuntu however.
We can also try removing the static linking from the build commands. It may no longer be needed but I'd have to do some further testing there as well.
If we make a build with Ubuntu 20.04 and the new version of glibc will it be compatible with older versions as well?
No, glibc is designed to be backwards compatible not forwards compatible. So Ubuntu 20.10 should be able able to runt he genarated files from 18.04.
Unfortunatly i did not had time to look into that issue. I think compiling fully dynamic could fix this. But that needs a lot of testing on multiple linux versions.
Yeah removing the static linking seems like the way to go if everything works properly across the OS's.
Seems like that is fixed with linking dynamic. See #263 for more information and please test it :)
Also the docker version?
As said in the PR: Test it with the docker image ofsm/ofsm:fix-glibc
Installed with ofsm/ofsm:fix-glibc can confirm it's working on 20.04:
downloading Krastorio 2 after succesful login:
Thanks for testing @Omaha2002
I merged in the PR. Now develop
will also work.
@knoxfighter mods working but I can't start the server anymore because I can't create the first save file. Did a clean docker install with develop branch.
Can't create a savefile, it says:
logs:
docker-compose logs
I installed the latest docker version ofsm/ofsm:latest. with the commits for fix-glibc and Ubuntu docker. It is possible to create a "first" save file and the server starts. The mods page still has the same problem, can't login, seems as if the fix-glibc commit didn't make it?
ofsm/ofsm:use-ubuntu-docker did work, both save file and mods downloading.
Are you sure, you used the latest image? When you had it already downloaded to need to manually run docker pull ofsm/ofsm:latest
.
Well, I was sure i did but nonetheless did a reinstall and now it works. docker ps showed ofsm:latest apparently it wasn't running latest.
Sorry for the confusion, all is working now, will test with a game this weekend.
Thanks for all the time and effort, much appreciated!
Thanks for helping out with this one @Omaha2002!
Running on Ubuntu 20.10. Nav'ing to other pages is fine, but as soon as I click on the mods page, the app crashes with this output on console.