Re: http fsys - dlna compliance 7.4.32.2 - MTMaximum Byte Size Transfers
Rishi Mathew <[email protected]>
| Newsgroups | gmane.comp.multimedia.helix.devel,gmane.spam.detected |
|---|---|
| Message-ID | <[email protected]> |
Hey John, We havent tested for DLNA compliance internally, this has been typically done by partners like yourself. You will need to drive this, we can provide you the help that you need to fix this issue. If you ask specific questions related to the code/architecture, someone will definitely answer. Cheers, Rishi. At 01:24 AM 9/8/2008, John Stirling wrote: >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 (<mailto:[email protected]>[email protected]) >>>Technical Lead >>>RealNetworks, Inc. >>> >>> >>>> >>>>-----Original Message----- >>>>From: >>>><mailto:[email protected]>[email protected] >>>> >>>>[mailto:[email protected]] On >>>>Behalf Of John Stirling >>>>Sent: Tuesday, June 17, 2008 1:03 PM >>>>To: Greg Wright >>>>Cc: >>>><mailto:[email protected]>[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 >>>>>><mailto:[email protected]>[email protected] >>>>>>http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev >>>>>> >>>>>> >>>> >>>>_______________________________________________ >>>>Helix-client-dev mailing list >>>><mailto:[email protected]>[email protected] >>>>http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev >>>> >>>> >>> >>> >>> >> >> >> >> >> >>_______________________________________________ >>Helix-client-dev mailing list >><mailto:[email protected]>[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 Rishi Mathew Helix Community RealNetworks, Inc. [email protected] http://www.helixcommunity.org http://www.realnetworks.com/products/support/devsupport.html _______________________________________________ Helix-client-dev mailing list [email protected] http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev