RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1139568 - Windows guest show dark screen due to unknown reason occasionally
Summary: Windows guest show dark screen due to unknown reason occasionally
Keywords:
Status: CLOSED DUPLICATE of bug 1027244
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-server
Version: 6.4
Hardware: x86_64
OS: Windows
unspecified
high
Target Milestone: rc
: ---
Assignee: Default Assignee for SPICE Bugs
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-09 08:37 UTC by Blangero Wang
Modified: 2014-10-08 07:16 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-08 07:16:16 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
1st VM log (3.45 KB, text/plain)
2014-09-09 08:37 UTC, Blangero Wang 		no flags Details
1st VM gdb attach bt (1.12 KB, text/plain)
2014-09-09 08:38 UTC, Blangero Wang 		no flags Details
2nd VM log ( 2nd VM gdb attach bt is same with 1st VM gdb attach bt) (51.31 KB, text/plain)
2014-09-09 08:40 UTC, Blangero Wang 		no flags Details
View All

Description Blangero Wang 2014-09-09 08:37:25 UTC 
Created attachment 935580 [details]
1st VM log

Description of problem:

We have about 30 Windows7 VMs running on two RHEL 6.4 servers,
and the VMs occasionally show dark screen.
Most of the time it shows when re-connect VM after long disconnection(VMs never shutdown)
One time it shows when VM is connected using spice-protocol.

Only virsh destroy and restart resolves the problem.

No useful log in Guest OS.
No useful log in libvirtd log.

gdb attach the dark screen VM thread and bt, get the following:

#0  0x00007fc9b229354d in read () from b64bpthread.so.0
#1  0x00007fc9b0aad993 in read (fd=21, buf=0x7fff3bbbae4c "\311\177", size=4, block=<value optimized out>) at /usr/include/bits/unistd.h:45
#2  read_safe (fd=21, buf=0x7fff3bbbae4c "\311\177", size=4, block=<value optimized out>) at dispatcher.c:76
#3  0x00007fc9b0aadbc6 in dispatcher_send_message (dispatcher=0x7fc9b3b23a98, message_type=6, payload=0x7fff3bbbae80) at dispatcher.c:188
#4  0x00007fc9b0aae70d in red_dispatcher_disconnect_display_peer (rcc=0x7fc890338ae0) at red_dispatcher.c:144
#5  0x00007fc9b0aad305 in red_client_destroy (client=0x7fc9b411a5a0) at red_channel.c:1722
#6  0x00007fc9b0ad7e4b in reds_client_disconnect (client=0x7fc9b411a5a0) at reds.c:731
#7  0x00007fc9b0aa9351 in red_peer_handle_incoming (rcc=0x7fc9b53a4710) at red_channel.c:285
#8  red_channel_client_receive (rcc=0x7fc9b53a4710) at red_channel.c:294
#9  0x00007fc9b0aa9adc in red_channel_client_event (fd=<value optimized out>, event=<value optimized out>, data=0x7fc9b53a4710) at red_channel.c:1204
#10 0x00007fc9b293229f in ?? ()
#11 0x00007fc9b295497a in ?? ()
#12 0x00007fc9b2935008 in main (

Version-Release number of selected component (if applicable):

spice-server 0.12
RHEL 6.4


How reproducible:

No concrete procedure, but it do show in one or two days in 30 VMs.

Steps to Reproduce:
1.disconnect the VM
2.(after a period of time) re-connect the VM

Actual results:
Dark screen

Expected results:
connects successful and works

Additional info:
No return when ping the VM.
Comment 1 Blangero Wang 2014-09-09 08:38:34 UTC 
Created attachment 935582 [details]
1st VM gdb attach bt
Comment 2 Blangero Wang 2014-09-09 08:40:01 UTC 
Created attachment 935584 [details]
2nd VM log ( 2nd VM gdb attach bt is same with 1st VM gdb attach bt)
Comment 4 Ademar Reis 2014-09-15 16:32:12 UTC 
Blangero Wang, thanks for taking the time to enter a bug report with us. We use reports like yours to keep improving the quality of our products and releases. That said, we're not able to guarantee the timeliness or suitability of a resolution for issues entered here because this is not a mechanism for requesting support.

If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain it receives the proper attention and prioritization that will result in a timely resolution.

For information on how to contact the Red Hat production support team, please visit: https://www.redhat.com/support/process/production/#howto
Comment 5 Gerd Hoffmann 2014-09-16 07:32:22 UTC 
Hangs in spice-server, reassigning.

