Browser will crash after 3603 or 3604 seconds

[duckunix]

Version info:

qutebrowser v1.13.1
Git commit: d3f76a0eb on master (2020-08-07 16:44:42 +0200)
Backend: QtWebEngine (Chromium 80.0.3987.163)
Qt: 5.15.0

CPython: 3.8.2
PyQt: 5.15.0

sip: 5.3.0
colorama: 0.4.3
pypeg2: 2.15
jinja2: 2.11.2
pygments: 2.6.1
yaml: 5.3.1
cssutils: 1.0.2 $Id$
attr: 19.3.0
PyQt5.QtWebEngineWidgets: yes
PyQt5.QtWebEngine: 5.15.0
PyQt5.QtWebKitWidgets: no
pdf.js: 2.4.456 (/home/don/.local/share/qutebrowser/pdfjs/build/pdf.js)
sqlite: 3.31.1
QtNetwork SSL: OpenSSL 1.1.1f  31 Mar 2020

Style: QFusionStyle
Platform plugin: xcb
OpenGL: Intel Open Source Technology Center, 3.0 Mesa 20.0.8
Platform: Linux-5.4.0-42-generic-x86_64-with-glibc2.29, 64bit
Linux distribution: Ubuntu 20.04.1 LTS (ubuntu)
Frozen: False
Imported from /home/don/src/qutebrowser.new/qutebrowser
Using Python from /home/don/qutebrowser.env/bin/python
Qt library executable path: /home/don/qutebrowser.env/lib/python3.8/site-packages/PyQt5/Qt/libexec, data path: /home/don/qutebrowser.env/lib/python3.8/site-packages/PyQt5/Qt

Paths:
cache: /home/don/.cache/qutebrowser
config: /home/don/.config/qutebrowser
data: /home/don/.local/share/qutebrowser
runtime: /run/user/1000/qutebrowser

Autoconfig loaded: yes
Config.py: /home/don/.config/qutebrowser/config.py has been loaded
Uptime: 0:05:54

Does the bug happen if you start with --temp-basedir?:
Have not tested.

Description
Browser will exit after 3603 or 3604 seconds repeatably. This can be if the browser is idle, or if the browser is in active use.

How to reproduce

1. Build browser from git source using scripts/mkvenv.sh
2. Activate virtual env with . ${VENV-PATH}/bin/activate
3. run browser with qutebrowser
4. wait 3603 to 3604 seconds for the browser to abend with a segmentation fault

[The-Compiler]

Would be good to know if you can reproduce this with --temp-basedir. I've seen similar crash reports, but I've never seen that happen myself and I'm pretty sure I often have qutebrowser running for >1h.

[duckunix]

I just fired it up, and will update in an hour or two.

[duckunix]

Well, it did not fail, and is still running. So, that points it to something in my config? Thoughts on how to debug that?

Thanks!

[duckunix]

Okay, so I did some reading from https://www.qutebrowser.org/doc/stacktrace.html
And I have a bt for you:

#0  0x00007fffeb190ab7 in  () at /home/don/qutebrowser.env/lib/python3.8/site-packages/PyQt5/Qt/lib/libQt5WebEngineCore.so.5
#1  0x00007fff9effc8b0 in  ()
#2  0x00007fff91400210 in  ()
#3  0x00007fff9effc850 in  ()
#4  0x00007fffeb1826ff in  () at /home/don/qutebrowser.env/lib/python3.8/site-packages/PyQt5/Qt/lib/libQt5WebEngineCore.so.5
#5  0x00007fffeb186340 in  () at /home/don/qutebrowser.env/lib/python3.8/site-packages/PyQt5/Qt/lib/libQt5WebEngineCore.so.5
#6  0x00007fff9effc810 in  ()
#7  0x0000000000000000 in  ()

[toofar]

That's not a very informative stack trace. You can go to qute://configdiff/ to see differences from the default config. Your config.py would be the other point of interest since it doesn't happen with a temp basdir. Either share them here or read through them and manually bisect if nothing jumps out at you.

[duckunix]

