> > well, nothing specific, but for example early on we had some confusion > in drm_gralloc (when adding dmabuf fd support) about who close()d the > fd's. Resulting in same fd getting closed twice (although some > completely unrelated file handle might have snuck into that slot > between the two close()s). > > Or you could end up w/ the same sort of thing for gem handles (which > are unique to the drm device fd, so if you open() the device multiple > times..). I did initially have some confusion about this, w/ multiple > fd_bo's (or pipe_resource's) being created for a given gem handle, and > first one that gets deleted takes away the backing store that both > userspace references where using. > > You might want to look at freedreno_drm_winsys.c and the crazy things > it does.. I suspect virgl might need similar hacks. That is really > one part of two, that ensures that we share the same pipe_screen, and > therefore (from libdrm) fd_device, for a given drm device fd. The > other part is that fd_device has hashtables to deal w/ double import > of gem buffers.
I think Rob Clark might be on the right track here. it sounds like the host is sending double deletes for some objects, which sounds like a possible reference counting bug in the host. So possibly something drm_gralloc, but it could be a bug in mesa, though I haven't triggered anything like this yet. I'd be more willing to look at this if/when there is an easy to produce android-x86 image that I could just drop newer mesa/drm_gralloc into, I suppose I could look at ARM images, but I'm not really setup for cross dev, and I've a few other things to be doing. Dave. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
