I got Segmentation fault (core dumped) crash when I enabled svg feature and attaching menu to WindowDesc.
svg feature while NOT attaching a menu to window run just fine.Replicated in
To quickly replicate:
Add svg to the default feature in druid's Cargo.toml
[features]
default = ["gtk","svg"]
then run the example which uses menu:
cargo run --example multiwin
DEBUG [druid::localization] available locales [], current en-US
DEBUG [druid::localization] resolved: [en-US]
INFO [multiwin] Window added, id: WindowId(1)
Segmentation fault (core dumped)
OS used:
Ubuntu 18.04.5 LTS x86_64
Kernel: 4.15.0-118-generic
I wasn't able to replicate this in the published 0.6.0 crate.
Thanks for the report! I'm having trouble reproducing, though, even with the exact same commit. Are you able to produce a backtrace?
@jneem there was no backtrace.
I am also able to reproduce this problem on a freshly installed ubuntu 20.04
I'm also getting this segfault with no backtrace after updating my app to master (was on 0.6). I'm on pop_os latest which is based on ubuntu 20.10. I'm also using svg feature and menus. Segfault went away when I got rid of menus.
I also get this on Ubuntu 20.04, but not Windows 10. Same project as @futurepaul.
Are any of you able to get a backtrace using gdb? I found some instructions here.
I followed the gdb instructions, got this:
Starting program: /home/futurepaul/dev/rust/druid/target/debug/examples/multiwin-3d3680e1e9e4ce7a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff5e8a640 (LWP 192921)]
[New Thread 0x7ffff5689640 (LWP 192922)]
[New Thread 0x7ffff4e28640 (LWP 192923)]
[New Thread 0x7fffef100640 (LWP 192924)]
DEBUG [druid::localization] available locales [], current en-US
DEBUG [druid::localization] resolved: [en-US]
INFO [multiwin] Window added, id: WindowId(1)
Thread 1 "multiwin-3d3680" received signal SIGSEGV, Segmentation fault.
0x0000555555671618 in BEInt<unsigned int, 4>::operator unsigned int (this=0x0)
at harfbuzz/src/hb.hh:620
620 return (v[0] << 24) + (v[1] << 16) + (v[2] << 8) + (v[3]);
here's the backtrace apologies for the poor formatting this has nice colors on my screen!
#0 0x0000555555671618 in BEInt<unsigned int, 4>::operator unsigned int() const
(this=0x0) at harfbuzz/src/hb.hh:620
#1 0x0000555555670332 in OT::IntType<unsigned int, 4u>::operator unsigned int() const (this=0x0) at harfbuzz/src/hb-open-type.hh:64
#2 0x000055555566f81e in OT::OpenTypeFontFile::get_face(unsigned int, unsigned int*) const (this=0x0, i=0, base_offset=0x7fffffff91bc) at harfbuzz/src/hb-open-file.hh:408
#3 0x000055555566feb0 in _hb_face_for_data_reference_table(hb_face_t*, hb_tag_t, void*) (face=0x555555dfad40, tag=1835104368, user_data=0x555555dfad20)
at harfbuzz/src/hb-face.cc:164
#4 0x000055555566eace in hb_face_t::reference_table(unsigned int) const
(this=0x555555dfad40, tag=1835104368) at harfbuzz/src/hb-face.hh:76
#5 0x000055555567015e in hb_face_reference_table(hb_face_t const*, hb_tag_t)
(face=0x555555dfad40, tag=1835104368) at harfbuzz/src/hb-face.cc:309
#6 0x00005555556c87eb in hb_sanitize_context_t::reference_table<OT::maxp>(hb_face_t const*, unsigned int) (this=0x7fffffff92c0, face=0x555555dfad40, tableTag=1835104368)
at harfbuzz/src/hb-sanitize.hh:379
#7 0x00005555556c866e in hb_face_t::load_num_glyphs() const (this=0x555555dfad40)
at harfbuzz/src/hb-static.cc:59
#8 0x000055555566eb57 in hb_face_t::get_num_glyphs() const (this=0x555555dfad40)
at harfbuzz/src/hb-face.hh:96
#9 0x00005555556701fb in hb_face_get_glyph_count(hb_face_t const*)
(face=0x555555dfad40) at harfbuzz/src/hb-face.cc:371
#10 0x00005555556a3ca6 in hb_sanitize_context_t::reference_table<OT::head>(hb_face_t const*, unsigned int) (this=0x7fffffff93a0, face=0x555555dfad40, tableTag=1751474532)
at harfbuzz/src/hb-sanitize.hh:378
#11 0x00005555556a2867 in hb_table_lazy_loader_t<OT::head, 1u>::create(hb_face_t*)
(face=0x555555dfad40) at harfbuzz/src/hb-machinery.hh:327
#12 0x00005555556a08c8 in hb_data_wrapper_t<hb_face_t, 1u>::call_create<hb_blob_t, hb_table_lazy_loader_t<OT::head, 1u> >() const (this=0x555555dfad90)
at harfbuzz/src/hb-machinery.hh:158
#13 0x000055555569db02 in hb_lazy_loader_t<OT::head, hb_table_lazy_loader_t<OT::head, 1u>, hb_face_t, 1u, hb_blob_t>::get_stored() const (this=0x555555dfad90)
at harfbuzz/src/hb-machinery.hh:243
#14 0x0000555555698756 in hb_lazy_loader_t<OT::head, hb_table_lazy_loader_t<OT::head, 1u>, hb_face_t, 1u, hb_blob_t>::get() const (this=0x555555dfad90)
at harfbuzz/src/hb-machinery.hh:267
#15 0x00005555556c8872 in hb_lazy_loader_t<OT::head, hb_table_lazy_loader_t<OT::head, 1u>, hb_face_t, 1u, hb_blob_t>::operator->() const (this=0x555555dfad90)
at harfbuzz/src/hb-machinery.hh:220
#16 0x00005555556c86ec in hb_face_t::load_upem() const (this=0x555555dfad40) at harfbuzz/src/hb-static.cc:70
#17 0x000055555566eb1b in hb_face_t::get_upem() const (this=0x555555dfad40) at harfbuzz/src/hb-face.hh:87
#18 0x00005555556701dd in hb_face_get_upem(hb_face_t const*) (face=0x555555dfad40) at harfbuzz/src/hb-face.cc:356
#19 0x000055555567882b in _hb_font_create(hb_face_t*) (face=0x555555dfad40) at harfbuzz/src/hb-font.cc:1152
#20 0x0000555555678880 in hb_font_create(hb_face_t*) (face=0x555555dfad40) at harfbuzz/src/hb-font.cc:1170
#21 0x00007ffff6afdd1d in () at /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0
#22 0x00007ffff769699b in pango_font_get_hb_font () at /lib/x86_64-linux-gnu/libpango-1.0.so.0
#23 0x00007ffff76b334b in () at /lib/x86_64-linux-gnu/libpango-1.0.so.0
#24 0x00007ffff76b2b5f in pango_shape_with_flags () at /lib/x86_64-linux-gnu/libpango-1.0.so.0
#25 0x00007ffff76a33f0 in () at /lib/x86_64-linux-gnu/libpango-1.0.so.0
#26 0x00007ffff76a46a0 in () at /lib/x86_64-linux-gnu/libpango-1.0.so.0
#27 0x00007ffff76a699e in () at /lib/x86_64-linux-gnu/libpango-1.0.so.0
#28 0x00007ffff76a8549 in () at /lib/x86_64-linux-gnu/libpango-1.0.so.0
#29 0x00007ffff7a1e720 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#30 0x00007ffff7961b07 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#31 0x00007ffff79669ef in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#32 0x00007ffff7a1b067 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#33 0x00007ffff7ad585b in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#34 0x00007ffff7ad4f09 in gtk_widget_get_preferred_height () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#35 0x00007ffff7a43c57 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#36 0x00007ffff7961b07 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#37 0x00007ffff79669ef in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#38 0x00007ffff7a4385a in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#39 0x00007ffff7ad528b in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#40 0x00007ffff7ad5df5 in gtk_widget_get_preferred_height_and_baseline_for_width () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#41 0x00007ffff7a40ca0 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#42 0x00007ffff7961b07 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#43 0x00007ffff79669ef in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#44 0x00007ffff7a412aa in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#45 0x00007ffff7fbdd9f in () at /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libappmenu-gtk-module.so
#46 0x00007ffff7ad528b in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#47 0x00007ffff7ad5df5 in gtk_widget_get_preferred_height_and_baseline_for_width () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#48 0x00007ffff790dff1 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#49 0x00007ffff7961b07 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#50 0x00007ffff79669ef in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#51 0x00007ffff790ea67 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#52 0x00007ffff7ad585b in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#53 0x00007ffff7ad4f09 in gtk_widget_get_preferred_height () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#54 0x00007ffff7b9e8ca in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#55 0x00007ffff7900a90 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#56 0x00007ffff7ad528b in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#57 0x00007ffff7ad5df5 in gtk_widget_get_preferred_height_and_baseline_for_width () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#58 0x00007ffff7ad5ee7 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#59 0x00007ffff7ba0511 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#60 0x00007ffff7ba777f in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#61 0x00007ffff72f6b56 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#62 0x00007ffff730fbbf in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#63 0x00007ffff730fda3 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#64 0x00007ffff7ba2a8e in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#65 0x00007ffff72f68fa in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#66 0x00007ffff730914a in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#67 0x00007ffff730fc41 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#68 0x00007ffff730fda3 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#69 0x00007ffff7b8e826 in gtk_widget_show () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#70 0x000055555582cbef in <O as gtk::auto::widget::WidgetExt>::show_all (self=0x555555aedae0)
at /home/futurepaul/.cargo/registry/src/github.com-1ecc6299db9ec823/gtk-0.9.2/src/auto/widget.rs:2708
#71 0x000055555580fedb in druid_shell::platform::gtk::window::WindowHandle::show (self=0x7fffffffc360) at druid-shell/src/platform/gtk/window.rs:764
#72 0x00005555558074fb in druid_shell::window::WindowHandle::show (self=0x7fffffffc360) at druid-shell/src/window.rs:179
#73 0x00005555555bbebc in druid::app::AppLauncher<T>::launch (self=..., data=...) at /home/futurepaul/dev/rust/druid/druid/src/app.rs:177
#74 0x00005555555ded91 in multiwin::main () at druid/examples/multiwin.rs:47
Thanks for the backtrace, but unfortunately it's a bit tricky to interpret. My wild guess is that we're somehow linking to the wrong version of harfbuzz (because it looks like the only effect of enabling "svg" is that it restricts the harfbuzz-rs version...)
Here's what valgrind says:
$ valgrind ../target/debug/examples/multiwin
==2337== Memcheck, a memory error detector
==2337== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2337== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==2337== Command: ./../target/debug/examples/multiwin
==2337==
--2337-- WARNING: unhandled amd64-linux syscall: 315
--2337-- You may be able to write your own handler.
--2337-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--2337-- Nevertheless we consider this a bug. Please report
--2337-- it at http://valgrind.org/support/bug_reports.html.
==2340== Warning: invalid file descriptor 4084 in syscall close()
==2340== Warning: invalid file descriptor 4085 in syscall close()
==2340== Warning: invalid file descriptor 4086 in syscall close()
==2340== Warning: invalid file descriptor 4087 in syscall close()
==2340== Use --log-fd=<number> to select an alternative log fd.
==2340== Warning: invalid file descriptor 4088 in syscall close()
==2340== Warning: invalid file descriptor 4089 in syscall close()
==2337== Syscall param statx(file_name) points to unaddressable byte(s)
==2337== at 0x578789D: syscall (syscall.S:38)
==2337== by 0x4549AB: statx (weak.rs:95)
==2337== by 0x4549AB: std::sys::unix::fs::try_statx (fs.rs:123)
==2337== by 0x45409E: std::sys::unix::fs::stat (fs.rs:1022)
==2337== by 0x44EED8: metadata<&std::path::Path> (fs.rs:1566)
==2337== by 0x44EED8: std::path::Path::is_dir (path.rs:2470)
==2337== by 0x1D6117: druid::localization::L10nManager::new::get_available_locales (localization.rs:198)
==2337== by 0x1D5686: druid::localization::L10nManager::new (localization.rs:217)
==2337== by 0x1F9D22: <druid::env::Env as core::default::Default>::default (env.rs:471)
==2337== by 0x17622D: druid::app::AppLauncher<T>::launch (app.rs:162)
==2337== by 0x157EB1: multiwin::main (multiwin.rs:46)
==2337== by 0x18C85A: core::ops::function::FnOnce::call_once (function.rs:227)
==2337== by 0x19230D: std::sys_common::backtrace::__rust_begin_short_backtrace (backtrace.rs:137)
==2337== by 0x17F1A0: std::rt::lang_start::{{closure}} (rt.rs:66)
==2337== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==2337==
==2337== Syscall param statx(buf) points to unaddressable byte(s)
==2337== at 0x578789D: syscall (syscall.S:38)
==2337== by 0x4549AB: statx (weak.rs:95)
==2337== by 0x4549AB: std::sys::unix::fs::try_statx (fs.rs:123)
==2337== by 0x45409E: std::sys::unix::fs::stat (fs.rs:1022)
==2337== by 0x44EED8: metadata<&std::path::Path> (fs.rs:1566)
==2337== by 0x44EED8: std::path::Path::is_dir (path.rs:2470)
==2337== by 0x1D6117: druid::localization::L10nManager::new::get_available_locales (localization.rs:198)
==2337== by 0x1D5686: druid::localization::L10nManager::new (localization.rs:217)
==2337== by 0x1F9D22: <druid::env::Env as core::default::Default>::default (env.rs:471)
==2337== by 0x17622D: druid::app::AppLauncher<T>::launch (app.rs:162)
==2337== by 0x157EB1: multiwin::main (multiwin.rs:46)
==2337== by 0x18C85A: core::ops::function::FnOnce::call_once (function.rs:227)
==2337== by 0x19230D: std::sys_common::backtrace::__rust_begin_short_backtrace (backtrace.rs:137)
==2337== by 0x17F1A0: std::rt::lang_start::{{closure}} (rt.rs:66)
==2337== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==2337==
DEBUG [druid::localization] available locales [de-DE, en-US, fr-CA], current en-US
DEBUG [druid::localization] resolved: [en-US]
INFO [multiwin] Window added, id: WindowId(1)
==2337== Invalid read of size 1
==2337== at 0x21D5A6: BEInt<unsigned int, 4>::operator unsigned int() const (hb.hh:620)
==2337== by 0x21C2BD: OT::IntType<unsigned int, 4u>::operator unsigned int() const (hb-open-type.hh:64)
==2337== by 0x21B7AB: OT::OpenTypeFontFile::get_face(unsigned int, unsigned int*) const (hb-open-file.hh:408)
==2337== by 0x21BE3B: _hb_face_for_data_reference_table(hb_face_t*, unsigned int, void*) (hb-face.cc:164)
==2337== by 0x21AA57: hb_face_t::reference_table(unsigned int) const (hb-face.hh:76)
==2337== by 0x21C0EA: hb_face_reference_table (hb-face.cc:309)
==2337== by 0x2744F4: hb_blob_t* hb_sanitize_context_t::reference_table<OT::maxp>(hb_face_t const*, unsigned int) (hb-sanitize.hh:379)
==2337== by 0x274377: hb_face_t::load_num_glyphs() const (hb-static.cc:59)
==2337== by 0x21AAE0: hb_face_t::get_num_glyphs() const (hb-face.hh:96)
==2337== by 0x21C187: hb_face_get_glyph_count (hb-face.cc:371)
==2337== by 0x24FAF3: hb_blob_t* hb_sanitize_context_t::reference_table<OT::head>(hb_face_t const*, unsigned int) (hb-sanitize.hh:378)
==2337== by 0x24E6B2: hb_table_lazy_loader_t<OT::head, 1u>::create(hb_face_t*) (hb-machinery.hh:327)
==2337== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==2337==
==2337==
==2337== Process terminating with default action of signal 11 (SIGSEGV)
==2337== Access not within mapped region at address 0x0
==2337== at 0x21D5A6: BEInt<unsigned int, 4>::operator unsigned int() const (hb.hh:620)
==2337== by 0x21C2BD: OT::IntType<unsigned int, 4u>::operator unsigned int() const (hb-open-type.hh:64)
==2337== by 0x21B7AB: OT::OpenTypeFontFile::get_face(unsigned int, unsigned int*) const (hb-open-file.hh:408)
==2337== by 0x21BE3B: _hb_face_for_data_reference_table(hb_face_t*, unsigned int, void*) (hb-face.cc:164)
==2337== by 0x21AA57: hb_face_t::reference_table(unsigned int) const (hb-face.hh:76)
==2337== by 0x21C0EA: hb_face_reference_table (hb-face.cc:309)
==2337== by 0x2744F4: hb_blob_t* hb_sanitize_context_t::reference_table<OT::maxp>(hb_face_t const*, unsigned int) (hb-sanitize.hh:379)
==2337== by 0x274377: hb_face_t::load_num_glyphs() const (hb-static.cc:59)
==2337== by 0x21AAE0: hb_face_t::get_num_glyphs() const (hb-face.hh:96)
==2337== by 0x21C187: hb_face_get_glyph_count (hb-face.cc:371)
==2337== by 0x24FAF3: hb_blob_t* hb_sanitize_context_t::reference_table<OT::head>(hb_face_t const*, unsigned int) (hb-sanitize.hh:378)
==2337== by 0x24E6B2: hb_table_lazy_loader_t<OT::head, 1u>::create(hb_face_t*) (hb-machinery.hh:327)
==2337== If you believe this happened as a result of a stack
==2337== overflow in your program's main thread (unlikely but
==2337== possible), you can try to increase the size of the
==2337== main thread stack using the --main-stacksize= flag.
==2337== The main thread stack size used in this run was 8388608.
==2337==
==2337== HEAP SUMMARY:
==2337== in use at exit: 1,820,616 bytes in 23,182 blocks
==2337== total heap usage: 187,516 allocs, 164,334 frees, 12,894,149 bytes allocated
==2337==
==2337== LEAK SUMMARY:
==2337== definitely lost: 1,536 bytes in 3 blocks
==2337== indirectly lost: 7,863 bytes in 321 blocks
==2337== possibly lost: 22,162 bytes in 127 blocks
==2337== still reachable: 1,675,527 bytes in 21,863 blocks
==2337== of which reachable via heuristic:
==2337== length64 : 4,520 bytes in 77 blocks
==2337== newarray : 2,112 bytes in 52 blocks
==2337== suppressed: 0 bytes in 0 blocks
==2337== Rerun with --leak-check=full to see details of leaked memory
==2337==
==2337== For lists of detected and suppressed errors, rerun with: -s
==2337== ERROR SUMMARY: 4 errors from 3 contexts (suppressed: 0 from 0)
Segmentation fault
I had a similar problem to this when linking to libgpg. The problem was a version mismatch. Not saying that's what's happening here, just that its my guess.
So I just noticed that harfbuzz-sys defaults to building its own copy of harfbuzz instead of linking to the system version. It seems likely that this is causing some issues; I'll have a PR up for testing in a minute.
Sorry for all the random guessing, but could you check if 67c7db6cd works? It's the last commit before the harfbuzz-sys version got bumped.
More wild guessing: I noticed that usvg now depends on rustybuzz instead of harfbuzz, and rustybuzz contains a vendored copy of harfbuzz in it. Could it be that the symbols are conflicting?
Sorry for all the random guessing, but could you check if 67c7db6 works? It's the last commit before the harfbuzz-sys version got bumped.
I'm very happy to help debug this. We want to upgrade for the Tabs widget in particular but this is preventing it.
I get a ton of gtk compile errors when I try to build that commit hash.
More wild guessing: I noticed that usvg now depends on rustybuzz instead of harfbuzz, and rustybuzz contains a vendored copy of harfbuzz in it. Could it be that the symbols are conflicting?
usvg hasn't been updated in 4 months. Hard to believe this had been broken for 4 months, right?
Thanks for checking, I'll have another candidate PR up in a minute.
I'm more and more convinced that the issue is that rustybuzz introduces some symbols that conflict with the system harfbuzz. Latest evidence is that rustybuzz embeds harfbuzz 2.7. This is the same version that's installed on my system (and has no segfault), but ubuntu apparently is on harfbuzz 2.6.
Also, nm -gD confirms that the multiwin example (compiled with svg support) exports a bunch of harfbuzz symbols
<snip>
0000000000179f4e T hb_aat_layout_feature_type_get_name_id
0000000000179f81 T hb_aat_layout_feature_type_get_selector_infos
0000000000179f0e T hb_aat_layout_get_feature_types
0000000000179d10 T hb_aat_layout_has_positioning
0000000000179a12 T hb_aat_layout_has_substitution
0000000000179e2f T hb_aat_layout_has_tracking
<snip>
I have a pr on the way that downgrades usvg to 0.10.0, and it appears to prevent these symbols from appearing, because 0.10.0 depends on harfbuzz and not rustybuzz. By the way, this hasn't been broken for 4 months, because we only upgraded the usvg version 2 months ago.
I believe this is fixed by #1356.
Yep, it's fixed now. Thank you guys!.
Thank you so much to everyone involved for tracking this down!
Most helpful comment
I believe this is fixed by #1356.