After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 606645 - criticals on rygel console when streaming
criticals on rygel console when streaming
Status: RESOLVED FIXED
Product: libsoup
Classification: Core
Component: HTTP Transport
2.29.x
Other Linux
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2010-01-11 17:37 UTC by Zeeshan Ali
Modified: 2010-01-25 14:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Zeeshan Ali 2010-01-11 17:37:10 UTC
I keep seeing these criticals on server-side when HTTP client stream data from rygel:

(rygel:3864): libsoup-CRITICAL **: soup_message_body_flatten: assertion `priv->accumulate == TRUE' failed
Comment 1 Dan Winship 2010-01-23 20:45:24 UTC
Fixed in git. Thanks.

FYI, the warning would only be triggered if the client included a Range
header, to request only part of the resource. soup-message-server-io has
code to automatically fix up SoupServer responses so that if the client
requested a subrange, we only return that range. But it only works for
non-streamed responses. This is still OK, protocolwise, because you're
allowed to ignore the Range header and just return the full response
anyway, but this would be really inefficient if the client only wanted
a small piece of it. So you might want to look at the Range header
yourself (soup_message_headers_get_ranges()) and return the proper
subrange if appropriate (and if it's not too hard for you to compute
because of transcoding, etc).
Comment 2 Dan Winship 2010-01-23 20:46:26 UTC
(see soup-message-server-io.c:handle_partial_get() for details)
Comment 3 Zeeshan Ali 2010-01-23 22:42:32 UTC
(In reply to comment #1)
> Fixed in git. Thanks.

  Cool!

> FYI, the warning would only be triggered if the client included a Range
> header, to request only part of the resource.

  You mean I get it because I am not properly handling the 'Range' request and push more bytes then requested? I get it this warning soon after the client closes the connection (SoupServer::request-aborted is emitted). 

> soup-message-server-io has
> code to automatically fix up SoupServer responses so that if the client
> requested a subrange, we only return that range. But it only works for
> non-streamed responses. This is still OK, protocolwise, because you're
> allowed to ignore the Range header and just return the full response
> anyway, but this would be really inefficient if the client only wanted
> a small piece of it. So you might want to look at the Range header
> yourself (soup_message_headers_get_ranges()) and return the proper
> subrange if appropriate (and if it's not too hard for you to compute
> because of transcoding, etc).

  I do handle the range header for non-transcoded streams.
Comment 4 Dan Winship 2010-01-25 14:58:29 UTC
(In reply to comment #3)
> I get it this warning soon after the client
> closes the connection (SoupServer::request-aborted is emitted). 

hm... that might be something other than what I fixed then...

if you get it with git libsoup (or with 2.29.6, coming out this week), set a breakpoint on g_log and get a backtrace of where the error is coming from