Segmentation fault with 3.0 on RHEL 7.4 #5550
Comments
|
Specifically, this crashes on fish installed on RHEL 7 via nix. Can you try building it manually to rule out any nix changes (I know there are a few), or at least try a log from one of those builds to remove all the nix paths? There's a few things here that look weird, one is that the last message of
(http://man7.org/linux/man-pages/man2/access.2.html) Which could be down to some kind of sandboxing or some such. @ridiculousfish's knowledge would be appreciated here. |
|
I am a novice |
What I mean is building without nix.
Can you upload the output for a fish built using linuxbrew instead of nix? It's both that nix does special stuff, and that the nix output is quite noisy (these ugly /nix/store/buesfhaeiodfhiosjd paths). Also you might get an actual backtrace here, which would be great. |
I still need to get the curses dependency on that machine somehow (it is not currently installed), and the easiest way to do that seems to be by using |
No. What I'm suggesting is simply that I feel like running fish outside of nix would result in nicer output. It's probably alright to get the dependencies via nix (I'm assuming you don't have root, because otherwise this'd be a simple |
|
Hey, I’d like to add my 2 cents. I would guess that the problem is in the weird combination of nix and proot. The output with exactly the same hash as in OP’s log files is available straight in the official nixpkgs cache, and I have no problems running it: |
|
This is a null dereference; gdb should be able to tell us where if we can catch it. But the Can you please try repeating the gdb command with |
|
https://pastebin.com/raw/Sq0rPqjf Fish installed via linuxbrew. |
|
Compiling from source, manually, also produces segmentation fault. During the compilation I get the following warnings: |
|
|
|
|
Yeah, glibc deprecated some stuff without easy replacement. Not to worry. Your log shows that it crashes in
Which has an const char *dir = getenv("XDG_RUNTIME_DIR");
if (dir != NULL && access(dir, mode) == 0 && check_runtime_path(dir) == 0) {
result = str2wcstring(dir);
} else {
const char *uname = getpwuid(geteuid())->pw_name;
// /tmp/fish.user
std::string tmpdir = "/tmp/fish.";
tmpdir.append(uname);So, I am assuming the following:
|
|
I'm trying to use fish on a cluster, btw. |
|
Workaround when starting fish from bash: # ~/.bashrc
export XDG_RUNTIME_DIR=/run/user/$(id -u) |
|
@horta doesn't work for me. |
|
Yeah, it still gives me segmentation fault randomly. |
|
@horta that's great, can you please try this in gdb: $ gdb fish From within gdb, before quitting, it would be good to get a backtrace |
|
Might fix fish-shell#5550 at least partially.
|
@horta: That still looks like the crash I described. Can you try b8efd89? Also, can you clarify this for me:
Does fish, without setting $XDG_RUNTIME_DIR in bash outside, crash randomly or always? If it crashes always if you don't do that and only randomly if you do, then that's a change in behavior that probably means we'd got a few different crashes here. Which could possibly all be down to the same root cause - us not expecting that getting passwd info fails. The other crash then might not be "random" at all, but e.g. triggered by tilde-expansion (because that gets $HOME for the mentioned user). (or it's down to |
|
I'm working on a cluster. In the login machine:
But once I log into a worker node:
I will try that commit in a moment/ |
@horta: Is that directory accessible? If it isn't, that still means the else-branch is taken, which still leads to the crash. |
|
It works @faho , but with a "warning": Master node:
Worker node:
Warning: |
That folder exists (and accessible) in the master node. That folder does not exist and cannot be created on a worker node. |
Which means we won't get our runtime dir, which is why we correctly try other ways to get one. Note that this is against the XDG Base Directory Specification ("The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700. "), so you can expect more things to fail.
And that warning is also correct. We can't get our runtime path, so we warn about it, because you are now running fish with reduced functionality. In particular universal variables won't actually be shared across instances. Set $XDG_RUNTIME_DIR to a path that is accessible to that fish, or make it so getpwuid works and gives us an accessible $HOME. |
|
Thanks, I didnt know that. I will change my shell files accordingly... |
|
That is great. It works now with fish 3.0.0. I don't manage the cluster but I manage a group of people that uses it, so I need to sometimes fix those issues. Here it is what I come up with for those interested: if [ -z "$XDG_RUNTIME_DIR" ];
then
export XDG_RUNTIME_DIR=/run/user/$(id -u)
fi
if ! touch $XDG_RUNTIME_DIR/.can_i_write 2>/dev/null;
then
export XDG_RUNTIME_DIR=~/.run/user/$(id -u)
mkdir -p $XDG_RUNTIME_DIR
chmod 700 $XDG_RUNTIME_DIR
fi |
Otherwise this is a NULL dereference and then crash. Fixes #5550.
|
This should now hopefully be fixed in master and the upcoming 3.0.1. |
dniku
changed the title
|
Looks like 963e321 is the pick, thanks faho! |
|
With @horta's workaround, I am still seeing frequent crashes, both during startup and during autocompletion. I don't see any pattern to them (the sequence of actions that triggers the crash usually, but not always, ceases to work after a restart), but |
@Pastafarianist: Crashes are not expected behavior, no. Can you try to build 963e321, i.e. the "Integration_3.0.1" branch (which will become the 3.0.1 release shortly)? That should make the workaround unnecessary. If you can still reproduce the crashes with that, I'd really love to have a stack trace. |
|
@Pastafarianist you can also enable core dumps to automatically generate a fish.core in |
|
I have enabled core dumps and will upload them as soon as I get a crash. As for building from source, unfortunately, as a novice Nix user, I do not know how to specify that I want to download a specific commit. |
This looks like a different issue. Do you want me to file a new bug report? |
Yes, and yes! |
|
On second thought, #5605. |
Segfault is also produced just by running
fish.I don't have an easy way to test the issue with 2.7.1 as I am running on a server without root, where I installed
fishusingnix, itself installed viaprootin~/.nix.This gist contains outputs of the following commands:
nix log nixpkgs.fishfish -d 5gdb fishstrace fishNote that the output of
gdb fishis most likely unhelpful as it seems thatfishdetects that it is launched in a non-interactive environment (probably due togdb) and does something weird.Also note that I have also tried to install
fishon the same machine using Linuxbrew, and it also failed with a segfault.The text was updated successfully, but these errors were encountered: