On 11/26/2016 11:59 PM, Marek Marczykowski-Górecki wrote:
>> - Qubes-GUID crashed in one AppVM as soon as I started monodevelop
>> the first time. Cannot reproduce this problem either. Error in guid
>> log was:
>
>> ErrorHandler: BadAccess (attempt to access private resource
>> denied) Major opcode: 130 (MIT-SHM) Minor opcode: 1 (X_ShmAttach)
>> ResourceID: 0x2000054 Failed serial number: 3670 Current serial
>> number: 3671
>
>> may be related to the fact that monodevelop shows and hides many
>> windows in rapid sequence when starting?
>
> Yes, it may be. Very similar error (#2171) was already fixed some
> time ago, but apparently not all the cases. Anyway it's rather
> problem in gui-daemon, independent of Fedora version.
Ok, this problem happened again, and always when starting monodevelop.
Now I collected more logs, and tried to fiddle a bit with qubes-guid.
In dmesg there's nothing interesting apart from 238 repetitions of this
line just before the crash manifested with all windows from that VM
disappearing:
[ 77.469369] U2MFN_GET_MFN_FOR_PAGE: get_user_pages failed,
ret=0xfffffffffffffff2
Before this repetition of lines there is only the Fedora 25 (Workstation
Edition) login prompt.
The full content of guid log is short:
---------snip---------
Icon size: 128x128
invalid PMaxSize for 0x340001c (32767/32767)
invalid PMaxSize for 0x340001c (32767/32767)
invalid PMaxSize for 0x3400025 (32767/32767)
invalid PMaxSize for 0x3400025 (32767/32767)
invalid PMaxSize for 0x3400025 (32767/32767)
ErrorHandler: BadAccess (attempt to access private resource denied)
Major opcode: 130 (MIT-SHM)
Minor opcode: 1 (X_ShmAttach)
ResourceID: 0x340003b
Failed serial number: 1294
Current serial number: 1295
---------snip---------
And that's all of it. This run was from a freshly started VM, where only
Firefox and Thunderbird were started before monodevelop. I'm starting to
get convinced that windows that appear and suddently disappear after a
very short amount of time can be a problem for gui-daemon.
After the crash I tried to open a shell to restart the daemon (later I
tried to just restart the daemon from dom0) but without luck:
dom0$ qvm-run --pass-io work /bin/bash
[here the windows from the work appVM briefly returned on screen, a
terminal appeared too, then everything from that vm disappeared again in
a couple of seconds. No output in dom0 terminal, so I killed this
qvm-run instance]
dom0$ qvm-run --pass-io work /usr/bin/qubes-gui
Running command on VM: 'work'...
--> Starting Qubes GUId...
Connecting to VM's GUI agent: .exiting
ERROR(work): Cannot start qubes-guid!
dom0$ qvm-run --pass-io work "/usr/bin/systemctl restart qubes-gui-agent"
Running command on VM: 'work'...
--> Starting Qubes GUId...
Connecting to VM's GUI agent: .exiting
ERROR(work): Cannot start qubes-guid!
And that's when I gave up... The way out is to restart the VM. I guess I
should study the Qubes project deeper as a developer to help both me and
the project more :/ If only I had the time...
--
Alex
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/ac00e59f-3338-91bc-546f-4feb6fde8a81%40gmx.com.
For more options, visit https://groups.google.com/d/optout.
