Uzbl

Tasklist

FS#265 - Uzbl-tabbed freezes on some pages

Attached to Project: Uzbl
Opened by Jan Vargas (andevellicus) - 2011-05-01 02:37:39 PM
Last edited by Ben Boeckel (mathstuf) - 2014-03-06 07:56:14 AM
Task Type Bug Report
Category uzbl-tabbed
Status Unconfirmed
Assigned To No-one
Operating System Linux
Severity Medium
Priority Normal
Reported Version Development
Due in Version 1.0
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

I'm running archlinux with python2, uzbl-git 20110501. Running uzbl-tabbed from the terminal, I can browse without a problem, but occasionally when browsing a page uzbl will completely hang and become unresponsive, ultimately drawing a blank screen. Terminal output will show:

(uzbl-core:8385): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Error resolving 'upload.wikimedia.org': Name or service not known

uzbl-browser does not have this problem whatsoever, for some reason it is restricted to uzbl-tabbed. Please let me know what other information I can contribute. Thanks.
This task depends upon

Comment by David Keijser (keis) - 2011-05-07 02:33:32 PM
this was tracked down to uzbl-core getting stuck in a flush after writing a event.
Comment by murchik (murchik) - 2012-12-17 10:18:55 PM
Yeah, such crap happens sometimes. Some keybinding to kill current tab instance can become helpful. I'm doing it manually by kill -9 by now.
Comment by murchik (murchik) - 2013-12-13 02:39:07 PM
Any progress on this? Sometimes it's really annoying especially when you can't identify the proccess to kill, because for some processes there's no --uri (btw, why?). Example:

$ps ax | grep uzbl | tail -7
15923 ? Sl 0:02 uzbl-core -n 15747-26 -s 27263041 --connect-socket /tmp/uzbltabbed_15747.socket --uri http://bucardo.org/wiki/Pgsi#Download --connect-socket /h
ome/murchik/.cache/uzbl/event_daemon
21486 ? Sl 2:52 uzbl-core -n 15747-100 -s 27269957 --connect-socket /tmp/uzbltabbed_15747.socket --connect-socket /home/murchik/.cache/uzbl/event_daemon
29163 ? Sl 4:12 uzbl-core -n 15747-105 -s 27270780 --connect-socket /tmp/uzbltabbed_15747.socket --connect-socket /home/murchik/.cache/uzbl/event_daemon
31153 ? Sl 0:05 uzbl-core -n 15747-107 -s 27271024 --connect-socket /tmp/uzbltabbed_15747.socket --connect-socket /home/murchik/.cache/uzbl/event_daemon
31653 ? Sl 2:44 uzbl-core -n 15747-109 -s 27271052 --connect-socket /tmp/uzbltabbed_15747.socket --connect-socket /home/murchik/.cache/uzbl/event_daemon
32455 ? Sl 4:23 uzbl-core -n 15747-50 -s 27264752 --connect-socket /tmp/uzbltabbed_15747.socket --connect-socket /home/murchik/.cache/uzbl/event_daemon

And killing nice working processes one by one gets one pissed off.
Comment by Ben Boeckel (mathstuf) - 2014-03-06 06:16:59 AM
Could you please test with the latest 'next' branch? I don't know why a pile of instances wouldn't have a URI unless they were opened manually (not with a link). I've seen some stutters in uzbl-core as well, but it's not reliable (mashing Ctrl seems to push enough through the queue to get things going). I have yet to catch it with gdb to see what it's actually waiting on.
Comment by Ben Boeckel (mathstuf) - 2014-03-06 08:03:03 AM
I just went through and initialized GError pointers to NULL…seems I missed two before. I don't know about the hanging (yet), but the console message stuff should be gone for good.

Loading...