Red Hat Bugzilla – Full Text Bug Listing
|Summary:||xcb_io.c:221: poll_for_event: Assertion `(((long) (event_sequence) - (long) (dpy->request)) <= 0) failed|
|Product:||[Fedora] Fedora||Reporter:||Kamil Páral <kparal>|
|Component:||gtk2||Assignee:||Matthias Clasen <mclasen>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||awilliam, bcl, giovanni.tirloni, mclasen|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-02-13 20:57:38 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Kamil Páral 2011-05-06 09:54:18 EDT
Description of problem: On Date and Time dialog I selected network synchronization. When I pressed forward, there was "Starting NTP service" dialog. I hit Cancel and firstboot crashed (/var/log/messages reports firstboot has exited with return code 1). See attached screencast. Version-Release number of selected component (if applicable): firstboot-1.118-1.fc15.i686 How reproducible: always Steps to Reproduce: 1. Follow description, see video.
Comment 2 Brian Lane 2011-05-06 13:30:57 EDT
bug 475304 seems to be a dupe of this, which is then duped to bug 648050. I just did a F15 Beta install and updated the system and it is still happening.
Comment 3 Brian Lane 2011-05-06 13:37:47 EDT
*** This bug has been marked as a duplicate of bug 648050 ***
Comment 4 Kamil Páral 2011-11-01 09:48:23 EDT
I have reproduced this issue with Fedora 16 RC3. It is clearly not fixed. firstboot-16.4-1.fc16 There is no error message in /var/log/messages. But if I run firstboot command, I then see this error message: python: xcb_io.c:221: poll_for_event: Assertion `(((long) (event_sequence) - (long) (dpy->request)) <= 0) failed. It is 100% reproducible. The implications of this bug: 1. Users of 32bit Fedora will end up in GDM with no user account created. Users of 64bit Fedora will end up in GDM with their user account created. (That is due to bug 750527, on 64bit platform the user account is created before setting the time). 2. On next reboot firstboot tool is run again. Proposing as blocker bug: In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied. The firstboot utility must be able to create a working user account In some cases user ends up with no user account, which fails the criterion.
Comment 5 Kamil Páral 2011-11-01 10:53:57 EDT
According to Martin Gracik this is a bug in gtk2. Redirecting to gtk2. This bug is claimed to be fixed in bug 648050, but clearly it is not.
Comment 6 Adam Williamson 2011-11-01 11:39:48 EDT
This _only_ happens if you cancel the dialog? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 7 Kamil Páral 2011-11-01 12:20:44 EDT
(In reply to comment #6) > This _only_ happens if you cancel the dialog? Yes. Every other code path seems ok.
Comment 8 Adam Williamson 2011-11-01 15:56:34 EDT
Discussed at 2011-11-01 emergency blocker review meeting. We agreed not to accept this as a blocker: it is a bit of a bad bug, but at least if you reboot you get back to firstboot and you can try again, so it shouldn't permanently break anything. And it is on the error path, not the 'normal' path. We didn't accept it as NTH either as it seems really dangerous to touch either gtk2 or firstboot at this point, but if someone manages to come up with an extremely safe fix in the next hour or two, please re-propose. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 9 Giovanni Tirloni 2011-11-01 16:15:19 EDT
Just a data point: I did the installation and right before telling anaconda to sync using NTP, I disconnected the network cable so it'd have nowhere to go. Anaconda simply skipped to the next screen after close to a minute as nothing had happened. No crash. I repeated the process and clicked Cancel and could reproduce the issue faithfully (32-bit).
Comment 10 Fedora End Of Life 2013-02-13 20:57:50 EST
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.