On Tuesday, September 25, 2018 at 2:12:29 PM UTC-5, tyler.e....@raytheon.com wrote: > 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]
Reposted to qubes-devel mailing list: https://groups.google.com/forum/#!topic/qubes-devel/AMaga3H2Xa8 -- 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/0dd6bee0-3f95-42cd-b197-c3baf92eb05a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
