Comments (14)
GSI
commented on May 15, 2024
Tried to run via G_DEBUG=fatal_warnings gdb uzbl-core, but was unable to run into a segfault this way.
from uzbl.
keis
commented on May 15, 2024
You interpreted my ramblings like what I intended :)
Weird that it would work under gdb. Did uzbl still come up all right when running with gdb? Is there any interesting output (with -v) before crashing?
from uzbl.
GSI
commented on May 15, 2024
Just realized that dmesg after the crash provides more details:
[15314.600009] traps: uzbl-core[21082] general protection ip:7f5c20d6ff4b sp:7fff1030de20 error:0 in libc-2.23.so[7f5c20cfb000+198000]
Does this help to track down what exactly in libc causes the error?
from uzbl.
keis
commented on May 15, 2024
I'm afraid not. what's at that address could wary from each build of libc.
You could try enabling core dumps ulimit -c and send that over and the uzbl binary if this is a custom build.
from uzbl.
mathstuf
commented on May 15, 2024
Just a backtrace to start with would be good.
from uzbl.
GSI
commented on May 15, 2024
What could be the reason for uzbl-core to not crash when called from within gdb?
Within less of 10 invocations of /usr/bin/uzbl-core, it crashes rather consistantly.
However, I just tried again to run it from gdb (gdb /usr/bin/uzbl-core) some 50 times, and it does not crash.
(Even made this to avoid exhaustion:
xdotool type 'gdb /usr/bin/uzbl-core'; xdotool key 36 ; xdotool type 'run about:blank'; xdotool key 36 ; xdotool type bt ; xdotool key 36 ; xdotool key q key 36 key Up key Up)
from uzbl.
GSI
commented on May 15, 2024
I found some explanation for the differing behaviour within gdb.
Anyway, I already found out how to retrieve the core dumps on Arch. Backtrace:
#0 0x00007fd369014f4b in malloc_consolidate () from /usr/lib/libc.so.6
#1 0x00007fd369016c90 in _int_malloc () from /usr/lib/libc.so.6
#2 0x00007fd36901941a in calloc () from /usr/lib/libc.so.6
#3 0x00007fd36653baa5 in ?? () from /usr/lib/libGL.so.1
#4 0x00007fd3665413cd in ?? () from /usr/lib/libGL.so.1
#5 0x00007fd36653a4f5 in ?? () from /usr/lib/libGL.so.1
#6 0x00007fd36de167f6 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#7 0x00007fd36de12264 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#8 0x00007fd36de161e7 in _dl_open () from /lib64/ld-linux-x86-64.so.2
#9 0x00007fd365f7ff09 in ?? () from /usr/lib/libdl.so.2
#10 0x00007fd36de12264 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#11 0x00007fd365f80521 in ?? () from /usr/lib/libdl.so.2
#12 0x00007fd365f7ffa1 in dlopen () from /usr/lib/libdl.so.2
#13 0x00007fd3129e1b05 in libmodman::module_manager::load_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) () from /usr/lib/libproxy.so.1
#14 0x00007fd3129e2cfd in libmodman::module_manager::load_dir(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) () from /usr/lib/libproxy.so.1
#15 0x00007fd3129cf563 in ?? () from /usr/lib/libproxy.so.1
#16 0x00007fd3129d040b in px_proxy_factory_new () from /usr/lib/libproxy.so.1
#17 0x00007fd312bec629 in ?? () from /usr/lib/gio/modules/libgiolibproxy.so
#18 0x00007fd369be1329 in g_type_create_instance () from /usr/lib/libgobject-2.0.so.0
#19 0x00007fd369bc32bb in ?? () from /usr/lib/libgobject-2.0.so.0
#20 0x00007fd369bc4ba1 in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#21 0x00007fd369bc54d4 in g_object_new () from /usr/lib/libgobject-2.0.so.0
#22 0x00007fd369e60261 in ?? () from /usr/lib/libgio-2.0.so.0
#23 0x00007fd369e60410 in ?? () from /usr/lib/libgio-2.0.so.0
#24 0x00007fd36a1e9cf8 in ?? () from /usr/lib/libsoup-2.4.so.1
#25 0x00007fd369bc3837 in ?? () from /usr/lib/libgobject-2.0.so.0
#26 0x00007fd369bc4ba1 in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#27 0x00007fd369bc54d4 in g_object_new () from /usr/lib/libgobject-2.0.so.0
#28 0x00007fd36a1f3d0c in soup_session_add_feature_by_type () from /usr/lib/libsoup-2.4.so.1
#29 0x00007fd36a1f4823 in ?? () from /usr/lib/libsoup-2.4.so.1
#30 0x00007fd369bc5898 in g_object_set_valist () from /usr/lib/libgobject-2.0.so.0
#31 0x00007fd369bc5f6c in g_object_set () from /usr/lib/libgobject-2.0.so.0
#32 0x00007fd36cfc9ca7 in ?? () from /usr/lib/libwebkitgtk-3.0.so.0
#33 0x00007fd36cfc9d40 in ?? () from /usr/lib/libwebkitgtk-3.0.so.0
#34 0x00007fd36c0c06ae in webkit_get_default_session () from /usr/lib/libwebkitgtk-3.0.so.0
#35 0x000000000040ac65 in ?? ()
#36 0x000000000040a59f in ?? ()
#37 0x00007fd368fc0710 in __libc_start_main () from /usr/lib/libc.so.6
#38 0x000000000040a749 in ?? ()
from uzbl.
mathstuf
commented on May 15, 2024
Looks to be something wrong with your soup stack. What library is being loaded here:
#12 0x00007fd365f7ffa1 in dlopen () from /usr/lib/libdl.so.2
Doing:
info registers
p (char*)$rax # for registers which look like pointersshould show the library name of interest. Why is it trying to load libGL from it though…
from uzbl.
GSI
commented on May 15, 2024
(gdb) info registers
rax 0x1ace1 109793
rbx 0x1ad2131 28123441
rcx 0x41 65
rdx 0x2000000000000000 2305843009213693952
rsi 0x1ad21310 449975056
rdi 0x7fd36933bb00 140545979824896
rbp 0x2000000000000000 0x2000000000000000
rsp 0x7fffb58ffc00 0x7fffb58ffc00
r8 0x7fd36933bb58 140545979824984
r9 0x1ad21320 449975072
r10 0x7fd36933bbb8 140545979825080
r11 0x0 0
r12 0x2000000001ad2131 2305843009241817393
r13 0x200 512
r14 0x7fd36933bb18 140545979824920
r15 0x7fd36933bb00 140545979824896
rip 0x7fd369014f4b 0x7fd369014f4b <malloc_consolidate+251>
eflags 0x10206 [ PF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
Suppose this fails as I am working just on the dump, not on a live instance:
(gdb) p (char*)$rax
$1 = 0x1ace1 <error: Cannot access memory at address 0x1ace1>
(Same happens if I try to investigate $rax via core dumps immediately after a crash.)
Also noticed this upon starting. Is that uzbl related too - or just gdb complaining?
Reading symbols from /usr/bin/uzbl-core...(no debugging symbols found)...done.
warning: .dynamic section for "/usr/lib/libgdk-3.so.0" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/usr/lib/libsoup-2.4.so.1" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/usr/lib/libgstpbutils-1.0.so.0" is not at the expected address (wrong library or version misma$
ch?)
warning: .dynamic section for "/usr/lib/libpango-1.0.so.0" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/usr/lib/libpangocairo-1.0.so.0" is not at the expected address (wrong library or version misma$
ch?)
warning: .dynamic section for "/usr/lib/libatk-bridge-2.0.so.0" is not at the expected address (wrong library or version misma$
ch?)
warning: .dynamic section for "/usr/lib/libpangoft2-1.0.so.0" is not at the expected address (wrong library or version mismatc$
?)
from uzbl.
mathstuf
commented on May 15, 2024
That was more a pattern to try rather than a single thing. $rax doesn't look to be a pointer. Try $rbx, $rsi, $rdi, $rsp, $r8, and $r10. My guess is that $rdi is the string we're interested in.
from uzbl.
GSI
commented on May 15, 2024
Here we go:
(gdb) p (char*)$rbx
$2 = 0x1ad2131 ""
(gdb) p (char*)$rcx
$3 = 0x41 <error: Cannot access memory at address 0x41>
(gdb) p (char*)$rdx
$4 = 0x2000000000000000 <error: Cannot access memory at address 0x2000000000000000>
(gdb) p (char*)$rsi
$5 = 0x1ad21310 <error: Cannot access memory at address 0x1ad21310>
(gdb) p (char*)$rdi
$6 = 0x7fd36933bb00 <main_arena> "\001"
(gdb) p (char*)$rbp
$7 = 0x2000000000000000 <error: Cannot access memory at address 0x2000000000000000>
(gdb) p (char*)$rsp
$8 = 0x7fffb58ffc00 "\035"
(gdb) p (char*)$r8
$9 = 0x7fd36933bb58 <main_arena+88> ""
(gdb) p (char*)$r9
$10 = 0x1ad21320 <error: Cannot access memory at address 0x1ad21320>
(gdb) p (char*)$r10
$11 = 0x7fd36933bbb8 <main_arena+184> "\250\273\063i\323\177"
(gdb) p (char*)$r11
$12 = 0x0
(gdb) p (char*)$r12
$13 = 0x2000000001ad2131 <error: Cannot access memory at address 0x2000000001ad2131>
(gdb) p (char*)$r13
$14 = 0x200 <error: Cannot access memory at address 0x200>
(gdb) p (char*)$r14
$15 = 0x7fd36933bb18 <main_arena+24> ""
(gdb) p (char*)$r15
$16 = 0x7fd36933bb00 <main_arena> "\001"
(gdb) p (char*)$rip
$17 = 0x7fd369014f4b <malloc_consolidate+251> "M\213l$\bI\203\345\370\203\342\001uGH\213\023H)\323H\001\325L\213S\020H\213S\030I;Z\030\017\205\224"
(gdb) p (char*)$eflags
Invalid cast.
(gdb) p (char*)$cs
$18 = 0x33 <error: Cannot access memory at address 0x33>
(gdb) p (char*)$ss
$19 = 0x2b <error: Cannot access memory at address 0x2b>
(gdb) p (char*)$ds
$20 = 0x0
(gdb) p (char*)$es
$21 = 0x0
(gdb) p (char*)$fs
$22 = 0x0
(gdb) p (char*)$gs
$23 = 0x0
from uzbl.
mathstuf
commented on May 15, 2024
Hrm. That's not very helpful :( . Maybe strace can help?
from uzbl.
GSI
commented on May 15, 2024
Apparently neither strace nor valgrind allows reproducing the crash.
However, I was able to get something using LD_DEBUG. Below I marked the line where the a crashing instance is trancuted, while a non-crashing instance continues outputting the lines that follow.
I suspect a bug in /usr/lib/libnvidia-tls.so.340.96 - or even a hardware issue. What do you think?
Anyway I'll try without the propietary NVIDIA driver and report back.
LD_DEBUG=files
file=/usr/lib/libproxy/0.4.12/modules/config_gnome3.so [0]; dynamically loaded by /usr/lib/libproxy.so.1 [0]
file=/usr/lib/libproxy/0.4.12/modules/config_gnome3.so [0]; generating link map
dynamic: 0x00007fb242799dd0 base: 0x00007fb24258f000 size: 0x000000000020b290
entry: 0x00007fb242591680 phdr: 0x00007fb24258f040 phnum: 7
[CRASHES HERE]
calling init: /usr/lib/libproxy/0.4.12/modules/config_gnome3.so
opening file=/usr/lib/libproxy/0.4.12/modules/config_gnome3.so [0]; direct_opencount=1
calling fini: /usr/lib/libproxy/0.4.12/modules/config_gnome3.so [0]
LD_DEBUG=bindings
binding file /usr/lib/libGL.so.1 [0] to /usr/lib/libnvidia-tls.so.340.96 [0]: normal symbol `_nv018tls'
binding file /usr/lib/libGL.so.1 [0] to /usr/lib/libc.so.6 [0]: normal symbol `munmap' [GLIBC_2.2.5]
binding file /usr/lib/libGL.so.1 [0] to /usr/lib/libnvidia-tls.so.340.96 [0]: normal symbol `_nv014tls'
[CRASHES HERE]
binding file /usr/lib/libgio-2.0.so.0 [0] to /usr/lib/libglib-2.0.so.0 [0]: normal symbol `g_source_attach'
binding file /usr/lib/libgio-2.0.so.0 [0] to /usr/lib/libglib-2.0.so.0 [0]: normal symbol `g_source_unref'
binding file /usr/lib/libgio-2.0.so.0 [0] to /usr/lib/libglib-2.0.so.0 [0]: normal symbol `g_main_context_new'
from uzbl.
GSI
commented on May 15, 2024
After removing nvidia driver (340.96-8) and switching to nouveau (1.0.12-1) instead, I am now unable to reproduce this type of crash.
I will keep an eye out to see if #242 or #255 might be related.
from uzbl.
Related Issues (20)
- Javascript in binding not getting executed HOT 19
- uzbl-tabbed shows empty window HOT 3
- event manager doesn't "connect"(?) unless uzbl-browser is being verbose HOT 8
- event-manager NEVER connects, verbose option or not HOT 3
- pb with uzbl scripting (load_url_from_surfraw.sh) HOT 1
- global problem which my explain the symptoms (last issues posted by me) HOT 2
- No website displays after compiling in current environment HOT 15
- blank page, couldn't set ssl credentials, PROP_TIMELINE_PROFILING_ENABLED... ??? HOT 3
- Fonts imported from the web don't load HOT 1
- Example files are installed using cp and do not have the right permissions HOT 16
- Which commit should currently be considered "stable"? HOT 4
- CJK input (e.g. mozc, anthy) via X input methods (e.g. uim, fcitx, ibus) doesn't work in the status bar
- alerta.io is not displayed correctly HOT 6
- ReactJs doesn't work
- What is the official status of this project? HOT 5
- Directory "= " created in current directory HOT 2
- www.uzbl.org web site is down HOT 6
- Github isn't shown correctly
- Keyboards scrolling not working HOT 4
- Web feed not working at uzbl.org HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from uzbl.