@toofar thanks for the pointers. I agree the trace was pretty light on details. :(

I have looked at qute://configdiff and the major differences I can see were over color theme, which I have commented out, and I think the rest are pretty normal:

aliases = {"q": "close", "qa": "quit", "w": "session-save", "wq": "quit --save", "wqa": "quit --save"}
auto_save.session = true
backend = webengine
bindings.commands = {"normal": {",M": "hint links spawn umpv {hint-url}", ",P": "spawn --userscript qute-pass --username-pattern=r\".*/(.+)\" --dmenu-invocation dmenu --password-only", ",V": "hint links spawn umpv {hint-url}", ",b": "spawn rofi-buku", ",d": "spawn --userscript open_download", ",j": "spawn --userscript joplin-import", ",m": "spawn --userscript mymail", ",n": "config-cycle content.user_stylesheets /home/don/src/solarized-everything-css/css/mine.css \"\"", ",p": "spawn --userscript qute-pass --username-pattern=r\".*/(.+)\" --dmenu-invocation dmenu", ",v": "spawn umpv {url}", ",w": "set-cmd-text -s :spawn --userscript taskadd", ";M": "hint --rapid links spawn umpv {hint-url}", ";V": "hint --rapid links spawn umpv {hint-url}", "xb": "config-cycle statusbar.hide", "xt": "config-cycle tabs.show always switching", "xx": "config-cycle statusbar.hide ;; config-cycle tabs.show always switching"}}
bindings.key_mappings = {"<Ctrl+6>": "<Ctrl+^>", "<Ctrl+Enter>": "<Ctrl+Return>", "<Ctrl+[>": "<Escape>", "<Ctrl+j>": "<Return>", "<Ctrl+m>": "<Return>", "<Enter>": "<Return>", "<Shift+Enter>": "<Return>", "<Shift+Return>": "<Return>"}
completion.cmd_history_max_items = 100
content.autoplay = false
https://www.academy.com: content.geolocation = false
https://www.lowes.com: content.geolocation = false
content.host_blocking.whitelist = 
content.hyperlink_auditing = false
file://*: content.javascript.enabled = false
https://voice.google.com: content.media.audio_capture = true
https://voice.google.com: content.media.audio_video_capture = true
https://voice.google.com: content.media.video_capture = true
https://messages.google.com: content.notifications = true
https://voice.google.com: content.notifications = true
https://www.reddit.com: content.notifications = false
https://www.techowns.com: content.notifications = false
https://www.youtube.com: content.notifications = false
https://calendar.google.com?cid=%25s: content.register_protocol_handler = true
https://mail.google.com?extsrc=mailto&url=%25s: content.register_protocol_handler = false
hints.border = 1px solid #282a36
new_instance_open_target = tab
qt.args = ["blink-settings=darkMode=4"]
spellcheck.languages = ["en-US"]
statusbar.padding = {"bottom": 6, "left": 8, "right": 8, "top": 6}
statusbar.show = never
tabs.favicons.scale = 1
tabs.indicator.width = 1
tabs.last_close = close
tabs.padding = {"bottom": 1, "left": 8, "right": 8, "top": 1}
tabs.position = bottom
tabs.show = always
tabs.title.format = {audio}{current_title}

I am not sure if the qt.args = ["blink-settings=darkMode=4"] is an issue. I should probably take that out as I have never got it to work (darkmode web pages)

[duckunix]

Okay, I have turned off almost everything, to the point that :open qute://configdiff shows me:

aliases = {"q": "close", "qa": "quit", "w": "session-save", "wq": "quit --save", "wqa": "quit --save"}
auto_save.session = true
bindings.commands = {"normal": {",M": "hint links spawn umpv {hint-url}", ",P": "spawn --userscript qute-pass --username-pattern=r\".*/(.+)\" --dmenu-invocation dmenu --password-only", ",V": "hint links spawn umpv {hint-url}", ",b": "spawn rofi-buku", ",d": "spawn --userscript open_download", ",j": "spawn --userscript joplin-import", ",m": "spawn --userscript mymail", ",n": "config-cycle content.user_stylesheets /home/don/src/solarized-everything-css/css/mine.css \"\"", ",p": "spawn --userscript qute-pass --username-pattern=r\".*/(.+)\" --dmenu-invocation dmenu", ",v": "spawn umpv {url}", ",w": "set-cmd-text -s :spawn --userscript taskadd", ";M": "hint --rapid links spawn umpv {hint-url}", ";V": "hint --rapid links spawn umpv {hint-url}", "xb": "config-cycle statusbar.show", "xt": "config-cycle tabs.show always switching", "xx": "config-cycle statusbar.show ;; config-cycle tabs.show always switching"}}
completion.cmd_history_max_items = 10
content.autoplay = false
https://www.academy.com: content.geolocation = false
https://www.lowes.com: content.geolocation = false
content.host_blocking.whitelist = 
content.hyperlink_auditing = false
https://voice.google.com: content.media.audio_capture = true
https://voice.google.com: content.media.audio_video_capture = true
https://voice.google.com: content.media.video_capture = true
https://messages.google.com: content.notifications = true
https://voice.google.com: content.notifications = true
https://www.reddit.com: content.notifications = false
https://www.techowns.com: content.notifications = false
https://www.youtube.com: content.notifications = false
https://calendar.google.com?cid=%25s: content.register_protocol_handler = true
https://mail.google.com?extsrc=mailto&url=%25s: content.register_protocol_handler = false
new_instance_open_target = tab
spellcheck.languages = ["en-US"]
statusbar.show = never
tabs.last_close = close
tabs.show = always

And now, I can get all the way up to 3605 seconds!

Whilst I do like the reminder to get up and move every hour, it does get a little frustrating to have the reminder be the browser crashing like clockwork.

Any more thoughts on what to go look for?

[toofar]

The only other thing I can thing of is the crashes around service workers: #5279
As I can't think of anything with an hour interval in qutebrowser presumably it is something external. Perhaps if some site is trying to re-register a worker hourly it is what is doing it.

If you could try moving ~/.local/share/qutebrowser/webengine/ out of the way while qutebrowser is crashed shut down maybe that'll fix it?

Also if you aren't running in a terminal with --debug then you could see if there is anything interesting on stdout when it crashes, although with segfaults there often isn't.

[schodet]

I left my computer off for one week, now I have the same problem, on 1.13.0 and 1.13.1.

I deleted .cache/qutebrowser and .local/share/qutebrowser/webengine to see if it solve the problem.

It is running now for more than one hour.

[duckunix]

@toofar I will try that this morning. So, when I looked in ~/.local/share/qutebrowser/webengine/, the last files updated which were updated when the browser shutdown was Cookies and Cookies-journal. The latter was empty. Not sure if this helps.
I will try it the --debug flag as well. If that fails, I will try @schodet 's suggestion of removing the cache dir.

[The-Compiler]

Please don't remove anything, just move it away - removing means it's impossible to investigate what was going on, or to test possible workarounds.

[duckunix]

@The-Compiler sorry to mis-type. I did back up the webengine directory, and will do the same for the cache dir if I need to.

[duckunix]

Okay. Just cleared two hours running with --debug and a new webengine dir. I am going to try it again without the --debug flag so see if there is any difference.

[duckunix]

And an update: after 2.5 hours, it stable and still running.

Next question: would the old webengine dir be useful for debugging? If so, is there a good reference on what I would find in there so I can prep it to be shared?

[The-Compiler]

This is most likely a QtWebEngine issue and not a bug in qutebrowser - but the directory would definitely be useful to report a bug upstream. Not sure what's in there exactly, the data is coming from the underlying Chromium...

It'd be good to find out what exactly in there is causing the crash, but that's kind of tedious... I wonder if you can trigger it by moving your system clock forward by an hour?

[duckunix]

So, I think I figured out what is causing the bug. After things has settled down, I started adding things back into my config. After I added Dracula color theme for qutebrowser (https://github.com/dracula/qutebrowser), guess what? It happened again.

I pulled it back out of my config, and if it does not fail in 20 minutes or so, I will open a ticket in the theme's repo, and see if I can figure out how to work with them to a) get a fix in the theme and b) isolate a reproducer to submit upstream to the QtWebEngine folks.

I want to thank you all for your help in narrowing down the issue. I will keep this open until I get bugs opened in the other trackers so I can make sure everyone who wants to know about this can find the issue no matter of the entry vector.

[duckunix]

New try with new empty webengine dir and no dracula theme. sigh

[duckunix]

Yup. Confirmed. Something in that color theme makes a config change which freaks out the QtWebEngine.

[The-Compiler]

That's crazy. I have no idea what that could be. That wouldn't be consistent with what @schodet has mentioned though? Are you sure it's really the theme, and not something in ~/.cache/qutebrowser or ~/.local/share/qutebrowser then?

I'll give it a try later this week and see if I can reproduce it with that.

[duckunix]

I know, it seems odd. I did not clean my cache during this whole process. I suppose the next step would be move the cache dir out of the way, re-enable the theme, and see how long it goes. I will try to set that up this evening. I have to go get dinner running, so I will be off keyboard for a few hours.

[The-Compiler]

Over in dracula/qutebrowser#8 you said:

Remove ~/.local/share/qutebrowser/webengine, disable the inclusion of the dracula theme, fire the browser up, let it run for hours.

What I don't understand there: What makes you think it's the theme triggering this, and not the removal of ~/.local/share/qutebrowser/webengine? It's much more likely to be that fixing the issue than the theme being the culprit.

FWIW I tried to reproduce by doing:

• qutebrowser --basedir /tmp/dracula and quit (to get the initial directory structure)
• cd /tmp/dracula/config
• git clone https://github.com/dracula/qutebrowser-dracula-theme.git dracula
• Create a config.py as per the instructions:

import dracula.draw

# Load existing settings made via :set
config.load_autoconfig()

dracula.draw.blood(c, {
    'spacing': {
        'vertical': 6,
        'horizontal': 8
    }
})

• Launch qutebrowser --basedir /tmp/dracula

I left it run overnight for 8h, without any issues.

[schodet]

Tests I have done on my side:

• restore .local/share/qutebrowser/webengine from backup to /tmp/1hcrash,
• run qutebrowser --basedir /tmp/1hcrash,
• no crash.

After the message about dracula theme, I made another test:

• link .config/qutebrowser to /tmp/1hcrash/config,
• run qutebrowser --basedir /tmp/1hcrash again,
• still no crash.

I am sorry I removed my cache dir, I realized it was a mistake when it was gone.

[The-Compiler]

So if I'm getting this right:

• For @duckunix it definitely wasn't the cache (I did not clean my cache during this whole process.) but might've been ~/.local/share/qutebrowser or the Dracula theme
• For @schodet it wasn't config/data, but it was the cache dir.

That doesn't make me any less confused... 😕

[duckunix]

@The-Compiler Why I think it is the theme is that when I added it back, I get the crash. Then I remove it from my config, and it still crashes until I reset the webengine dir.
I do fully believe it could be there is something else wrong with my system that the theme is tickling. I sadly have a full day of almost 11 hours of meetings/work today, so I will not be able to look into it more for a bit.

[The-Compiler]

Why I think it is the theme is that when I added it back, I get the crash. Then I remove it from my config, and it still crashes until I reset the webengine dir.

Ah, that clarifies things. Did you actually browse around while reproducing this with the theme enabled? I wonder if it's some site you regularly visit which is somehow storing some data which triggers the crash.

I sadly have a full day of almost 11 hours of meetings/work today, so I will not be able to look into it more for a bit.

No worries!

[duckunix]

Major sites I visit: Reddit, YouTube, Gmail, handful of internally hosted apps, duck-duck-go, plus the random blogs.

[smaslennikov]

About a week ago I ran into this and was more concerned with attending work meetings than anything else - didn't realize the importance of data and removed both .cache/qutebrowser/ and .local/share/qutebrowser/webengine/* while qutebrowser was still running. Didn't restart it, worked out fine for a while.

Fast forward to today: laptop hard-reset for other reasons, qutebrowser crashes again. Directories removed again, qutebrowser still crashes. I can get some more information tomorrow morning.

[CD3]

I'm seeing the exact same issue. I didn't realize it was happening at the same time, and then I read this issue and started running qutebrowser from the terminal with the time command.

lagrange(:|✔) % time qutebrowser                                                                                                                                                                               
12:47:30 INFO: Run :adblock-update to get adblock lists.
12:48:30 INFO: Search hit BOTTOM, continuing at TOP
/home/cclark/bin/qutebrowser: line 2: 1079334 Segmentation fault      (core dumped) ${HOME}/Software/qutebrowser/.venv/bin/python -m qutebrowser
user: 440.74s system: 39.84s elapsed: 3606.95s
lagrange(:|✔) % time qutebrowser                                                                                                                                                                               
15:18:53 INFO: Run :adblock-update to get adblock lists.
/home/cclark/bin/qutebrowser: line 2: 1243975 Segmentation fault      (core dumped) ${HOME}/Software/qutebrowser/.venv/bin/python -m qutebrowser
user: 512.74s system: 68.55s elapsed: 3605.92s
lagrange(:|✔) %    

I'm also running the 1.13.1 venv version

qutebrowser v1.13.1
Git commit: 1b1a833a0 on master (2020-08-17 09:50:41 +0200)
Backend: QtWebEngine (Chromium 80.0.3987.163)
Qt: 5.15.0

CPython: 3.8.2
PyQt: 5.15.0

sip: 5.3.0
colorama: 0.4.3
pypeg2: 2.15
jinja2: 2.11.2
pygments: 2.6.1
yaml: 5.3.1
cssutils: 1.0.2 $Id$
attr: 19.3.0
PyQt5.QtWebEngineWidgets: yes
PyQt5.QtWebEngine: 5.15.0
PyQt5.QtWebKitWidgets: no
pdf.js: 1.5.188 (/usr/share/javascript/pdf/build/pdf.js)
sqlite: 3.31.1
QtNetwork SSL: OpenSSL 1.1.1f  31 Mar 2020

Style: QFusionStyle
Platform plugin: xcb
OpenGL: NVIDIA Corporation, 4.6.0 NVIDIA 440.100
Platform: Linux-5.4.0-42-generic-x86_64-with-glibc2.29, 64bit
Linux distribution: Ubuntu 20.04.1 LTS (ubuntu)
Frozen: False
Imported from /home/cclark/Software/qutebrowser/qutebrowser
Using Python from /home/cclark/Software/qutebrowser/.venv/bin/python
Qt library executable path: /home/cclark/Software/qutebrowser/.venv/lib/python3.8/site-packages/PyQt5/Qt/libexec, data path: /home/cclark/Software/qutebrowser/.venv/lib/python3.8/site-packages/PyQt5/Qt

Paths:
cache: /home/cclark/.cache/qutebrowser
config: /home/cclark/.config/qutebrowser
data: /home/cclark/.local/share/qutebrowser
runtime: /run/user/1000/qutebrowser

Autoconfig loaded: no
Config.py: /home/cclark/.config/qutebrowser/config.py has been loaded
Uptime: 0:00:13

[The-Compiler]

@CD3 Whatever you do, please do not delete the cache/config/data directories:

cache: /home/cclark/.cache/qutebrowser
config: /home/cclark/.config/qutebrowser
data: /home/cclark/.local/share/qutebrowser

Can you please try whether you can also force the crash to appear by adjusting your clock forward by one hour?

Also, can you please try moving those directories away one by one (with qutebrowser quit) and see which one triggers it?

[CD3]

OK, I have not deleted any of the directories.

Adjusting the clock forward did not affect anything, other than the runtime reported by the time command.

lagrange(:|✔) % time qutebrowser
07:20:08 INFO: Run :adblock-update to get adblock lists.
...
/home/cclark/bin/qutebrowser: line 2: 2306600 Segmentation fault      (core dumped) ${HOME}/Software/qutebrowser/.venv/bin/python -m qutebrowser
user: 929.56s system: 111.71s elapsed: 6716.84s

I'll start moving directories one by one.

[toshism]

I've also been having this issue and I also use the dracula theme. I moved .local/share/qutebrowser/webengine yesterday and I have not had a crash since. I made no other changes.

qutebrowser v1.13.1
Git commit: 786198fde-dirty on master (2020-08-13 14:30:37 +0200)
Backend: QtWebEngine (Chromium 80.0.3987.163)
Qt: 5.15.0

CPython: 3.7.4
PyQt: 5.15.0

sip: 5.3.0
colorama: 0.4.3
pypeg2: 2.15
jinja2: 2.11.2
pygments: 2.6.1
yaml: 5.3.1
cssutils: 1.0.2 $Id$
attr: 19.3.0
PyQt5.QtWebEngineWidgets: yes
PyQt5.QtWebEngine: 5.15.0
PyQt5.QtWebKitWidgets: no
pdf.js: no
sqlite: 3.31.1
QtNetwork SSL: OpenSSL 1.1.1  11 Sep 2018

Style: QFusionStyle
Platform plugin: xcb
OpenGL: Intel Open Source Technology Center, 3.0 Mesa 20.0.8
Platform: Linux-5.4.0-42-generic-x86_64-with-debian-buster-sid, 64bit
Linux distribution: Ubuntu 18.04.5 LTS (ubuntu)
Frozen: False
Imported from /home/tosh.lyons/dev/projects/qutebrowser/qutebrowser
Using Python from /home/tosh.lyons/dev/projects/qutebrowser/.venv/bin/python3
Qt library executable path: /home/tosh.lyons/dev/projects/qutebrowser/.venv/lib/python3.7/site-packages/PyQt5/Qt/libexec, data path: /home/tosh.lyons/dev/projects/qutebrowser/.venv/lib/python3.7/site-packages/PyQt5/Qt

Paths:
cache: /home/tosh.lyons/.cache/qutebrowser
config: /home/tosh.lyons/.config/qutebrowser
data: /home/tosh.lyons/.local/share/qutebrowser
runtime: /run/user/1001/qutebrowser

Autoconfig loaded: yes
Config.py: /home/tosh.lyons/.config/qutebrowser/config.py has been loaded
Uptime: 2:04:18

I still have the old webengine folder if there is anything I can do to help debug this issue?

[The-Compiler]

@toshism It'd be great to find out what in there is causing the crash. If you want to continue using your instance, you should be able to do:

• qutebrowser --basedir /tmp/qb-5656-1 :quit
• Remove /tmp/qb-5656-1/data/webengine/
• Copy your backed up webengine/ to /tmp/qb-5656-1/data/
• Run with qutebrowser --basedir /tmp/qb-5656-1 :quit and wait 1h, the crash should still happen
• Start deleting subfolders from /tmp/qb-5656-1/data/webengine/ (with that instance closed) until it doesn't happen anymore

Unfortunately that's kind of tedious, but it'd give us a first idea of where the issue is. Like @toofar mentioned above, my first guess would be the "Service Worker" subdirectory.

[CD3]

So far I have moved ~/.cache/qutebrowser and ~/.config/qutebrowser, each separately, and was able to run longer than an hour. I'll try the data directory next and then make sure I still get a crash when all directories are back to their normal state.

[toshism]

I copied my old webengine folder to the new basedir and left it running overnight, and it's still running 8 hours later. No crashes. Interesting.... I also had an instance with the "new" webengine folder running. I am not sure if that could have any effect.

So in summary:
New .local/share/qutebrowser/webengine same everything else. No crashes
Old /tmp/qb-5656-1/data/webengine and new basedir as suggested. No crashes

So it seems it's either some combination of webengine and something else in the basedir, or running both versions had some effect. Tonight I'll try again with only the new basedir and old webengine running.

[CD3]

@The-Compiler Well, this is strange. I moved each of the directories one at a time as you suggested and have not had a crash since. I even moved all of the original directories back and left it running overnight with no crash. So it seems to be "fixed" for now, but I will report back if I can reproduce the crash.

[The-Compiler]

Until someone has a somewhat reliable idea on how to reproduce this, I'm pretty much out of ideas...

Can anyone who can still reproduce this (@CD3 @toshism @smaslennikov) get a stacktrace? You won't be able to get any debug symbols for the binary since you all seem to have qutebrowser installed via virtualenv, but at least it'd be good to confirm you're seeing the same crash as @duckunix in #5656 (comment).

[toshism]

I have not been able to reproduce it since i moved the webengine folder. I'll keep experimenting though to see if i can trigger it again.

stack trace from when i could trigger it.

#0  raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  <signal handler called>
#2  0x00007f5baa0f1ab7 in ?? ()
   from /home/tosh.lyons/dev/projects/qutebrowser/.venv/lib/python3.7/site-packages/PyQt5/Qt/lib/libQt5WebEngineCore.so.5
#3  0x00007f5b4bffe8b0 in ?? ()
#4  0x00007f5b40816610 in ?? ()
#5  0x00007f5b4bffe850 in ?? ()
#6  0x00007f5baa0e36ff in ?? ()
   from /home/tosh.lyons/dev/projects/qutebrowser/.venv/lib/python3.7/site-packages/PyQt5/Qt/lib/libQt5WebEngineCore.so.5
#7  0x00007f5baa0e7340 in ?? ()
   from /home/tosh.lyons/dev/projects/qutebrowser/.venv/lib/python3.7/site-packages/PyQt5/Qt/lib/libQt5WebEngineCore.so.5
#8  0x00007f5b4bffe810 in ?? ()
#9  0x0000000000000000 in ?? ()

[glostis]

Hi,

I've been affected by this problem too for the past 2 weeks.
I currently have a qutebrowser that consistently reproduces the error, i.e. that crashes every time after being up for 1 hour.
I have not yet tried to set aside my cache or webengine directories, since I could be of help to debug the issue.

I have run qutebrowser with gdb to catch the stack trace but I do not get meaningful information, probably due to the fact that I did not compile Qt myself:

#0  0x00007fffe5445ab7 in ?? ()
   from /home/glostis/libs/qutebrowser/.venv/lib/python3.6/site-packages/PyQt5/Qt/lib/libQt5WebEngineCore.so.5
No symbol table info available.
#1  0x00007fffb49d68b0 in ?? ()
No symbol table info available.
#2  0x00007fff88531120 in ?? ()
No symbol table info available.
#3  0x00007fffb49d6850 in ?? ()
No symbol table info available.
#4  0x00007fffe54376ff in ?? ()
   from /home/glostis/libs/qutebrowser/.venv/lib/python3.6/site-packages/PyQt5/Qt/lib/libQt5WebEngineCore.so.5
No symbol table info available.
#5  0x00007fffe543b340 in ?? ()
   from /home/glostis/libs/qutebrowser/.venv/lib/python3.6/site-packages/PyQt5/Qt/lib/libQt5WebEngineCore.so.5
No symbol table info available.
#6  0x00007fffb49d6810 in ?? ()
No symbol table info available.
#7  0x0000000000000000 in ?? ()
No symbol table info available.

I have also run qutebrowser --debug twice this morning, and have noticed that both times there was a

ipc:update_atime:413 Touching /run/user/1000/qutebrowser/ipc-...

message within the last second of debug output before the crash. This was the only point in common between the outputs of my two crashes from this morning.
Is that of any interest?

[toshism]

I don't have any real details, but I just wanted to add that this actually starts to reoccur some time after removing the webengine folder. I remove the webengine folder and everything is fine for a few days/weeks and then the same issue will start to reoccur. I've removed the webengine folder probably 5 times now and it eventually comes back.

Not sure if that is helpful or not, but maybe.

[glostis]

I still encounter this problem where after a while, qutebrowser will persistently crash exactly after being up for 1 hour. The only way I can solve it is by removing my ~/.local/share/qutebrowser/webengine directory. This stops the browser from crashing for a few days, until the problem re-appears.

After doing this a few times, I figured I would try to find more specifically what needs to be deleted inside webengine in order to "solve" the problem. I've found that deleting just the webengine/Service Worker/CacheStorage directory in my data directory (~/.local/share/qutebrowser) is sufficient to solve the problem for a while (I've tried it 3 times until now, and it has worked every time).

I hope this can help in narrowing down the problem!

[The-Compiler]

Could someone who can reproduce this try to start with --qt-flag disable-shared-workers (or add 'disable-shared-workers' to the qt.args setting and :restart) and see if that changes anything? If it doesn't, can you still add it and see if it helps with the issue (not) coming back?

So far, this does sound a lot like another case of #5279 (and #5634 probably is too) - just that some change in Qt 5.15 made it harder to debug because it now only happens after 1h. It still sounds like the issue described in the relevant Qt bug: Somehow the cache storage gets corrupted, and Chromium crashes when it tries to read that storage.

The million dollar question nobody has been able to answer yet is how those files got corrupted in the first place...

[glostis]

@The-Compiler I've restarted qutebrowser with --qt-flag disable-shared-workers and unfortunately qutebrowser keeps crashing exactly after one hour...

[rperce]

Potentially of note: I've got this issue, moved .local/share/qutebrowser/webengine out of the way, and that seemed to fix the issue. Last Friday night, I shut my computer down for the weekend; upon booting up this morning, the issue was back. Perhaps the corruption is some sort of improper shutdown cleanup in Qt? I'll try to reproduce that when I have time to sit through several boot cycles, but that may not be until this coming weekend.

[mavaa]

I believe I'm also having this issue, although I haven't checked yet that it happens after exactly one hour, it's pretty close to that.

I'm having the issue on Ubuntu 20.04 LTS, with QB built from source, although the reason I chose to build it is because I had the same issue with the version from apt (it's probably about six months since I changed to source-built).

