search

atlas-engineer / nyxt

Nyxt - the hacker's browser.
https://nyxt-browser.com/
9.85k stars 412 forks source link

Next hangs after cancel print #756

Closed plattfot closed 3 years ago

plattfot commented 4 years ago

Describe the bug Locks next after I hit cancel on the print popup. Precise recipe to reproduce the issue Run next --no-init, hit C-p and hit cancel on the print dialog. Then it locks.

Information

Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {1000618083}> 0: ("bogus stack frame") 1: ((FLET SB-UNIX::BODY :IN SB-THREAD::FUTEX-WAIT)) 2: (SB-THREAD::%%WAIT-FOR-MUTEX #<SB-THREAD:MUTEX "thread result lock" owner: #<SB-THREAD:THREAD "cl-cffi-gtk main thread" RUNNING {1007795353}>> #<SB-THREAD:THREAD "main thread" RUNNING {1000618083}> NIL NIL NIL NIL) 3: (SB-THREAD::%WAIT-FOR-MUTEX #<SB-THREAD:MUTEX "thread result lock" owner: #<SB-THREAD:THREAD "cl-cffi-gtk main thread" RUNNING {1007795353}>> #<SB-THREAD:THREAD "main thread" RUNNING {1000618083}> NIL NIL NIL NIL NIL NIL) 4: ((FLET "WITHOUT-INTERRUPTS-BODY-2" :IN SB-THREAD:JOIN-THREAD)) 5: (SB-THREAD:JOIN-THREAD #<SB-THREAD:THREAD "cl-cffi-gtk main thread" RUNNING {1007795353}> :DEFAULT NIL :TIMEOUT NIL) 6: (START (:NO-INIT T)) 7: ((LAMBDA NIL :IN UIOP/IMAGE:RESTORE-IMAGE)) 8: (UIOP/IMAGE:CALL-WITH-FATAL-CONDITION-HANDLER #<CLOSURE (LAMBDA NIL :IN UIOP/IMAGE:RESTORE-IMAGE) {1005D26E6B}>) 9: ((FLET SB-UNIX::BODY :IN SB-EXT:SAVE-LISP-AND-DIE)) 10: ((FLET "WITHOUT-INTERRUPTS-BODY-14" :IN SB-EXT:SAVE-LISP-AND-DIE)) 11: ((LABELS SB-IMPL::RESTART-LISP :IN SB-EXT:SAVE-LISP-AND-DIE))

unhandled condition in --disable-debugger mode, quitting

Ambrevar commented 4 years ago

I can reproduce this frequently but not always. I haven't found a precise recipe yet (there may be known).

I can also reproduce when printing to a PDF. I don't have a printer, so I haven't tried printing for real but that's probably not relevant.

Could be an FFI issue.

@jmercouris: Can you reproduce?

If we can't figure it out, maybe we should try webkit_print_operation_new (). https://webkitgtk.org/reference/webkit2gtk/unstable/WebKitPrintOperation.html#webkit-print-operation-new

jmercouris commented 4 years ago

I can't reproduce. I've tried to print and have cancelled hundreds of times over several sessions

Ambrevar commented 4 years ago

Have you tried on the quick start page with no other buffer open (in other words, an empty session)?

plattfot commented 4 years ago

For me it hangs regardless if I have an empty session or not. And it also hangs when I press print. I just tested this with printing to a pdf (I don't have a printer).

Another thing I discovered is that if I try to change the output file, nextcrashes with this backtrace

(sbcl:24934): Gtk-WARNING **: 09:24:03.070: Could not load a pixbuf from /org/gtk/libgtk/theme/Adwaita/assets/bullet-symbolic.svg.
This may indicate that pixbuf loaders or the mime database could not be found.

(sbcl:24934): Gtk-WARNING **: 09:24:03.081: Could not find the icon 'list-remove-symbolic-ltr'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
    http://icon-theme.freedesktop.org/releases
^CUnhandled SB-SYS:INTERACTIVE-INTERRUPT in thread #<SB-THREAD:THREAD "main thread" RUNNING
                                                    {1000618083}>:
  Interactive interrupt at #x7FE5073B4787.

Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {1000618083}>
0: ("bogus stack frame")
1: ((FLET SB-UNIX::BODY :IN SB-THREAD::FUTEX-WAIT))
2: (SB-THREAD::%%WAIT-FOR-MUTEX #<SB-THREAD:MUTEX "thread result lock" owner: #<SB-THREAD:THREAD "cl-cffi-gtk main thread" RUNNING {1007795CB3}>> #<SB-THREAD:THREAD "main thread" RUNNING {1000618083}> NIL NIL NIL NIL)
3: (SB-THREAD::%WAIT-FOR-MUTEX #<SB-THREAD:MUTEX "thread result lock" owner: #<SB-THREAD:THREAD "cl-cffi-gtk main thread" RUNNING {1007795CB3}>> #<SB-THREAD:THREAD "main thread" RUNNING {1000618083}> NIL NIL NIL NIL NIL NIL)
4: ((FLET "WITHOUT-INTERRUPTS-BODY-2" :IN SB-THREAD:JOIN-THREAD))
5: (SB-THREAD:JOIN-THREAD #<SB-THREAD:THREAD "cl-cffi-gtk main thread" RUNNING {1007795CB3}> :DEFAULT NIL :TIMEOUT NIL)
6: (START (:NO-INIT T))
7: ((LAMBDA NIL :IN UIOP/IMAGE:RESTORE-IMAGE))
8: (UIOP/IMAGE:CALL-WITH-FATAL-CONDITION-HANDLER #<CLOSURE (LAMBDA NIL :IN UIOP/IMAGE:RESTORE-IMAGE) {1005D26E6B}>)
9: ((FLET SB-UNIX::BODY :IN SB-EXT:SAVE-LISP-AND-DIE))
10: ((FLET "WITHOUT-INTERRUPTS-BODY-14" :IN SB-EXT:SAVE-LISP-AND-DIE))
11: ((LABELS SB-IMPL::RESTART-LISP :IN SB-EXT:SAVE-LISP-AND-DIE))

unhandled condition in --disable-debugger mode, quitting

Note that firefox also crashes when trying to change the output in the print dialog. So looks like something is definitely wrong on my side.

plattfot commented 4 years ago

Think I figured out the crash when picking the path. At least it fixed it in firefox. Cannot test it in next right now as it seem to be broken with the latest guix commit (guix (GNU Guix) b2d35dd9aeb3f6c566d53bfc9534abfd57860a51) and I cannot rollback right now as I'm debugging an unrelated thing with guix.

But anyway the issue was XDG_DATA_DIRS wasn't set correctly. I'm using a bare bone arch linux setup with sway and I do not set XDG_DATA_DIRS anywhere so I'm just relying on the defaults. But when I installed guix using the install script, it add some paths to the XDG_DATA_DIRS.

Namely this from /etc/profile.d/guix.sh

[ -f "$GUIX_PROFILE/etc/profile" ] && . "$GUIX_PROFILE/etc/profile"

# set XDG_DATA_DIRS to include Guix installations
export XDG_DATA_DIRS="$GUIX_PROFILE/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}"

The . "$GUIX_PROFILE/etc/profile" will add things to the XDG_DATA_DIRS so the second line will not add /usr/local/share/:/user/share/. And I ended up with just path to guix stuff in that file. So I just added a script /etc/profile.d/0-xdg.sh

export XDG_HOME_CONFIG=$HOME/.config
export XDG_DATA_DIRS=/usr/local/share/:/usr/share/

The 0- prefix is to make sure it gets picked up first. Rebooted and then no more crashes in firefox. And I would assume next as they seem to use the same print dialog. I'll update once I get next working again.

plattfot commented 4 years ago

Can confirm that the XDG_DATA_DIRS fix, also fixed the crash for next. So now it is just hanging when I try to press cancel or print.

Ambrevar commented 4 years ago

I can't seem to reproduce your XDG_DATA_DIRS crash.

I'm on Guix System and I have no /usr... in my XDG_DATA_DIRS. If I set the PDF output file to "blah.pdf" and press print, it hangs Next, but it does not crash it.

jmercouris commented 4 years ago

Perhaps you have a problem with pixbuf if it hangs next but does not crash it. Maybe incorrectly configured?

Ambrevar commented 4 years ago

I believe the pixbuf issue is a benign warning about missing icons.

azzamsa commented 4 years ago

for me it always hang after copying text in github issue then pasting it. I need to kill the process and start next again.

plattfot commented 4 years ago

For me it works fine copying and pasting text. I just have to remember not to try and cut text as then I kill the buffer.

Like @Ambrevar mention I also believe the pixbuf warning is not the cause of this. I have the same warning in firefox and it works fine for both printing and cancel the operation.

Ambrevar commented 4 years ago

@azzamsa Is this issue #593?

Ambrevar commented 4 years ago

@azzamsa Should be fixed on master.

Ambrevar commented 4 years ago

Now that I understood what was going on with the pasting issue, maybe it's the same thing here: we are waiting somewhere in out code while WebKitGTK is waiting for us and this results in a dead-lock.

Need to have a more proper look at what happens when we get the result from the parenscript. We might be waiting there.

jmercouris commented 4 years ago

There is no javascript return value for print or anything like that. Please try the following @Ambrevar

Ambrevar commented 4 years ago

Yes, it still freezes Nyxt, while Epiphany does not.

I think this is a problem similar to the C-v issue. Epiphany does not suffer from it because it does not have dead-lock problems with a Common Lisp thread running next to it :p

jmercouris commented 4 years ago

Please try replacing your print-buffer definition with the following:

(define-command print-buffer ()
  "Print the current buffer."
  (bt:make-thread
   (lambda ()
     (ffi-within-renderer-thread *browser* #'%print-buffer))))
Ambrevar commented 4 years ago

I've already tried that, sadly it does not help.

jolmg commented 4 years ago

This also happens to me, but I don't have XDG_DATA_DIRS set.

jolmg commented 4 years ago

Nyxt version 2-pre-release-1

Installed on Archlinux using the AUR package nyxt-browser-git.

jolmg commented 4 years ago

This is my output of nyxt -v:

$ nyxt -v  
Arguments parsed: (VERBOSE T) and NIL
Nyxt version 2-pre-release-1
 <INFO> [18:09:23] nyxt start.lisp (start-browser) -
  Using data profile "default".
 <INFO> [18:09:23] nyxt start.lisp (bind-socket-or-quit) -
  Listening to socket "/home/jol/.local/share/nyxt/nyxt.socket".
<DEBUG> [18:09:23] nyxt renderer-gtk.lisp (ffi-initialize gtk-browser) -
  Initializing GTK Interface
<DEBUG> [18:09:23] nyxt help.lisp (help form-fun-6) - Calling command HELP.
<DEBUG> [18:09:23] nyxt buffer.lisp (make-buffer form-fun-6) -
  Calling command MAKE-BUFFER.
<DEBUG> [18:09:23] nyxt mode.lisp (make-mode) - NYXT::MODE-SYMBOL: BASE-MODE
  BUFFER: #<GTK-BUFFER {1006F30583}>
  (NYXT::MODE-COMMAND NYXT::MODE-SYMBOL): #<NYXT::COMMAND {100374A533}> 
<DEBUG> [18:09:23] nyxt base-mode.lisp (base-mode form-fun-12) -
  Calling command BASE-MODE.
<DEBUG> [18:09:23] nyxt base-mode.lisp (base-mode form-fun-12) -
  BASE-MODE enabled.
<DEBUG> [18:09:23] nyxt mode.lisp (make-mode) -
  NYXT::MODE-SYMBOL: NYXT::WEB-MODE BUFFER: #<GTK-BUFFER {1006F30583}>
  (NYXT::MODE-COMMAND NYXT::MODE-SYMBOL): #<NYXT::COMMAND {100374A413}> 
<DEBUG> [18:09:23] nyxt/web-mode web-mode.lisp (web-mode form-fun-16) -
  Calling command WEB-MODE.
<DEBUG> [18:09:23] nyxt/web-mode web-mode.lisp (web-mode form-fun-16) -
  WEB-MODE enabled.
<DEBUG> [18:09:23] nyxt mode.lisp (make-mode) -
  NYXT::MODE-SYMBOL: NYXT::CERTIFICATE-EXCEPTION-MODE
  BUFFER: #<GTK-BUFFER {1006F30583}>
  (NYXT::MODE-COMMAND NYXT::MODE-SYMBOL): #<NYXT::COMMAND {100374A2C3}> 
<DEBUG> [18:09:23] nyxt/certificate-exception-mode certificate-exception-mode.lisp (certificate-exception-mode form-fun-22) -
  Calling command CERTIFICATE-EXCEPTION-MODE.
<DEBUG> [18:09:23] nyxt/certificate-exception-mode certificate-exception-mode.lisp (certificate-exception-mode form-fun-22) -
  CERTIFICATE-EXCEPTION-MODE enabled.
<DEBUG> [18:09:23] nyxt/help-mode help-mode.lisp (help-mode form-fun-10) -
  Calling command HELP-MODE.
<DEBUG> [18:09:23] nyxt/help-mode help-mode.lisp (help-mode form-fun-10) -
  HELP-MODE enabled.
<DEBUG> [18:09:24] nyxt mode.lisp (make-mode) -
  NYXT::MODE-SYMBOL: NYXT::MINIBUFFER-MODE BUFFER: #<MINIBUFFER {100646EDC3}>
  (NYXT::MODE-COMMAND NYXT::MODE-SYMBOL): #<NYXT::COMMAND {100374A883}> 
<DEBUG> [18:09:24] nyxt/minibuffer-mode minibuffer-mode.lisp (minibuffer-mode form-fun-12) -
  Calling command MINIBUFFER-MODE.
<DEBUG> [18:09:24] nyxt/minibuffer-mode minibuffer-mode.lisp (minibuffer-mode form-fun-12) -
  MINIBUFFER-MODE enabled.
<DEBUG> [18:09:25] nyxt renderer-gtk.lisp (on-signal-key-press-event gtk-window) -
  NYXT::KEY-STRING: NIL NYXT::KEYCODE: 37 CHARACTER: #\Nul
  NYXT::KEYVAL-NAME: "Control_L" 
<DEBUG> [18:09:26] nyxt renderer-gtk.lisp (on-signal-key-press-event gtk-window) -
  NYXT::KEY-STRING: "down" NYXT::KEYCODE: 116 CHARACTER: #\Nul
  NYXT::KEYVAL-NAME: "Down" 
<DEBUG> [18:09:26] nyxt input.lisp (dispatch-input-event) -
  Found key binding "down" [#116]
<DEBUG> [18:09:26] nyxt/minibuffer-mode minibuffer-mode.lisp (select-next form-fun-6) -
  Calling command SELECT-NEXT.
<DEBUG> [18:09:26] nyxt renderer-gtk.lisp (on-signal-key-press-event gtk-window) -
  NYXT::KEY-STRING: "return" NYXT::KEYCODE: 36 CHARACTER: #\Return
  NYXT::KEYVAL-NAME: "Return" 
<DEBUG> [18:09:26] nyxt input.lisp (dispatch-input-event) -
  Found key binding "return" [#36]
<DEBUG> [18:09:26] nyxt/minibuffer-mode minibuffer-mode.lisp (return-input form-fun-6) -
  Calling command RETURN-INPUT.
<DEBUG> [18:09:26] nyxt/minibuffer-mode minibuffer-mode.lisp (cancel-input form-fun-6) -
  Calling command CANCEL-INPUT.
<DEBUG> [18:09:27] nyxt renderer-gtk.lisp (on-signal-key-press-event gtk-window) -
  NYXT::KEY-STRING: NIL NYXT::KEYCODE: 37 CHARACTER: #\Nul
  NYXT::KEYVAL-NAME: "Control_L" 
<DEBUG> [18:09:28] nyxt renderer-gtk.lisp (on-signal-key-press-event gtk-window) -
  NYXT::KEY-STRING: "p" NYXT::KEYCODE: 33 CHARACTER: #\p NYXT::KEYVAL-NAME: "p"
  NYXT::MODIFIERS: ("control") 
<DEBUG> [18:09:28] nyxt input.lisp (dispatch-input-event) -
  Found key binding "C-p" [C-#33]
<DEBUG> [18:09:28] nyxt buffer.lisp (print-buffer form-fun-6) -
  Calling command PRINT-BUFFER.
Memory pressure relief: Total: res = 12906496/12820480/-86016, res+swap = 7733248/7733248/0
Memory pressure relief: Total: res = 12894208/12836864/-57344, res+swap = 7716864/7716864/0
Memory pressure relief: Total: res = 12517376/12382208/-135168, res+swap = 7327744/7327744/0
Memory pressure relief: Total: res = 16355328/14135296/-2220032, res+swap = 10817536/10817536/0
Memory pressure relief: Total: res = 14200832/13672448/-528384, res+swap = 8622080/8622080/0

Semi last "Memory pressure relief" happened when pressing "Cancel". The last one happened a couple seconds after focusing out to another window.

I can only kill it with SIGKILL.

It's not necessary to hit Cancel. Shaking a window above the nyxt window and/or the print dialog enough causes it to get close to a freeze. It makes the modeline/statusline-like bar and print dialog slow to re-render, and the page contents simply don't re-render (the area stays a solid cream color).

Ambrevar commented 4 years ago

I've never seen the "memory pressure relief" lines before. Which version of WebKitGTK are you using? (Should look like 2.2x.y, not 4.x.)

jolmg commented 4 years ago

It's 2.28.4.

jolmg commented 4 years ago

I just checked luakit and midori, which also use WebKitGTK, to see if they have the same behaviour. luakit has the same rendering problem when shaking the window, but not midori, and neither have problems with clicking "Cancel".

Ambrevar commented 4 years ago

I can reproduce this issue on the simple browser example from cl-webkit, which means the issue does not come from Nyxt.

To test this, I loaded https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_print in a web view and clicked on the "print" button, then cancel in the dialog box.

However, the issue does not happen in cl-gobject-introspection! Nor does the copy-paste issue from #593.

I'll start working on a new GI-based renderer soon, it might free us from so many issues that we get probably because of cl-cffi-gtk.

ghost commented 4 years ago

I tested with Midori and cancel print non hangs the browser, but it happens to me with nyxt

Ambrevar commented 4 years ago

I've confirmed that this is a CFFI issue with cl-webkit.

I'll work on a new renderer soon, hopefully this will fix it.

jmercouris commented 3 years ago

This issue is fixed when running GTK with the new GI renderer.

Ambrevar commented 3 years ago

I suggest we leave this kind of issues open until the GI renderer is the default.

Ambrevar commented 3 years ago

Or better: create an issue to make GI the default! :)