Crash

[diego-rt]

Could it be that the recent updates are causing jbrowse to crash? It only seems to happen when I have a MAF track loaded. Crashes seem to be triggered on close zoom ins but not when too zoomed out. It used to work fine before. Happy to provide some log if you point me to where to find it.

Thanks!

[cmdcolin]

sorrry about the crash...if you are using jbrowse desktop on a mac for example, you can check out the "developer tools console" (which contains various errors and console logs)

here is a screenshot showing the "toggle developer tools" and then the console is below

[diego-rt]

No worries at all! Still a jbrowse fan ;)

I can't seem to catch the error on the console. It dies before anything gets printed. I think the other errors are unrelated.

[cmdcolin]

hmmm...that seems to indicate maybe there is an out of memory or something of the nature. the new 'mouseover tooltips' that were recently added might increase memory usage somewhat but it would be odd that it happens on 'close zoom in' (e.g. viewing a small region?) vs zoom outs

[cmdcolin]

if you have the data files handy by chance i could try to take a look at it

[diego-rt]

Yes this typically happens for memory reasons but in this case I got 64 GB memory and it usually only happens after extended browsing and not after a few seconds.

That would be great! I'll drop you an email with the data.

Thanks again!

[cmdcolin]

Thanks so much for sending this sample data.

I confirmed the slowness and made some changes that should help, I tried to keep the new tooltip functionality which does cost a little extra CPU but I made the calculations faster and more memory efficient so shouldn't crash

Thanks as always with being super helpful with sharing crash reports like this. If you still run into any more crashes please let me know!

It is kind of a random thing but (I think!) even with 64gb of ram on your machine jbrowse will often not even try to use all this memory, the javascript VM is often limited to like 2-8gb or something and so we have to be really memory efficient or the javascript garbage collector starts going crazy

[diego-rt]

Hi @cmdcolin !

Thanks a lot for the quick fix! And thanks for being so positive about the bug reports! I often worry I might be posting too many issues so happy to hear they are well received.

I can confirm that it seems to work now. I actually really like the new tooltips by the way. It would be exciting if in the future somehow the information of the other genome coordinates could be used to "link out" to that other assembly at that position. It would be complicated logistically since one would need to tell JBrowse where all those assemblies and (maybe) MAF/BED tracks are, but there might be ways. Perhaps it could work only for those assemblies that are already open in another jbrowse view?

Other than that, just a small bug report. Does it also happen for you that the blue selection box only gets to row 71? I'm attaching a picture below.

[cmdcolin]

i'll check into the issue with the blue box

It would be exciting if in the future somehow the information of the other genome coordinates could be used to "link out" to that other assembly at that position. It would be complicated logistically since one would need to tell JBrowse where all those assemblies and (maybe) MAF/BED tracks are, but there might be ways. Perhaps it could work only for those assemblies that are already open in another jbrowse view?

Absolutely, this is what I want to add next! Making this tooltip feature was a intermediate step that sort of "proves" that we can reason about the coordinates from the user interface side of things, so we can add the ability to create navigation now

I'm also working on a project to bulk load tons of genomes into jbrowse now (https://jbrowse.org/jb2hubs/, built on the back of work done by UCSC) and so the goal is to enable the linkage to these large multi-way alignments with that!