Latest crash log: https://pastebin.com/mU0r8nsj

I also have another computer (two actually) running arch, where I've never experienced this, with the pacman version. Version dump from that one: https://pastebin.com/hMK9z8xp

I see there are some differences between the two, but I'm not sure if it's worth the time to start messing with version numbers at random(?). User config files are identical on all my machines.

Like rperce I tried to move my webengine directory yesterday, and that seemed to temporarily solve the issue. Today though, after a reboot, it's back again. I have both the webengine dirs from yesterday and today available, if there's something to investigate in those, I will gladly do so.

[mavaa]

I also remembered: Earlier, I ran arch on this machine as well, with qutebrowser from pacman running completely fine. It started to happen after I decided to test out 20.04 (which I'm still doing 🙂 ). I will probably switch back to Arch sooner or later, but I could to some testing and comparisons on my Arch and Ubuntu machines if there's anything that can help. Only caveat is, I probably won't be able to do much on the Arch machine until december 1st, as I'm in the middle of moving to a new appartment right now.

[mavaa]

Accidentally sent a crash report today when the issue occured again, which probably won't contain much info not already in my pastebin links. Sorry about that...

[duckunix]

So, I have found that if I remove ~/.local/share/qutebrowser/webengine/Service\ Worker*, the browser behaves for me after that, until something else messes with the browser, and then I go back to my hourly crashes until I remove it again.

[toofar]

You should be able to see what service workers are registered from Application > Service Workers > "Service workers from other origins" in the dev tools. And chrome://serviceworker-internals/

[alexkohler]

FWIW, I was seeing intermittent crashes and I ended up defining a cron job to rm -rf ~/.local/share/qutebrowser/webengine every 15 minutes and I'm no longer running into crashes.

[mavaa]

I've ended up with a similar solution for now, note that I only need to delete the "Service Workers/CacheStorage" folder (stored this as ~/bin/qutebrowser, which is in my path):

#!/bin/bash
~/src/qutebrowser/.venv/bin/python3 -m qutebrowser "$@"
rm -r "~/.local/share/qutebrowser/webengine/Service Worker/CacheStorage"

This deletes the folder each time I exit qutebrowser, which seems to be enough in my case.

[parisni]

I am experiencing the same trouble, and also the “rm workarround” works. I have the feeling the website that trigger the crash are those sending desktop notifications.

[cizmazia]

I can also concur that I do not experience frequent arbitrary crashes any more after applying @mavaa's workaround (removing the cache before every start of the browser):

#!/bin/bash
rm -frv ~/.local/share/qutebrowser/webengine/Service\ Worker/CacheStorage
~/.local/src/qutebrowser/.venv/bin/python3 -m qutebrowser "$@"

[duckunix]

I can also concur that I do not experience frequent arbitrary crashes any more after applying @mavaa's workaround (removing the cache before every start of the browser):

#!/bin/bash
rm -frv ~/.local/share/qutebrowser/webengine/Service\ Worker/CacheStorage
~/.local/src/qutebrowser/.venv/bin/python3 -m qutebrowser "$@"

Tested that, and so far, so good!

[The-Compiler]

With 7d8fd50 I've now introduced a new qt.workarounds.remove_service_workers setting which can be set to true to nuke the service workers directory on every start.

I'm not really happy with that workaround (and I'd still hope someone gets a reliable reproducer for this some day, so that I can report this properly to Qt upstream) - but I guess for affected people it's a better escape hatch than having to write a wrapper script around qutebrowser.

@mavaa To be honest I'm surprised that approach (deleting the folder after qutebrowser quits) works - I suspect this is caused by an unclean shutdown of some sorts, so I wonder if this gets executed at all. Even if it does, this currently wouldn't work, as ~ isn't expanded by bash inside "...":

[florian@aragog ~]$ ls "~/.local/share/qutebrowser"
/usr/bin/ls: cannot access '~/.local/share/qutebrowser': No such file or directory

@cizmazia @duckunix FWIW this is more or less what qutebrowser is doing now with that workaround enabled.

[mavaa]

My version works because then the folder won't exist the next time I start qutebrowser 🙂
And I did it that way because I forgot I could have added -f to prevent the script from dying if the folder was already deleted 😅

Regarding the ~ you're correct. I have the path hard-coded to my home folder, and rewrote it for github without testing if it works...