Bug 713474 - spice server crash on ring_remove ASSERT(item->next != NULL && item->prev != NULL)
spice server crash on ring_remove ASSERT(item->next != NULL && item->prev != ...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-server (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Yonit Halperin
Desktop QE
Depends On:
Blocks: 723676
  Show dependency treegraph
Reported: 2011-06-15 10:04 EDT by Yonit Halperin
Modified: 2012-03-06 05:22 EST (History)
6 users (show)

See Also:
Fixed In Version: spice-server-0.8.2-1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-12-06 10:21:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
proposed solution (2.16 KB, patch)
2011-06-15 10:14 EDT, Yonit Halperin
no flags Details | Diff
solution v2 (2.23 KB, patch)
2011-07-12 08:28 EDT, Yonit Halperin
no flags Details | Diff

  None (edit)
Description Yonit Halperin 2011-06-15 10:04:40 EDT
Description of problem:
When spice client connects/reconnects to the server, the red_worker might reach a scenario where it tries to remove from the "current tree" an item that has already been removed and released. Specifically:

1. client is not connected
2. surface's x current tree contains drawable d1
3. client gets connected
4. drawable d2 is being processed. It has the same surface and region as d1.
5. red_current_add_equal is called
   (i) red_pipe_add_drawable(d2) is called ==> since the client wasn’t connected before, red_handle_drawable_surfaces_client_synced performs red_current_flush on surface x.
   (ii) remove_drawable(d2) is called while d2 is no longer in "current" and has already been released.
   (iii) ASSERT(item->next != NULL && item->prev != NULL) occurs in the call
         to ring_remove in current_remove_drawable

How reproducible:
I encountered the crash while preforming tests on S3/4 support (the patches are not yet committed). The guest was Windows xp. 
1) I logged in 
2) I started playing a movie with VLC, and then I performed standby. 
3) While returning from stand by, I disconnected the client and reconnected it. Then the crash occurred. 
However, this bug is not related to S3 and exists since offscreen surfaces were introduced (RHEL 6.1)
Comment 2 Yonit Halperin 2011-06-15 10:14:46 EDT
Created attachment 504884 [details]
proposed solution
Comment 5 Yonit Halperin 2011-07-12 08:28:20 EDT
Created attachment 512413 [details]
solution v2

This version is more efficient since it removes the other_drawable
from the tree before red_handle_drawable_surfaces_client_synced is called.
In this manner, other_drawable won't be unnecessarily rendered if
update_area is called.
Comment 8 errata-xmlrpc 2011-12-06 10:21:23 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.