From the description and the stacktrace it pretty much looks like spice-server thinks there is a client still connected, on the new client connect it tries to send a disconnect request to the old client, waits for a response and hangs there.

spice-server should have some kind of timeout there I think so it doesn't block forever.

The other question is why it spice-server thinks there is still a client connected even though it is long gone (according to the initial description).
Is there a firewall between VM host and spice clients?  Any chance it
filters a bit too aggressive, so the VM host doesn't receive the TCP/ICMP
packets saying the connection is gone?
Comment 6 Christophe Fergeau 2014-09-16 08:45:59 UTC 
Might be https://rhn.redhat.com/errata/RHBA-2013-1819.html ?
Comment 7 Blangero Wang 2014-09-16 08:59:52 UTC 
Thanks very for your replies!

When a connection shows dark screen, I tried to ping the VM but failed to get a return, normal shutdown and reboot didn't work, so I think the VM is in a bad status.Will https://rhn.redhat.com/errata/RHBA-2013-1819.html cause the Guest to fail?

The firewall between VM host and spice clients is stable and never changed, but the problems occurs only very few times.

So If I want to test if it's bug https://rhn.redhat.com/errata/RHBA-2013-1819.html that caused the dark screen, what should I do?
I plan to unplug the net on a running spice-client and wait a few hours, will that do?

