Re: http fsys - dlna compliance 7.4.32.2 - MTMaximum Byte Size Transfers
John Stirling <[email protected]>
| Newsgroups | gmane.comp.multimedia.helix.devel |
|---|---|
| Message-ID | <[email protected]> |
We tested with an atlas build and it still crashes. We're getting fairly close to needing to get this fixed. Is helix used in any DLNA certified products ? It seems like this would be a fairly common requirement , at least for the bigger brands. So any chance this could get fixed by someone at helix/real ? If not, could someone more familiar with httpfsys give us some assistance in fixing this ? John Eric Hyche wrote: > I would guess that Content-Length's or Chunked-Encoding-Size's > greater than 4GB will be a problem. Content-Length is probably > not as big of a problem. > > Eric > > ============================================= > Eric Hyche ([email protected]) > Technical Lead > RealNetworks, Inc. > > >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On >> Behalf Of John Stirling >> Sent: Tuesday, June 17, 2008 1:03 PM >> To: Greg Wright >> Cc: [email protected] >> Subject: Re: [Helix-client-dev] http fsys - dlna compliance >> 7.4.32.2 - MTMaximum Byte Size Transfers >> >> 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 >> >> > > _______________________________________________ Helix-client-dev mailing list [email protected] http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev