RangeError: byte length of Int32Array should be a multiple of 4

[Joshua Orvis]

I have a very simple configuration so far, which looks like this:

<script language="javascript">
  new Browser({
    chr:          'unitig_0|quiver',
    viewStart:    700000,
    viewEnd:      900000,


    coordSystem: {


    },


    sources:     [{name:                 'Genome',
                   twoBitURI:            './data/genome.2bit',
                   tier_type:            'sequence'},
                  {name:                 'Genes',
                   desc:                 'GALES predicted genes',
                   bwgURI:               './data/attributor.annotation.bb',
                   stylesheet_uri:       '//www.biodalliance.org/stylesheets/gencode.xml'}
                 ],
  });
  </script>

The BED (before bigBed conversion) looked like this:

$ head -n 5 attributor.annotation.bed
unitig_0|quiver 0 192 . 0 - 0 192 0 1 192, 0,
unitig_0|quiver 320 1331 . 0 + 320 1331 0 1 1011, 0,
unitig_0|quiver 1336 1897 . 0 + 1336 1897 0 1 561, 0,
unitig_0|quiver 1960 2398 . 0 - 1960 2398 0 1 438, 0,
unitig_0|quiver 2405 2822 . 0 - 2405 2822 0 1 417, 0,

Then I added locus identifiers to the bed:

$ head -n 5 attributor.annotation.withloci.bed
unitig_0|quiver 0 192 HYLE_00000 0 - 0 192 0 1 192, 0,
unitig_0|quiver 320 1331 HYLE_00001 0 + 320 1331 0 1 1011, 0,
unitig_0|quiver 1336 1897 HYLE_00002 0 + 1336 1897 0 1 561, 0,
unitig_0|quiver 1960 2398 HYLE_00003 0 - 1960 2398 0 1 438, 0,
unitig_0|quiver 2405 2822 HYLE_00004 0 - 2405 2822 0 1 417, 0,

Converted to bigBed and changed my configuration above, but now it fails to load the gene track with this error in Javascript:

worker-all.js?version=0.13.8:1 Uncaught RangeError: byte length of Int32Array should be a multiple of 4
    at new Int32Array (<anonymous>)
    at s.data.slice.salted.fetch.timeout (worker-all.js?version=0.13.8:1)
    at XMLHttpRequest.u.onreadystatechange (worker-all.js?version=0.13.8:1)

I'm not sure why it would work with one version and not the other.  I found this thread which implied it could be an issue with cross-origin requests, but that shouldn't be happening here.  I'll only be doing local.

Any idea what's happening here?

[Thomas Down]

Dear Joshua,

Sorry to hear you're having problems.  I've just run a quick test locally taking your sample fragment from attributor.annotation.withloci.bed, making a bigBed using:

                bedToBigBed -type=bed12 attributor.annotation.withloci.bed uni.sizes attributor.annotation.withloci.bb

...and viewing it in a test Biodalliance instance.  Everything seems to be working as expected from this end.

One thought: did you replace your original bigBed file with a new file of the same name?  If so, it's just possible that there's some stale data in your browser caches which is causing problems.  Could you try clearing all your caches (or running a different browser) and see what happens?

If you're still running into problems after clearing caches, might it be possible to send me a sample bigbed file (offlist is fine) which demonstrates the problem?

Best wishes,

            Thomas.

--
You received this message because you are subscribed to the Google Groups "Dalliance genome-viewing tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to biodalliance-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joshua Orvis]

I posted a reply via e-mail last night but it didn't show up here.  Reposting just in case:

Thanks for looking into this Thomas.  No, I didn't overwrite the file, I can alternate the bwgURI value in my config between 'attributor.annotation.bb' (which works) and 'attributor.annotation.withloci.bb' which doesn't.  I've tried both doing CTRL+Shift+R and in an incognito window too so caching wouldn't be an issue.

My config is the same as above, but I've put the files in a Dropbox here so you can check them out if you like.  Much appreciated.

https://www.dropbox.com/sh/hz9uqrdb68f1dd8/AAA6I9N20hnOBs9rFUzV4Hsea?dl=0

[Thomas Down]

Thanks Joshua, i’m on the road right now but should be able to take a look tomorrow.

--
You received this message because you are subscribed to the Google Groups "Dalliance genome-viewing tools" group.

To unsubscribe from this group and stop receiving emails from it, send an email to biodalliance-d...@googlegroups.com.

[Thomas Down]

Dear Joshua,

Thanks for providing the sample file.  I've done some testing and, on my machines, it appears to be working fine using either Biodalliance 0.13.8, or a recent build from Git:

....so I don't think there's anything fundamentally wrong with the file.

Could you provide some details of the server you're hosting the file on.  One possibility: Biodalliance expects web servers to handle the Range header to allow partial fetches of indexed files such as bigBed.  Most production web servers do this by default.  However, some "development" servers (the Python built-in server being one example) don't, and it's possible that might cause the kind of error you're seeing.

(If it's helpful, I'm happy to host the files on one of my servers so you can experiment with accessing them there -- but obviously, won't do this without explicit permission).

             Thomas.

To unsubscribe from this group and stop receiving emails from it, send an email to biodalliance-dev+unsubscribe@googlegroups.com.

[Joshua Orvis]

Yes, the server seemed to be the issue.  I actually fixed it by subclassing http.server's CGIHTTPRequestHandler and creating a RangeRequestHandler which does support Range requests.  Embedding this class within my own code, embedded Biodalliance now seems to work fine when called from Python's http.server.

Here's that portion of the code:

https://github.com/jorvis/GALES/commit/8cef4ffa79fb0eac7b608f97ac3163fe5778a548

Thanks for your help.