New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Cannot initialize system file configuration" #21
Comments
Hmm interesting - thanks for the bug report. I've never seen that error before, can you try updating to the latest commit to see if that fixes it? I made some filesystem related changes. If it still shows that error, can you attach the strace output? |
Thanks for replying!
Let me know if there's anything else I can provide. |
I think this must be because of the /proc/self/cwd usage. I've removed that now, so this might just start working. I have it working here in a virtual machine with 22.04, hopefully some of the recent cleanups fixed it! |
So far it still does the same, even with the latest commits. |
Is it possible you have an old |
Tried deleting it, replacing it with a newer one, changing perms of that file, no change so far. |
Weird! I'm really confused, but I want to solve this -- everything in the strace looks totally normal. If you don't mind trying a few things, maybe we can figure out what it's complaining about... If you run 123 under gdb, can you try breaking on
|
This is what I get with regular home. It....doesn't seem to be called, huh.
With temp home, exiting with /Quit:
That caught me off-guard. Not sure how to interpret this. Let me know if there's anything else I can try. |
Hmm, can you try |
This is what I get:
|
Hmm - I can see it reaches code that if it doesn't think your $HOME is valid (I know you had already figured that out, but just confirming from reading the code). Things it rejects:
All of those seem fine to me:
The stat works, and says S_IFDIR...maybe I'm not translating it properly? 😕 |
Just in case this is the strace at commit e1acff3
|
Wait.. I think I have a theory, hold on for a patch! |
I see this line in your strace output:
I don't think I translate S_IFCHR properly, but I don't know why it's doing that (edit: probably isatty()). Maybe just not returning an error on that case will fix it! |
Pulled and rebuilt, but unfortunately no changes so far. |
Hmm, okay. So I think all of this is just it trying to clean up when it thinks it can't continue, the statx() is probably isatty(), and the ioctls() are trying to put the terminal back into a sane state.
So the error must be just after this:
It only calls that from a few places, things it does:
|
Okay, last thing to try:
Do you also get 0x4000 if you try this? |
Strange again, doesn't seem to trigger.
As for the others:
|
Thanks, wow, it doesn't even reach there! I am so confused! |
There are only like two things that can fail before that.
I really can't see anything else that can fail. That does cause the error you're seeing though:
But "/home/magpie" is obviously a valid pathname --
Can you try this:
I am determined to figure this out now 😆 |
Yeah, I got nothing either, this is quite strange. What makes things really confusing is it working in a different
Locale outputs. (Changing LC_ADDRESS=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=es_ES.UTF-8
LC_TIME=C
LC_COLLATE=C
LC_NUMERIC=en_US.UTF-8
echo $LANG
en_US.UTF-8 My keyboard is Spanish, but changing $HOME like I did should maintain the rest of the environment and DE settings. |
Thanks for running all these tests! This part is interesting:
It does think your pathname is invalid... but why? Your locale and everything else looks totally normal. I'll have to think about this, it doesn't seem to use |
I'm sad to report it doesn't. |
Is it possible the fix for #45 might also fix this? 🤔 It is not allowed to use memcpy() with overlapping ranges, all kinds of random errors can occur, that was also true on UNIX. However.. it mostly seemed to kinda work on UNIX, and 123 does it all the time....which can make weird stuff happen on Linux, I decided to just replace every call to memmove() which is slower, but doesn't care if the ranges overlap. If not I'm out of ideas without being able to single step through the code! |
Pulled, cleaned, rebuilt binutils and rebuilt 123. Still no change. Maybe Lotus really hated magpies and checks for the word in path... |
So weird. What about if you do something like this:
|
I've read through every line of the code, it really seems okay! I've been trying to do weird things to see how to reproduce it. This works:
But obviously you would know if your $HOME was not a directory! What does stat say, is your directory anything unusual, like a bind mount or something?
Maybe also the extended attributes, could this be a MAC issue, like selinux or something?
|
Alright, here goes: $ stat ~
File: /home/magpie
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 821h/2081d Inode: 16646145 Links: 84
Access: (0755/drwxr-xr-x) Uid: ( 1000/ magpie) Gid: ( 1000/ magpie)
Access: 2040-02-06 12:28:16.000000000 +0100
Modify: 2022-05-28 20:53:18.233080212 +0200
Change: 2022-05-28 20:53:18.233080212 +0200
Birth: 2017-08-24 07:48:25.392428140 +0200 $ stat --file-system ~
File: "/home/magpie"
ID: 1d3da6b9465abd65 Namelen: 255 Type: ext2/ext3
Block size: 4096 Fundamental block size: 4096
Blocks: Total: 167457162 Free: 3589837 Available: 1881805
Inodes: Total: 42598400 Free: 40807804
$lsattr -d ~
--------------e------- /home/magpie
$getfattr -d ~
<no output>
$ls -lZd ~
drwxr-xr-x 84 magpie magpie ? 4096 May 28 20:53 /home/magpie EDIT: huh that access time is in the future for some reason. I have noatime and nodiratime in my mount options, could that be? |
Seems normal, although I guess it's weird that your atime is 20 years in the future... hmm, that is after 2038, the famous 2038 problem. This is an interesting clue. |
I actually just noticed that! Edited the post but you were faster 🥷 |
WOW
This is the craziest bug I've seen for months lol. Okay, now that I can reproduce I can track it down... hold on for a patch :) |
|
This is definitely the bug, if you use Perhaps glibc also required __TIMESIZE == 64, but I tried that and no difference. This is why your strace output looked fine, the kernel is working but glibc is returning the wrong result! Absolutely crazy combination of events. I think you just haven't been seeing problems because it only affects 32bit processes. I think I need to check with a glibc internals expert to see if this is supposed to work. |
This turned out to be really interesting after all! Thank you for your efforts and guesswork, this thread ended up with a plot twist! It was (the modern equivalent of) the Y2K bug all along! Since I'm here, allow me to say this whole project is fascinating. Being able to work with such old, binary-only software and getting it to work (pretty well, all things considered!) is nothing but inspiring. |
Does |
That was quite an adventure, wow! Thanks @magpie514 for being willing to help track it down, and thanks @tavianator for figuring out the cpp incantation to solve it! Very relieved we figured out the mystery and things make sense again 😂 |
Glad to have been here. Thanks again for your time and ideas, this was indeed a good one! |
Fascinating. |
System: Ubuntu 22.04 64b
123elf version: 199b81f
Terminal: Konsole (same issue with xterm)
I made a successful binary using the provided scripts and makefile, but executing it just returns a "123: Cannot initialize system file configuration" error.
Trying to run it with gdb doesn't return any form of crash or error message, it terminates normally.
Maybe I skipped some configuration step, but the binary seems fine.
The text was updated successfully, but these errors were encountered: