GNU bug report logs -
#57364
28.1.91; asynchronous X server error when creating a second frame on alternate DISPLAY
Previous Next
Reported by: Andrés Ramírez <rrandresf <at> hotmail.com>
Date: Tue, 23 Aug 2022 18:07:02 UTC
Severity: normal
Tags: moreinfo
Found in version 28.1.91
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #28 received at 57364 <at> debbugs.gnu.org (full text, mbox):
Hi. Po.
>>>>> "Po" == Po Lu <luangruo <at> yahoo.com> writes:
[...]
Po> Ah, that explains it. x-command-line-resources doesn't take effect if you run with "-Q",
Po> try "-q" instead.
As tested before. after s/Q/q the error does NOT show.
>> And also take in account, that the error is not reproducible in this condition.
Po> I think I've seen this somewhere. Does the error still happen if you build
Po> "--without-cairo"?
It does NOT happen If You use --without-cairo. Perhaps this could be a
workaround for my case. But I still think We should try to find the
offending line. WDYT?
>> I have had a question on my mind? Inspecting the last backtrace I have published on this bug
>> report.
>>
>> I see the error is recovered in a call on the function x_frame_highlight (within the call to
>> x_catch_error). Why If I am calling close-display-connection. Some functions need to be
>> called?
Po> Functions can be called on the display being closed while handling async input from that
Po> display, or when performing cleanup tasks. Unless, of course, the display is down, but that
Po> is rarely the case when you manually call close-display-connection/delete-terminal.
for cleanup tasks it's ok. But for x_frame_highlight. I am getting rid
of all the X-frames on this display. Is there a way of avoiding calling
that function in case of close-display-connections.
Best Regards
This bug report was last modified 2 years and 294 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.