New issue
Advanced search Search tips

Issue 906811 link

Starred by 2 users

Issue metadata

Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug
Gfx



Sign in to add a comment

Running FreeCAD with crosvm with virtio-gpu crashes crosvm

Project Member Reported by davidri...@chromium.org, Nov 19

Issue description

FreeCAD crashes during startup with virtio-gpu enabled.

Stack trace from coredump:

x86_64-cros-linux-gnu-gdb --core /tmp/crosvm.20181119.110037.31047.core /build/eve/usr/lib/debug/usr/bin/crosvm.debug
set sysroot /build/eve
where

(gdb) where
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x000078985532cd61 in __GI_abort () at abort.c:79
#2  0x00007898553234e4 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7898557f3065 "offset == 0",
    file=file@entry=0x7898557f06c3 "iov.c", line=line@entry=110,
    function=function@entry=0x7898557f30d0 "size_t vrend_write_to_iovec(const struct iovec *, int, size_t, const char *, size_t)") at assert.c:92
#3  0x0000789855323593 in __GI___assert_fail (assertion=0x7898557f3065 "offset == 0", file=0x7898557f06c3 "iov.c", line=110,
    function=0x7898557f30d0 "size_t vrend_write_to_iovec(const struct iovec *, int, size_t, const char *, size_t)") at assert.c:101
#4  0x00007898557db478 in vrend_write_to_iovec (iov=<optimized out>, iovlen=1, offset=<optimized out>,
    buf=0x7895747ad380 "\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\332\332\332\377\332\332\332\377\332\332\332\377\332\332\332\377\332\332\332\377\332\332\332\377\332\332\332\377\332\332\332\377\060\006", count=<optimized out>) at iov.c:110
#5  0x00007898557c0f2a in write_transfer_data (res=0x7895747ac7d0, iov=0x7895749643b0, num_iovs=63,
    data=0x7895747acdc0 "\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\332\332\332\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377\362\362\362\377"..., dst_stride=1056, box=0x789599417c80, level=0, offset=209920, invert=192) at vrend_renderer.c:5953
#6  0x00007898557ba40d in vrend_transfer_send_readpixels (ctx=<optimized out>, res=<optimized out>, iov=<optimized out>, num_iovs=<optimized out>,
    info=<optimized out>) at vrend_renderer.c:6526
#7  vrend_renderer_transfer_send_iov (ctx=<optimized out>, res=<optimized out>, iov=<optimized out>, num_iovs=<optimized out>, info=<optimized out>)
    at vrend_renderer.c:6600
#8  vrend_renderer_transfer_iov (info=<optimized out>, transfer_mode=<optimized out>) at vrend_renderer.c:6666
#9  0x00007898557ad530 in virgl_renderer_transfer_read_iov (handle=<optimized out>, ctx_id=<optimized out>, level=0, stride=1429385074, layer_stride=0,
    box=0x7895994176a0, offset=209920, iovec=0x0, iovec_cnt=0) at virglrenderer.c:147
#10 0x0000569c66f34c9c in ?? ()
#11 0x0000000000033400 in <arch::DeviceRegistrationError as core::fmt::Debug>::fmt ()
#12 0x0000000000000000 in ?? ()
 
Can you reproduce this on QEMU?  If not, it maybe an external texture, which is not adequately supported in virgl.  FYI, for https://gitlab.freedesktop.org/virgl/virglrenderer/issues/51, the plan is significantly revamp both the allocation and transfer paths.  Part of that is to explicitly differentiate between the external and non-external texture cases.
I don't have a qemu setup going at this point.  Is this something you can easily test: 
(sudo apt-get install freecad && freecad)
freecad works on QEMU with ToT virglrenderer + e1febb guest Mesa.
I was doing the refactoring described in #19 (crrev.com/c/1357195), and if this is the same bug as crbug.com/875998, differentiating the external and non-external paths is not enough.

The problem is the guest reserves memory before the host allocation has occurred:

https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c#L217

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/virtio/virtgpu_ioctl.c#L255

We really need a way to know the host stride and size before the allocation occurs if the we want Mesa to report the correct stride.

But then again, this bug may be totally unrelated to crbug.com/875998.  Freecad also works with QEMU with guest Mesa at ToT-ish (fcf15a).  I would verify (1) guest Mesa is new enough to avoid these bugs and (2) if this crash is a case of an EGLImage imported in virglrenderer.
Labels: -Grfx Gfx
Labels: -Pri-3 M-74 Pri-2
Owner: gurcheta...@chromium.org
Status: Assigned (was: Untriaged)

Comment 7 by gurcheta...@chromium.org, Jan 16 (6 days ago)

Status: Started (was: Assigned)

Sign in to add a comment