Re: http fsys - dlna compliance 7.4.32.2 - MT Maximum Byte Size Transfers
John Stirling <[email protected]>
| Newsgroups | gmane.comp.multimedia.helix.devel |
|---|---|
| Message-ID | <[email protected]> |
Greg Wright wrote: > John Stirling wrote: >> We're running our cayene build through the DLNA compliance test suite. >> >> There is a requirement to handle content-length, chunk-size, range >> fields with values up to 2^48. Currently this test crashes helix - >> the crash point being an attempt to dynamically allocate 2Gb in >> CHTTPFileObject::DecodeChunkedEncoding. It looks like helix is only >> set upo to deal with a max of 2^32 currently ? >> >> Before I look into this in detail, is anyone aware if this has been >> fixed in a later version of httpfsys ? If not, any pointers to an >> easy fix appreciated. I'm currently assuming that converting >> appropriate variables in httpfsys to u64 will probably do it (I'm >> working on the defintion of 'appropriate') > > I assume it is crashing because the alloc returns NULL (no alloc that > size possible) and the NULL is de-refed? > > We did do some work in this area to detect bad chunk sizes I remember. > And, that method on 310Atlas is different then on 150Cay. So, my guess > would be yes. You still wouldn't be able to just alloc any amount of > memory you want, but it shouldn't crash. The only way to tell though, > for you case, is to test it. > Apart from avoiding this specific crash, do you think atlas is also likely to handle content-length, chunk-size etc values greater than 32 bit ? > > --greg. > > > >> >> John >> >> >> >> >> >> >> >> >> _______________________________________________ >> Helix-client-dev mailing list >> [email protected] >> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev >> > _______________________________________________ Helix-client-dev mailing list [email protected] http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev