"Transport endpoint is not connected" bug about mp3fs HOT 22 CLOSED

This sounds like a crash in mp3fs. Can you run mp3fs with the -d flag (debug) and GitHub Gist the output? I'll see if I can see what part of the code causes the issue.

from mp3fs.

Done. The gist is here
https://gist.github.com/vlsd/ca14830bf815557c64ca

from mp3fs.

And just to confirm, the mp3fs command does seem to die when you run that command, right?

from mp3fs.

Yep. Although I have to unmount the mp3 folder by hand, which I suppose is to be expected since it exited uncleanly

from mp3fs.

Alright, I'll try to see if I can reproduce this on my own, hopefully soon.

from mp3fs.

Also, I can replicate it by trying to less the same (or any other) file, so it's not exiftool alone. In 0.32 it would crash during auto-completion in the shell.

Oddly, I can sshfs mount this folder and play music from it remotely (and supposedly locally as well, although I haven't tried) with mocp. Trying to less a file produces the same error though.

from mp3fs.

I am seeing the same or similar behaviour, Ubuntu 14.04:

MP3FS version 0.9
FUSE library version: 2.9.2
fusermount version: 2.9.2
using FUSE kernel interface version 7.19

I get this logged to dmesg:

mp3fs[28987]: segfault at 0 ip 00007f25216fabf7 sp 00007f2520834ae8 error 4 in libc-2.19.so[7f252165d000+1bc000]

from mp3fs.

I'm trying to reproduce this bug, and having some trouble. Does it seem to be related to a particular FLAC file? You said you can reproduce this by running less with this file or any other? Can you reproduce it if your music source directory only contains one FLAC file?

from mp3fs.

Now that you mention it, I might not have been running it on a FLAC file at
all. It was likely an mp3 originally.

On Tue, May 13, 2014 at 10:30 PM, K Henriksson [email protected]:

I'm trying to reproduce this bug, and having some trouble. Does it seem to
be related to a particular FLAC file? You said you can reproduce this by
running less with this file or any other? Can you reproduce it if your
music source directory only contains one FLAC file?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-43038840
.

from mp3fs.

I'm still having trouble reproducing, even if the source file for me is an mp3. Can you try reproducing with when the only thing in your source directory is just one problematic mp3?

from mp3fs.

I am able to reproduce the issue with a single mp3 in my source directory, yes.

from mp3fs.

In my case, I'm exporting the mp3fs folder via NFS to an OSX machine, and just opening the folder. Obviously something it is trying to do to gather metadata on the file is causing the core dump. Gist of -d here:

https://gist.github.com/ross-w/96682f56ade064457fa3

There is only a single mp3 file in the source dir, and the dir is exported readonly. Ignore all the cruft at the start where OSX tries to look for all of these non-existent files - they don't exist.

Aside from the mp3, I can also reproduce with a FLAC file.

Testing method:

1. Mount empty folder from OSX, no crash
2. Create an empty text file in folder and refresh, no crash
3. Put FLAC file or MP3 into the folder and refresh, immediate segfault

from mp3fs.

I narrowed it down to being related to something my shell is doing. This file is a log from me mounting a folder with one file and doing less on the file, first under sh, then under bash and finally under zsh (my default shell). The crash only happens under zsh, and I'm guessing it might be a plugin or something related that is being responsible:
http://paste.ubuntu.com/7463970/

Also note that I'm doing this locally, on the same machine, on the same physical drive. I'll dig a bit more and see if I can find exactly what part of my zsh setup is the culprit.

from mp3fs.

Ok, further hints: this does not happen if I remove the spaces from the file name.

from mp3fs.

Even further hints: the crash happens NOT when the command is run on the file, but during name autocompletion by the shell, if the shell is zsh. Also, it happens if I completely unload my .zshrc file, effectively using a vanilla install of zsh. Editing main issue to reflect this.

from mp3fs.

Alright, good news, now I can reproduce this. Thanks for your help! I'll try to figure out now what causes the problem.

from mp3fs.

Alright, this should now be fixed, and this seemed important enough to make a new release for it. Thanks for helping me track the issue down.

from mp3fs.

Haha I just looked at the diff the connection between cause and effect is crazy hard to infer. Do you know why the overflow was only affecting files with space in their name?

from mp3fs.

My only guess is that it was triggered by the particular pattern of access zsh did when there was a space. I can see it looking for a file of the name 01\ Moonromanticism.mp3 with a backslash, which it wouldn't do for a file with no space in the name, I think. We're falling into the realm of undefined behavior where anything at all can happen, without violating the language standard.

from mp3fs.

Anyway, just tested it and can confirm it fixed the issue 👍

from mp3fs.

Great, glad to hear it.

from mp3fs.

Fixed here also, many thanks! (And sorry for the weird use-case making it pretty difficult to reproduce)

from mp3fs.