JBrowse issue: "bad file descriptor"

[kew24]

I got this error from JBrowse, here is the stack trace:

Error: EBADF: bad file descriptor, close
No stack trace available

Upon initially loading in a fasta + fai, and a bam + csi, I was able to specify a region and see then alignments there. When I tried selecting a different region, instead of seeing alignments, I got this error instead. Running this on a Mac.

Let me know if you need any other information to debug; any suggestions would be appreciated – thanks!

[cmdcolin]

interesting...I have never seen that one before

I wasn't able to reproduce on my mac with v3.6.4 (latest). does this happen always or intermittently/rarely?

one message I saw while googling EBADF is "An EBADF error generally is a bad file descriptor. This might be an issue with the file I/O at the system level rather than a simple issue with your Node.js."

is there any network file system or external drive or anything like that potentially?

[kew24]

Thanks for the quick response!

I've actually just started using JBrowse, so can't speak much to the frequency of this error... but after the initial occurrence of the error, I quit the app, tried opening / restarting / creating new sessions and immediately got the error again. After several attempts, I created another new session, and this seemed to work for one region – then, when I tried with a different region, I got that same EBADF error. So, at least somewhat reproducible for me.

I am accessing network files for my fasta & bam – so there could be an issue there. I'm still able to access and interact with that file though, so I'm not quite sure what's going on.

I could try copying the file to test fully locally and remove that network/external piece of the puzzle, but don't want to rely on that as a full solution. If you end up thinking of any other workarounds or suggestions, I'm all ears. Thanks!

[cmdcolin]

One possible workaround would be to run a fully fledged HTTP server on whatever remote server you are using, and then you can paste URLs to the file into jbrowse. the http server might have somewhat predictable behavior for serving remote files. that's not always possible though

One thing that could be worth considering from our end (brainstorming somewhat internal technical details...) is to have some sort of recovery in https://github.com/GMOD/generic-filehandle2/blob/main/src/localFile.ts so e.g. upon detecting an EBADF issue, try to re-open the file...

[sophielemoine]

Dear all,
I have this error very often, and it can happen on a track that was loaded perfectly the moment before. It happens on bam files for me. When it's getting bad, I cannot get rid of it.
I use jbrowse on a mac, MacOS version 15.6.1 and last available version of jbrowse2 but it's not a new issue for me.
The files are uploaded from a local network.

thanks a lot for your work :-)

[cmdcolin]

Thanks for reporting @sophielemoine

I made a possible fix in one of our libraries and will try to make a new release of the desktop app soon with the fix included

[cmdcolin]

I released v3.6.5 with a small fix. i would actually be surprised if it fixed it, but if you want to retest and see if it helps let me know

[kew24]

I'll try it out & report whether it works! Thanks!

[kew24]

This release is actually working so far for me... I've been able to start a new session, load in the same fasta & bam, and zoom into multiple different regions w/o the error occurring (which is the same behaviour that previously caused an error). I'll keep playing around with it to see if I hit the error again, but so far, so good! Thank you for addressing this so quickly, @cmdcolin!

I'm happy to close this issue if the new release works for @sophielemoine, too.

[kew24]

Actually – I've let the window sit open since my last comment, and I just zoomed to a new area. The alignments from the bam showed up for a while, then I did get that same error:

Error: EBADF: bad file descriptor, close
No stack trace available

[cmdcolin]

darn :) I will probably try to set up a network filesystem to try to help reproduce the issue locally

[kew24]

Thanks. Some more info if it helps to debug:

• this only appears to be happening with the bam I have: the reference sequence file still shows up (w/ no error) even when the bam gives that EBADF error. This bam has a ".csi" index.
• the messages that show up on the track start with "Downloading alignments", then briefly a "Processing" message, before quickly erroring out.
• I have caught it in a weird state where after loading, the alignments show up, but the coverage area has the "EBADF" error. After this, if I pan to the side, both give me the "EBADF" error.
• my original bam file was a symlink, so I wondered if this was the cause of the error. I just tried again with the actual file, and got the same error.
• I copied over my bam locally, and loaded this in. After about an hour, I don't have a EBADF issue, so it's likely something network/server related. Interestingly, this type of action works fine with IGV and all other applications I've used.

[cmdcolin]

I tried using sshfs on linux to test out this condition but couldn't reproduce the error. Do you know what program/setup you are using on mac?

[kew24]

I'm using samba/smb! Finder cmd+k to "Connect to Server", and then smb

[cmdcolin]

I went and got a samba server set up on a ubuntu linux remote machine, connected to it from a mac with the that ctrl+k connect to server smb procedure, and tested using jbrowse desktop 3.6.5. I am only scrolling around with a BAM file and csi index, different chromosomes, clicking to different regions, zoom in and out, etc

unfortunately I haven't been able to reproduce the error yet though! weird stuff.