Re: http fsys - dlna compliance 7.4.32.2 - MTMaximum Byte Size Transfers
John Stirling <[email protected]>
| Newsgroups | gmane.comp.multimedia.helix.devel,gmane.spam.detected |
|---|---|
| Message-ID | <[email protected]> |
Any response to this ? John Stirling wrote: > 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 > _______________________________________________ Helix-client-dev mailing list [email protected] http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev