I am getting an error when the gui-daemon in dom0 receives a MSG_MFNDUMP
message from the domU gui-agent. Somehow the number of frame numbers reported
from the domU doesn't match up with the size of the window. I've posted the
log from the dom0 guid at the end of this message.
Initially, it looks like a window for gsd-xsettings is created just fine and
the dom0 receives the messages, no problem. For testing, I then started an
instance of xclock in domU and it runs into trouble when doing the mfndump.
Looking at the log messages, I can't tell if the size of the window is supposed
to be 164x164 or 1280x1024. Xclock is usually has a small application window,
but using either size, something erroneous is going on. There is some issue
when it comes to computing num_mfn. num_mfn is computed with the following
code snippet:
pixels = pixmap->devPrivate.ptr;
pixels_end =
pixels +
pixmap->drawable.width * pixmap->drawable.height *
pixmap->drawable.bitsPerPixel / 8;
off = ((long) pixels) & (4096-1);
pixels -= off;
num_mfn = ((long) pixels_end - (long) pixels + 4095) >> 12;
shmcmd.width = pixmap->drawable.width;
shmcmd.height = pixmap->drawable.height;
num_mfn is computed by using the starting address, adding the amount of data
the window occupies to find the ending address, and subtracting the two. There
are a few extra things to align the address to 4K pages. In the error log
below, the width and height that are part of the MSG_MFNDUMP are 1280x1024.
Yet, somehow num_mfn is only 0x141. According to the above code and assuming 3
bytes per pixel, it should be something close to (1280x1024x3)/4096 = 0x3c0.
Even if the size was 164x164, num_mfn should be close to (164x164x3)/4096 =
0x19. Somehow the dom0 receives a width and height of 1280x1024 yet it also
receives from the domU that num_mfn = 0x141.
Looking at the code for computing num_mfn, the only thing I can think of that
might affect num_mfn being too small is truncation error from doing pointer
arithmetic using "long." There could be 64 bit addresses but only 32 bit longs
and some higher order bits are being lost when computing num_mfn. Maybe
something like "ptrdiff_t" or "uint64_t" could have been used. That being
said, it shouldn't matter because everything was compiled for 64 bit machines,
right?
Any help figuring out what's going on here would be greatly appreciated!
dom0 guid log:
Created 0x200003(0x600001) parent 0x0(0x19b) ovr=1 x/y -1/-1 w/h 1/1
set title for window 0x200003
set title for window 0x200003
Created 0x200004(0x800001) parent 0x0(0x19b) ovr=0 x/y 10/10 w/h 10/10
set WM_NORMAL_HINTS for window 0x200004 to min=0/0, max=0/0, base=0/0, inc=0/0
(flags 0x0)
set title for window 0x200004
set class hint for window 0x200004 to (linux_domu:Gsd-xsettings,
linux_domu:gsd-xsettings)
XDestroyWindow 0x200004
cannot lookup 0x200004 in wid2windowdata
cannot lookup 0x200004 in wid2windowdata
cannot lookup 0x200004 in wid2windowdata
cannot lookup 0x200004 in wid2windowdata
cannot lookup 0x200004 in wid2windowdata
cannot lookup 0x200004 in wid2windowdata
cannot lookup 0x200004 in wid2windowdata
cannot lookup 0x200004 in wid2windowdata
cannot lookup 0x200004 in wid2windowdata
cannot lookup 0x200004 in wid2windowdata
Created 0x200005(0xa00001) parent 0x0(0x19b) ovr=0 x/y 10/10 w/h 10/10
set WM_NORMAL_HINTS for window 0x200005 to min=0/0, max=0/0, base=0/0, inc=0/0
(flags 0x0)
set title for window 0x200005
set class hint for window 0x200005 to (linux_domu:Update-notifier,
linux_domu:update-notifier)
Created 0x200006(0xc0000a) parent 0x0(0x19b) ovr=0 x/y 0/0 w/h 164/164
set WM_NORMAL_HINTS for window 0x200006 to min=0/0, max=0/0, base=0/0, inc=0/0
(flags 0x0)
set title for window 0x200006
set class hint for window 0x200006 to (linux_domu:XClock, linux_domu:xclock)
handle_configure_from_vm, local 0x200006 remote 0xc0000a, 164/164, was 164/164,
ovr=0, xy 0/0, was 0/0
MSG_MFNDUMP for 0x200006(0xc0000a): 1280x1024, num_mfn 0x141 off 0x10
handle_mfndump for window 0x200006(remote 0xc0000a) got too small num_mfn= 0x141
release_all_mapped_mfns running
Obtained 8 stack frames.
ErrorHandler: BadShmSeg (invalid shared segment parameter)
Major opcode: 130 (MIT-SHM)
Minor opcode: 2 (X_ShmDetach)
ResourceID: 0x0
Failed serial number: 98
Current serial number: 99
release_all_shm_no_x11_calls running
Obtained 15 stack frames.
qubes-guid(+0x78ca) [0x5589679328ca]
qubes-guid(+0x9d98) [0x558967934d98]
/lib/x86_64-linux-gnu/libc.so.6(+0x43041) [0x7f1426248041]
/lib/x86_64-linux-gnu/libc.so.6(+0x4313a) [0x7f142624813a]
qubes-guid(+0xa21c) [0x55896793521c]
qubes-guid(+0x5282) [0x558967930282]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f1426226b97]
qubes-guid(+0x6faa) [0x558967931faa]
qubes-guid(+0x78ca) [0x5589679328ca]
qubes-guid(+0x79a6) [0x5589679329a6]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XError+0x11a) [0x7f1427f5d8ba]
/usr/lib/x86_64-linux-gnu/libX11.so.6(+0x3d7eb) [0x7f1427f5a7eb]
/usr/lib/x86_64-linux-gnu/libX11.so.6(+0x3d895) [0x7f1427f5a895]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XReply+0x240) [0x7f1427f5b7f0]
/usr/lib/x86_64-linux-gnu/libX11.so.6(XSync+0x4d) [0x7f1427f5718d]
qubes-guid(+0x9d42) [0x558967934d42]
qubes-guid(+0x9dd7) [0x558967934dd7]
/lib/x86_64-linux-gnu/libc.so.6(+0x43041) [0x7f1426248041]
/lib/x86_64-linux-gnu/libc.so.6(+0x4313a) [0x7f142624813a]
qubes-guid(+0xa21c) [0x55896793521c]
qubes-guid(+0x5282) [0x558967930282]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f1426226b97]
qubes-guid(+0x6faa) [0x558967931faa]
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/f0515766-d202-4caa-881c-ffadb898ecae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
