Closed l29ah closed 1 year ago
I can't reproduce this locally in my test harness, using either 0.17.0 or 0.17.2.
I can't reproduce with an empty qutebrowser basedir as well. I guess it puts something nasty (or just big) in the window title when it's ran with my stored tabs.
That's still a bug, since the Shrinker
associated with the tabbed layout (defaultShrinker
in your case) should deal with oversized tab text.
OOC do you know what page is open on the active tab when it starts? Maybe I can reproduce that way, and hopefully track down what it's evaluating when it loops.
On Tue, Apr 18, 2023 at 02:29:56PM -0700, brandon s allbery kf8nh wrote:
OOC do you know what page is open on the active tab when it starts? Maybe I can reproduce that way, and hopefully track down what it's evaluating when it loops.
Not sure if this is it, but i just crashed xmonad by opening the URL that is stored at the following link (and that was yanked from another qutebrowser): https://0x0.st/H8wS.txt
-- () ascii ribbon campaign - against html mail /\ http://arc.pasp.de/ - against proprietary attachments
When I open that URL I get a screen full of gibberish starting with
data:text/html;charset=UTF-8
but neither xmonad nor qutebrowser crashes. The xmonad tab contents are normal ("https://0x0.st/H8wS.txt - qutebrowser
").
Again, i ask you not to open the URL, but the URL that is stored at that URL.
There's no URL there that I see…
This is the URL. At least it is treated as such by qutebrowser.
Uh. That's going to be a royal pain to get into my sandbox…
curl | xclip -i PP in qutebrowser
xmonad: X11 error: BadLength (poly request too large or internal Xlib length error), request code=139, error code=16
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
xmonad-x86_64-linux: ../../src/xcb_io.c:260: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
139 isn't a valid X11 request, so this is probably Xlib.
I am going to guess that qutebrowser shoveled that whole data
URL into WM_NAME
and Xlib choked on it trying to retrieve it (xcb probably handles this better). The "sequence number" part is probably whatever part of WM_NAME
it didn't read out of the socket.
We're both a bit confused as to what's going on with that data
URL; it appears to be a report that the renderer crashed trying to load an innocuous looking URL at https://blueprint.bryanjohnson.co.uk
, except that what it actually shows is a data:
URL that may or not be the same as the one that is crashing xmonad as above. If the Try again
link is clicked, it reports the renderer crashed opening the blueprint
URL.
I have my test harness running xmonad under gdb so I can try to get more information. Unfortunately, gdb is itself stuck at Loading symbols
so I won't be able to do anything until tomorrow morning (assuming it gets unstuck overnight). And then I may have to arrange for everything to get built with -g
which will require a build
script.
It's reproducing on startup for me now. After binding XSynchronize
(a trip in itself) I determined that it's crashing while trying to render the tab:
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007fa9d03de859 in __GI_abort () at abort.c:79
#2 0x00007fa9d03de729 in __assert_fail_base (fmt=0x7fa9d0574588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=0x7fa9d075d858 "!xcb_xlib_threads_sequence_lost", file=0x7fa9d075d6c3 "../../src/xcb_io.c", line=260,
function=<optimized out>) at assert.c:92
#3 0x00007fa9d03effd6 in __GI___assert_fail (assertion=0x7fa9d075d858 "!xcb_xlib_threads_sequence_lost",
file=0x7fa9d075d6c3 "../../src/xcb_io.c", line=260, function=0x7fa9d075db10 "poll_for_event") at assert.c:101
#4 0x00007fa9d06e9643 in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007fa9d06e96ed in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007fa9d06e99ea in _XEventsQueued () from /lib/x86_64-linux-gnu/libX11.so.6
#7 0x00007fa9cff603e7 in XRenderCompositeString8 () from /lib/x86_64-linux-gnu/libXrender.so.1
#8 0x00007fa9d0817cb5 in XftGlyphRender () from /lib/x86_64-linux-gnu/libXft.so.2
#9 0x00007fa9d0810ff9 in XftDrawGlyphs () from /lib/x86_64-linux-gnu/libXft.so.2
#10 0x00007fa9d08115fb in XftDrawStringUtf8 () from /lib/x86_64-linux-gnu/libXft.so.2
#11 0x000000000048cddc in ?? ()
#12 0x00000000000575b1 in ?? ()
#13 0x0000000000000000 in ?? ()
Which means that, among other things, the Shrinker
isn't. I hate those things….
The Shrinker
turns out to be
textWidthXMF
which doesn't appear to handle multi-line stringsinit
, which makes it quadratic (https://github.com/xmonad/xmonad-contrib/blob/master/XMonad/Layout/Decoration.hs#L415-L417)I propose to chop first to one line, then to 1K or 2K in deference to 4K displays.
Apparently it's still a couple seconds for @l29ah even though it's pretty clippy here. May leave this open since I'm not sure quadratic behavior on 2K chars should be that bad, and it's not reproducing here. (Well, it "is", but it's qutebrowser taking the second or so and xmonad has no control over its rendering.)
Problem Description
xmonad hangs for good when qutebrowser is being launched in a Tabbed layout. The tab decoration gets garbled. xmonad works fine if qutebrowser is launced in a non-Tabbed layout and then brought to a Tabbed one.
Configuration File
Checklist
[x] I've read CONTRIBUTING.md
I tested my configuration
xmonad
version 0.17.1xmonad-contrib
version 0.17.1