This is another bug (see bug 675640) that ends in memory corruption when more than one shmsink is reading from a shmsrc and one of them disconnects.

The same gst-launch command in bug 675640 should show the problem, but I have not been able to reproduce the issue with it. The problem has been found with a bigger app that uses shmsrc/shmsink.

Imaging we have these list of buffers (in ShmPipe) and we iterate through them in sp_writer_close_client. 

v means client has ack the buffer
x means client has decremented buffer use count (without ack)

              Client 1     Client 2

0 0x1d3d1c0                   
1 0x1d4ef80
2 0x1d4ef40      v
3 0x1e01940      v

If we iterate in the sp_writer_close loop, we have

              Client 1     Client 2

0 0x1d3d1c0                   x
1 0x1d4ef80                   x
2 0x1d4ef40      v            x   <-- we need a valid prev_buf
3 0x1e01940      v

But prev_buf is still NULL... prev_buf assignment should be outside the client loop.

  for (buffer = self->buffers; buffer; buffer = buffer->next) {
    int i;

    for (i = 0; i < buffer->num_clients; i++) {
      if (buffer->clients[i] == client->fd) {
        if (!sp_shmbuf_dec (self, buffer, prev_buf, client))
          goto again;
        break;
      }
      prev_buf = buffer;
    }
  }