As mentioned in the bug report the spice-server is 0.12, kind of old, but I didn't find any bug fix about this kind of problem, nor can I update the spice-server to test if the problem remains in the near future.
Comment 8 Christophe Fergeau 2014-09-16 14:43:01 UTC 
(In reply to Blangero Wang from comment #7)
> Thanks very for your replies!
> 
> When a connection shows dark screen, I tried to ping the VM but failed to
> get a return, normal shutdown and reboot didn't work, so I think the VM is
> in a bad status.Will https://rhn.redhat.com/errata/RHBA-2013-1819.html cause
> the Guest to fail?

If what you experience is the issue described in this errata, this should prevent the situation which causes the unresponsive VMs to happen.


> So If I want to test if it's bug
> https://rhn.redhat.com/errata/RHBA-2013-1819.html that caused the dark
> screen, what should I do?
> I plan to unplug the net on a running spice-client and wait a few hours,
> will that do?

I'd say upgrade to latest RHEL, and see if the issue still occurs. I don't know how you usually hit this problem.
Comment 9 Blangero Wang 2014-09-17 08:24:24 UTC 
I produced unresponsive VM 3 times in 4 trials, but the backtrace I got were totally different from the ones I posted in the bugreport.
I got:
#0 0x00007f874804554d in read () from /lib64/libpthread.so.0
#1 0x00007f874685f993 in ?? () from /usr/lib64/libspice-server.so.1
#2 0x00007f874685fbc6 in ?? () from /usr/lib64/libspice-server.so.1
#3 0x00007f874686070d in ?? () from /usr/lib64/libspice-server.so.1
#4 0x00007f874685f305 in ?? () from /usr/lib64/libspice-server.so.1
#5 0x00007f8746889e4b in ?? () from /usr/lib64/libspice-server.so.1
#6 0x00007f874685b351 in ?? () from /usr/lib64/libspice-server.so.1
#7 0x00007f874685badc in ?? () from /usr/lib64/libspice-server.so.1
#8 0x00007f87486e429f in ?? ()
#9 0x00007f874870697a in ?? ()
#10 0x00007f87486e7008 in main ()

which I think was caused by the bug in https://rhn.redhat.com/errata/RHBA-2013-1819.html .

But what about the following bt(the one I posted) ? Was it also caused by the same bug?
#0  0x00007fc9b229354d in read () from b64bpthread.so.0
#1  0x00007fc9b0aad993 in read (fd=21, buf=0x7fff3bbbae4c "\311\177", size=4, block=<value optimized out>) at /usr/include/bits/unistd.h:45
#2  read_safe (fd=21, buf=0x7fff3bbbae4c "\311\177", size=4, block=<value optimized out>) at dispatcher.c:76
#3  0x00007fc9b0aadbc6 in dispatcher_send_message (dispatcher=0x7fc9b3b23a98, message_type=6, payload=0x7fff3bbbae80) at dispatcher.c:188
#4  0x00007fc9b0aae70d in red_dispatcher_disconnect_display_peer (rcc=0x7fc890338ae0) at red_dispatcher.c:144
#5  0x00007fc9b0aad305 in red_client_destroy (client=0x7fc9b411a5a0) at red_channel.c:1722
#6  0x00007fc9b0ad7e4b in reds_client_disconnect (client=0x7fc9b411a5a0) at reds.c:731
#7  0x00007fc9b0aa9351 in red_peer_handle_incoming (rcc=0x7fc9b53a4710) at red_channel.c:285
#8  red_channel_client_receive (rcc=0x7fc9b53a4710) at red_channel.c:294
#9  0x00007fc9b0aa9adc in red_channel_client_event (fd=<value optimized out>, event=<value optimized out>, data=0x7fc9b53a4710) at red_channel.c:1204
#10 0x00007fc9b293229f in ?? ()
#11 0x00007fc9b295497a in ?? ()
#12 0x00007fc9b2935008 in main (
Comment 10 Marc-Andre Lureau 2014-10-07 13:00:13 UTC 
(In reply to Blangero Wang from comment #9)
> I produced unresponsive VM 3 times in 4 trials, but the backtrace I got were
> totally different from the ones I posted in the bugreport.
> I got:
> #0 0x00007f874804554d in read () from /lib64/libpthread.so.0
> #1 0x00007f874685f993 in ?? () from /usr/lib64/libspice-server.so.1
> #2 0x00007f874685fbc6 in ?? () from /usr/lib64/libspice-server.so.1
> #3 0x00007f874686070d in ?? () from /usr/lib64/libspice-server.so.1
> #4 0x00007f874685f305 in ?? () from /usr/lib64/libspice-server.so.1
> #5 0x00007f8746889e4b in ?? () from /usr/lib64/libspice-server.so.1
> #6 0x00007f874685b351 in ?? () from /usr/lib64/libspice-server.so.1
> #7 0x00007f874685badc in ?? () from /usr/lib64/libspice-server.so.1
> #8 0x00007f87486e429f in ?? ()
> #9 0x00007f874870697a in ?? ()
> #10 0x00007f87486e7008 in main ()
> 
> which I think was caused by the bug in
> https://rhn.redhat.com/errata/RHBA-2013-1819.html .

Could you provide the spice-server version you tested against here? Can you verify you have the debug symbols installed for this version? thanks
Comment 11 Blangero Wang 2014-10-08 01:14:11 UTC 
(In reply to Marc-Andre Lureau from comment #10)
> (In reply to Blangero Wang from comment #9)
> > I produced unresponsive VM 3 times in 4 trials, but the backtrace I got were
> > totally different from the ones I posted in the bugreport.
> > I got:
> > #0 0x00007f874804554d in read () from /lib64/libpthread.so.0
> > #1 0x00007f874685f993 in ?? () from /usr/lib64/libspice-server.so.1
> > #2 0x00007f874685fbc6 in ?? () from /usr/lib64/libspice-server.so.1
> > #3 0x00007f874686070d in ?? () from /usr/lib64/libspice-server.so.1
> > #4 0x00007f874685f305 in ?? () from /usr/lib64/libspice-server.so.1
> > #5 0x00007f8746889e4b in ?? () from /usr/lib64/libspice-server.so.1
> > #6 0x00007f874685b351 in ?? () from /usr/lib64/libspice-server.so.1
> > #7 0x00007f874685badc in ?? () from /usr/lib64/libspice-server.so.1
> > #8 0x00007f87486e429f in ?? ()
> > #9 0x00007f874870697a in ?? ()
> > #10 0x00007f87486e7008 in main ()
> > 
> > which I think was caused by the bug in
> > https://rhn.redhat.com/errata/RHBA-2013-1819.html .
> 
> Could you provide the spice-server version you tested against here? Can you
> verify you have the debug symbols installed for this version? thanks

First, thanks for your reply!
The spice-server version is 0.12.0.

I reproduced the bug by dis-connect the network or set the client to sleep, and it seems to be this bug: https://rhn.redhat.com/errata/RHBA-2013-1819.html .
I think I can close this thread, could you please tell me the right procedure to close it?

Thanks again for all your help!
Comment 12 Christophe Fergeau 2014-10-08 07:16:16 UTC 
The errata contains the number of the bug which was fixed (1027244), you can use the 'mark as duplicate' link at the bottom of the page to close this bug as a duplicate of the one fixed by the errata.

*** This bug has been marked as a duplicate of bug 1027244 ***
Note You need to log in before you can comment on or make changes to this bug.