Opened 2 years ago
Closed 18 months ago
#65743 closed defect (fixed)
cherrytree @0.99.48: crash on launch
Reported by: | afield1235 | Owned by: | mascguy (Christopher Nielsen) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.7.2 |
Keywords: | Cc: | ||
Port: | cherrytree |
Description
System
- macOS Monterey 12.5.1 (x86)
- MacPorts 2.7.2
- XQuartz 2.8.2
X11 (Default)
I am installing Cherrytree from Macports (no install errors) and I get the following errors when launching from Terminal or XQuartz. I have Keepnote installed and working so I know my XQuartz is working properly. I also confirmed I can launch all the GTK3 +x11 demo apps/widget test apps with XQuartz.
% sudo port install cherrytree
% cherrytree
Errors:
[2022-08-30 19:25:42.657] [gtk] [warning] AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[2022-08-30 19:25:42.658] [gtk] [critical] Class::register_derived_type(): base_query.type_name is NULL.
Quartz (Preferred)
I then removed both Cherrytree/GTK3 and then reinstalled both with the +quartz option. When launching then, I get the following errors. I also confirmed I can launch all the GTK3 +quartz demo apps/widget test apps so I know my native Quartz and GTK3 was working properly.
% sudo port install gtk3 +quartz
% sudo port install cherrytree +quartz
% cherrytree
Errors:
dyld[20081]: Symbol not found: (_gtk_plug_construct)
Referenced from: '/opt/local/lib/libgtkmm-3.0.1.dylib'
Expected in: '/opt/local/lib/libgtk-3.0.dylib'
zsh: abort cherrytree
Attachments (1)
Change History (49)
comment:1 Changed 2 years ago by jmroot (Joshua Root)
Milestone: | MacPorts Future |
---|
comment:2 Changed 2 years ago by mascguy (Christopher Nielsen)
comment:3 Changed 2 years ago by mascguy (Christopher Nielsen)
Also, can you verify that all dependencies - including gtk3
and gtkmm3
, among others - are installed with +quartz
?
comment:4 Changed 2 years ago by mascguy (Christopher Nielsen)
Cc: | mascguy added |
---|
comment:5 Changed 2 years ago by afield1235
Hello!
Quartz (Preferred)
No changes with the rev-upgrade.
% sudo port rev-upgrade ---> Scanning binaries for linking errors ---> No broken files found. ---> No broken ports found.
I listed my built depedencies below, several were not installed with the +quartz option.
cairo @1.17.4_0+quartz+x11 (active) cairomm @1.12.2_0+quartz+x11 (active) **glib2 @2.68.4_0+x11 (active) **glibmm @2.62.0_0+x11 (active) gtk3 @3.24.34_2+quartz (active) **gtkmm3 @3.24.2_0+x11 (active) pango @1.50.7_0+quartz+x11 (active) pangomm @2.42.1_1+quartz+x11 (active)
Since I had built the +x11 version first and then only manually uninstalled Cherrrytree and GTK3 for Quartz reinstall, I did a complete uninstall and reinstall of MacPorts. I then installed cherrytree with the +quartz option fresh:
% sudo port install cherrytree +quartz Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled: strchr: found in gtk+-3.24.34/config.log % cherrytree [2022-08-31 14:04:15.890] [gtk] [critical] Class::register_derived_type(): base_query.type_name is NULL. zsh: segmentation fault cherrytree
It appears I am now getting an error similar to the one I was getting with the X11 Variant. The dependencies all look fine now.
cairo @1.17.4_0+quartz+x11 (active) cairomm @1.12.2_0+quartz+x11 (active) glib2 @2.68.4_0+quartz (active) glibmm @2.62.0_0+quartz (active) gtk3 @3.24.34_2+quartz (active) gtkmm3 @3.24.2_0+quartz (active) pango @1.50.7_0+quartz+x11 (active) pangomm @2.42.1_1+quartz+x11 (active)
comment:6 Changed 2 years ago by mascguy (Christopher Nielsen)
Ah, I'm seeing a similar crash. For an immediate fix, try renaming the app config file, before opening CherryTree:
$ mv -v ~/.config/cherrytree/config.cfg{,.backup} ~/.config/cherrytree/config.cfg -> ~/.config/cherrytree/config.cfg.backup
Let me know if that workaround solves the crash.
If so, we'll check the list of upstream bugs, to see if this is a known issue.
comment:7 follow-up: 8 Changed 2 years ago by afield1235
I actually don't have a config.cfg, there is a cherrytree folder there but it's empty.
Also, I would like to go the Quartz route but do we also want to adress the issues with the X11 Variant? I'll let you lead.
Thanks.
EDIT:
These are not explicit dependencies but were installed as X11 variant, no quartz versions. They are needed for vala @0.56.2_0.
gd2 @2.3.3_1+x11 (active) graphviz @2.50.0_0+pangocairo+x11 (active)
comment:8 Changed 2 years ago by mascguy (Christopher Nielsen)
Replying to afield1235:
I actually don't have a config.cfg, there is a cherrytree folder there but it's empty.
Just tested on Monterey, to ensure we're comparing apples-to-apples. And I'm seeing the crash there too, but only after the second run. (In other words, only after the app has created a config file.)
So I'm a bit surprised that a config isn't being created for you, as the app creates/saves that on exit.
Regardless, to better understand what's happening, can you install CherryTree with +quartz+debug
?
Then run the app, and reproduce the crash. When the macOS error dialog is displayed, click "Report," and copy the stack trace for thread zero. Then paste that text here.
comment:9 Changed 2 years ago by mascguy (Christopher Nielsen)
Cc: | mascguy removed |
---|---|
Owner: | set to mascguy |
Status: | new → assigned |
comment:10 Changed 2 years ago by afield1235
Quartz (Preferred)
Please let me know if this helps.
% sudo port install cherrytree +quartz+debug % cherrytree [2022-09-01 10:47:36.743] [gtk] [critical] Class::register_derived_type(): base_query.type_name is NULL. zsh: segmentation fault cherrytree
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 cherrytree 0x10fec4f0b void spdlog::logger::log_<fs::path const&>(spdlog::source_loc, spdlog::level::level_enum, fmt::v9::basic_string_view<char>, fs::path const&) + 43 1 cherrytree 0x10fe0ecf1 CtConfig::_load_from_file() + 327 2 cherrytree 0x10fe0de9f CtConfig::CtConfig() + 3099 3 cherrytree 0x10fde91c5 CtApp::_on_startup() + 235 4 cherrytree 0x10fde9bf0 CtApp::on_activate() + 28 5 libgiomm-2.4.1.dylib 0x110e5cc2c Gio::Application_Class::activate_callback(_GApplication*) + 78 6 libgobject-2.0.0.dylib 0x111f31074 _g_closure_invoke_va + 201 7 libgobject-2.0.0.dylib 0x111f45ff7 g_signal_emit_valist + 988 8 libgobject-2.0.0.dylib 0x111f46a70 g_signal_emit + 120 9 libgio-2.0.0.dylib 0x1114e759f g_application_real_local_command_line + 1309 10 libgiomm-2.4.1.dylib 0x110e5dcaa Gio::Application::local_command_line_vfunc(char**&, int&) + 76 11 libgiomm-2.4.1.dylib 0x110e5c84a Gio::Application_Class::local_command_line_vfunc_callback(_GApplication*, char***, int*) + 94 12 libgio-2.0.0.dylib 0x1114e5950 g_application_run + 347 13 cherrytree 0x10fd7c1db main + 2103 14 dyld 0x11ab3652e start + 462 .. Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x00007f983c86c800 rcx: 0x77e2d11c7535002d rdx: 0x000000011017f2c9 rdi: 0x0000000000000000 rsi: 0x0000000000000003 rbp: 0x00007ff7b018ede0 rsp: 0x00007ff7b018ec00 r8: 0x00007f983c86d360 r9: 0x000000000000000a r10: 0x00000000000007fb r11: 0x00000000000000ff r12: 0x00007f983c86d2c0 r13: 0x00007f983c86d2d8 r14: 0x0000000000000000 r15: 0x0000000000000003 rip: 0x000000010fec4f0b rfl: 0x0000000000010206 cr2: 0x0000000000000038 Logical CPU: 0 Error Code: 0x00000004 (no mapping for user data read) Trap Number: 14 Thread 0 instruction stream: ff 19 00 eb 22 48 89 c3-f6 85 20 fe ff ff 01 74 ...."H.... ....t 11 48 8b bd 30 fe ff ff-e8 bc fe 19 00 eb 03 48 .H..0..........H 89 c3 e8 fa fe 19 00 48-89 df e8 ae e2 19 00 e9 .......H........ 5c fe ff ff 90 55 48 89-e5 41 57 41 56 41 55 41 \....UH..AWAVAUA 54 53 48 81 ec b8 01 00-00 49 89 c9 41 89 f7 49 TSH......I..A..I 89 fe 48 8b 0d a4 08 2e-00 48 8b 09 48 89 4d d0 ..H......H..H.M. [44]8b 67 38 8a 9f b0 00-00 00 41 39 f4 7e 0b 89 D.g8......A9.~.. <== d9 80 e1 01 0f 84 7b 01-00 00 48 8d 8d d0 fe ff ......{...H..... ff 48 c7 41 f0 00 00 00-00 48 8b 35 5d 03 2e 00 .H.A.....H.5]... 48 83 c6 10 48 89 b5 a0-fe ff ff 48 89 71 e0 48 H...H......H.q.H 89 49 e8 48 c7 41 f8 fa-00 00 00 48 8d 85 20 fe .I.H.A.....H.. . ff ff 4c 89 00 48 8b 0d-29 f3 2d 00 48 89 48 08 ..L..H..).-.H.H. Binary Images: 0x10fd70000 - 0x1101a3fff cherrytree (*) <8ba01523-5f2f-3925-bac2-d9bf690cc0ca> /opt/local/bin/cherrytree 0x110e4e000 - 0x110ee5fff libgiomm-2.4.1.dylib (*) <8d606f15-9e21-38b1-a997-e937babb02c0> /opt/local/lib/libgiomm-2.4.1.dylib 0x111f2b000 - 0x111f5efff libgobject-2.0.0.dylib (*) <91eaccbd-2be5-3c8c-a2b2-6dc1586db756> /opt/local/lib/libgobject-2.0.0.dylib 0x11145b000 - 0x111576fff libgio-2.0.0.dylib (*) <ccf3cfb2-8701-37ef-949e-f5f5a507bba0> /opt/local/lib/libgio-2.0.0.dylib 0x11ab31000 - 0x11ab9cfff dyld (*) <f71fb3ca-5fcc-3577-9457-b047888a46d1> /usr/lib/dyld 0x7ff819fd1000 - 0x7ff819fdcfff libsystem_pthread.dylib (*) <f32b6d06-b156-3da0-b086-a31cf011362b> /usr/lib/system/libsystem_pthread.dylib 0x7ff819f99000 - 0x7ff819fd0fff libsystem_kernel.dylib (*) <792406fe-2224-3c14-ba9f-f076fd7839d2> /usr/lib/system/libsystem_kernel.dylib 0x11232f000 - 0x11240afff libglib-2.0.0.dylib (*) <0497960f-e751-3bf8-94bd-53f86807f3d8> /opt/local/lib/libglib-2.0.0.dylib 0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???
comment:11 follow-up: 12 Changed 2 years ago by afield1235
X11 (Default)
Small aside regarding X11. If I use the -s flag, Cherrytree builds and runs without issue and seems to be the only way to get it to run with X11. This doesn't work for Quartz though.
sudo port install -s cherrytree
comment:12 follow-ups: 13 15 Changed 2 years ago by kencu (Ken)
In your initial report up top, the first x11 issue you mentioned was because dbus wasn’t running. So you’ve probably started that by now by setting it up as dbus says in it’s port notes, and that warning is gone.
The second x11 issue you mentioned is not unusual for x11 apps…. I almost always see many such “ critical” errors running x11 apps of all kinds, and although thre look scary and upstream should fix those, they never seem to affect the port’s function.
tldr; likely nothing wrong with the x11 version, even the prebuilt one on the buildbot.
the quartz version looks hosed for some reason; someone will have to dig in and debug that. The quartz version is the default macos install, and what is used by other package managers on Apple systems. So it’s possibly a MacPorts- specific issue, with the mix of stuff we have.
comment:13 Changed 2 years ago by mascguy (Christopher Nielsen)
Replying to kencu:
the quartz version looks hosed for some reason; someone will have to dig in and debug that. The quartz version is the default macos install, and what is used by other package managers on Apple systems. So it’s possibly a MacPorts- specific issue, with the mix of stuff we have.
Yep, and I haven't forgotten about this.
Based on the stack trace - as well as a similar crash I see locally, across macOS releases - it definitely seems related to loading of the config:
0 cherrytree 0x10fec4f0b void spdlog::logger::log_<fs::path const&>(spdlog::source_loc, spdlog::level::level_enum, fmt::v9::basic_string_view<char>, fs::path const&) + 43 1 cherrytree 0x10fe0ecf1 CtConfig::_load_from_file() + 327 2 cherrytree 0x10fe0de9f CtConfig::CtConfig() + 3099
comment:14 Changed 2 years ago by kencu (Ken)
But only on quartz? Very weird that x11 is fine (assuming it is).
I’d take that upstream then. https://github.com/giuspen/cherrytree
They were very pleasant when I worked with them to bring cherrytree to MacOS/MacPorts in the first place two yesrs ago…
comment:15 Changed 2 years ago by afield1235
Replying to kencu:
tldr; likely nothing wrong with the x11 version, even the prebuilt one on the buildbot.
I can confirm the X11 variant is not working. I just did a fresh install, dbus is loaded and running in activity monitor (that issue was already cleared up last week), it launches X11 and then nothing. It also fails to write any ~/.config/cherrytree data.
sudo port install cherrytree cherrytree [2022-09-11 13:14:21.366] [gtk] [critical] Class::register_derived_type(): base_query.type_name is NULL. zsh: segmentation fault cherrytree
Quick note: I also stopped using Xquartz from their website download and am using port's xorg-server now. That was causing different issues from the very start of my first post. With xorg-server, I am now getting the same errors with X11 or Quartz, they both fail with the segmentation fault.
comment:16 Changed 2 years ago by mascguy (Christopher Nielsen)
Summary: | cherrytree @0.99.48_0+x11 or +quartz: Critical Errors Launching macOS Monterey 12.5.1 → cherrytree @0.99.48: crash on launch |
---|
comment:17 follow-up: 19 Changed 2 years ago by kencu (Ken)
fixed - let's see if upstream has a better plan, though:
comment:18 Changed 2 years ago by Christopher Nielsen <mascguy@…>
comment:19 Changed 2 years ago by mascguy (Christopher Nielsen)
Replying to kencu:
fixed - let's see if upstream has a better plan, though:
Looks good, thanks Ken!
Any thoughts on the crash at shutdown?
comment:20 Changed 2 years ago by kencu (Ken)
I looked… but seems harder !
something to do with that initial NULL type warning was where I got to, then an abyss of gtk technical details…
comment:21 Changed 2 years ago by afield1235
Hello,
Quick question: In order to test, do I need to wait for the next release of Cherrytree to be released and then added to MacPorts? I don't have an environment set up for building from Git/Source. I did a fresh install after the Macports commit and I am still crashing on launch so I assume that is only part of the solution.
comment:22 Changed 2 years ago by kencu (Ken)
You may have another issue... or perhaps what fixed the issue for me does not fully fix it for you. There are many variables.
I would do this:
sudo port uninstall cherrytree rm -rf ~/.config/cherrytree sudo port -v selfupdate sudo port -v install cherrytree
and then run cherrytree. If you crash on launch -- well, damn. Please post a log.
There is another issue that has to do with a crash when quitting that I am looking into but it is harder to fix, so far at least. But that doesn't interfere with running it, for me.
comment:23 Changed 2 years ago by afield1235
Where is the log file or how can I record a log?
This is the terminal output.
[2022-09-15 21:51:14.066] [gtk] [critical] Class::register_derived_type(): base_query.type_name is NULL. zsh: segmentation fault cherrytree
comment:24 Changed 2 years ago by kencu (Ken)
does it not run at all? I get that segmentation fault at the very end of running the program, which is not pretty, but doesn't matter at all to me using it.
comment:25 follow-up: 27 Changed 2 years ago by afield1235
Yes, it does not run at all. mascguy recommended removing the ~/.config/cherrytree folder as a workaround but that never worked. The folder is re-created but no files are populated and the app never launches.
comment:26 Changed 2 years ago by kencu (Ken)
I assume you have updated and are getting the version of cherrytree that is patched. You can search for the patch being applied to be 100% sure you have it.
By the way, I believe that the crash at the very end of running the program is caused by the [gtk] [critical] Class::register_derived_type(): base_query.type_name is NULL.
issue, where during initialization, it appears that one (or more) of the gtk3 type registrations is failing.
I traced it like this, using lldb:
(lldb) breakpoint set --file class.cc --line 71 Breakpoint 6: where = libglibmm-2.4.1.dylib`Glib::Class::register_derived_type(unsigned long, _GTypeModule*) + 166 at class.cc:71:5, address = 0x0000000108048b76 (lldb) c Process 67660 resuming Process 67660 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 6.1 frame #0: 0x0000000108048b76 libglibmm-2.4.1.dylib`Glib::Class::register_derived_type(this=0x0000000106f4d160, base_type=105553156123712, module=0x0000000000000000) at class.cc:71:5 68 69 if (!(base_query.type_name)) 70 { -> 71 g_critical("Class::register_derived_type(): base_query.type_name is NULL."); 72 return; 73 } 74 Target 0: (cherrytree) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 6.1 * frame #0: 0x0000000108048b76 libglibmm-2.4.1.dylib`Glib::Class::register_derived_type(this=0x0000000106f4d160, base_type=105553156123712, module=0x0000000000000000) at class.cc:71:5 frame #1: 0x0000000108048ac1 libglibmm-2.4.1.dylib`Glib::Class::register_derived_type(this=0x0000000106f4d160, base_type=105553156123712) at class.cc:30:10 frame #2: 0x0000000106f34902 libgtksourceviewmm-3.0.0.dylib`Gsv::StyleSchemeChooser_Class::init(this=0x0000000106f4d160) at styleschemechooser.cc:63:5 frame #3: 0x0000000106f34f00 libgtksourceviewmm-3.0.0.dylib`Gsv::StyleSchemeChooser::get_type() at styleschemechooser.cc:128:36 frame #4: 0x0000000106f3b6bb libgtksourceviewmm-3.0.0.dylib`Gsv::wrap_init() at wrap_init.cc:159:3 frame #5: 0x0000000106f3b6fb libgtksourceviewmm-3.0.0.dylib`Gsv::init() at init.cc:36:5 frame #6: 0x00000001002f501a cherrytree`CtApp::CtApp(this=0x00000001097066b0, application_id_postfix=(string_ = "")) at ct_app.cc:35:5 frame #7: 0x00000001002f53e3 cherrytree`CtApp::create(application_id_postfix=(string_ = "")) at ct_app.cc:54:36 frame #8: 0x000000010000fcaf cherrytree`main(argc=1, argv=0x00007ff7bfeff8d8) at ct_main.cc:128:33 frame #9: 0x00000001057a952e dyld`start + 462 (lldb) frame var (Glib::Class *) this = 0x0000000106f4d160 (GType) base_type = 105553156123712 (GTypeModule *) module = nullptr (GTypeQuery) base_query = (type = 0, type_name = 0x0000000000000000, class_size = 0, instance_size = 0) (const guint16) class_size = 0 (const guint16) instance_size = 0 (const GTypeInfo) derived_info = { class_size = 0 base_init = 0x0000000000000000 base_finalize = 0x0000000000000000 class_init = 0x0000000106f34910 (libgtksourceviewmm-3.0.0.dylib`Gsv::StyleSchemeChooser_Class::class_init_function(void*, void*) at styleschemechooser.cc:74) class_finalize = 0x0000000000000000 class_data = 0x0000000000000000 instance_size = 0 n_preallocs = 0 instance_init = 0x0000000000000000 value_table = nullptr } (gchar *) derived_name = 0x0000600000218260 "`\x82\x8cޭ\xbe" (lldb) frame sel 1 frame #1: 0x0000000108048ac1 libglibmm-2.4.1.dylib`Glib::Class::register_derived_type(this=0x0000000106f4d160, base_type=105553156123712) at class.cc:30:10 27 void 28 Class::register_derived_type(GType base_type) 29 { -> 30 return register_derived_type(base_type, nullptr); 31 } 32 33 void (lldb) frame var (Glib::Class *) this = 0x0000000106f4d160 (GType) base_type = 105553156123712 (lldb) frame sel 2 frame #2: 0x0000000106f34902 libgtksourceviewmm-3.0.0.dylib`Gsv::StyleSchemeChooser_Class::init(this=0x0000000106f4d160) at styleschemechooser.cc:63:5 60 //CppClassParent::CppObjectType::get_type(); 61 62 // Create the wrapper type, with the same class/instance size as the base type. -> 63 register_derived_type(gtk_source_style_scheme_chooser_get_type()); 64 65 // Add derived versions of interfaces, if the C type implements any interfaces: 66 (lldb) frame var (Gsv::StyleSchemeChooser_Class *) this = 0x0000000106f4d160 (lldb) frame sel 3 frame #3: 0x0000000106f34f00 libgtksourceviewmm-3.0.0.dylib`Gsv::StyleSchemeChooser::get_type() at styleschemechooser.cc:128:36 125 126 GType StyleSchemeChooser::get_type() 127 { -> 128 return styleschemechooser_class_.init().get_type(); 129 } 130 131 (lldb) frame var (lldb) frame sel 4 frame #4: 0x0000000106f3b6bb libgtksourceviewmm-3.0.0.dylib`Gsv::wrap_init() at wrap_init.cc:159:3 156 SearchSettings::get_type(); 157 Style::get_type(); 158 StyleScheme::get_type(); -> 159 StyleSchemeChooser::get_type(); 160 StyleSchemeChooserButton::get_type(); 161 StyleSchemeChooserWidget::get_type(); 162 StyleSchemeManager::get_type(); (lldb) frame var (lldb) frame sel 5 frame #5: 0x0000000106f3b6fb libgtksourceviewmm-3.0.0.dylib`Gsv::init() at init.cc:36:5 33 if (!s_init) 34 { 35 Gtk::Main::init_gtkmm_internals () ; -> 36 Gsv::wrap_init () ; 37 s_init = true ; 38 } 39 }
Now I know that all looks probably quite confusing, but basically this call:
register_derived_type(gtk_source_style_scheme_chooser_get_type());
is not supposed to return NULL, it is supposed to find a type that matches this selector gtk_source_style_scheme_chooser_get_type
and register it.
I am not a gtk3 expert, but the class documentation is here <https://gjs-docs.gjsify.org/classes/GtkSource_3_0.GtkSource.StyleSchemeChooser.html> and it should answer to that call, so at the moment I'm somewhat uncertain about why it is not.
Perhaps all our gtk infrastructure need to be updated to current versions -- most of it is unfortunately very out of date. I rebuilt them all from source, so it's not just a matter of them needing to be rebuilt against new headers.
comment:27 Changed 2 years ago by kencu (Ken)
Replying to afield1235:
Yes, it does not run at all. mascguy recommended removing the ~/.config/cherrytree folder as a workaround but that never worked. The folder is re-created but no files are populated and the app never launches.
By the way, that was one of the instructions I referenced above -- so if you did not follow the instructions I posted *exactly*, please try to do so before you conclude you're totally busted.
comment:28 follow-up: 30 Changed 2 years ago by afield1235
I followed his instructions first.
$ mv -v ~/.config/cherrytree/config.cfg{,.backup} ~/.config/cherrytree/config.cfg -> ~/.config/cherrytree/config.cfg.backup
I then followed your instructions.
sudo port uninstall cherrytree rm -rf ~/.config/cherrytree sudo port -v selfupdate sudo port -v install cherrytree
No Dice
comment:29 Changed 2 years ago by kencu (Ken)
one thing here:
frame #1: 0x0000000108048ac1 libglibmm-2.4.1.dylib`Glib::Class::register_derived_type(this=0x0000000106f4d160, base_type=105553156123712) at class.cc:30:10
that is a very weird looking value for base_type
Edit: no it's actually not -- they all look like similar to that, it seems.
comment:30 follow-ups: 32 45 Changed 2 years ago by kencu (Ken)
Replying to afield1235:
No Dice
Ah, too bad. I have no more ideas for you, unless you want to get fancy :>
You need to build cherrytree with the debug variant turned on, and ideally with optimizations turned off.
To do that you edit the cherrytree Portfile:
bbedit `port file cherrytree`
and add a line like this:
configure.optflags -g
right under compiler.cxx_standard 2017
so it looks like this:
compiler.cxx_standard 2017 configure.optflags -g patchfiles-append patch-cherrytree-all-apple-is-not-homebrew-for-goodness-sake.diff # Fix crash on launch; see: https://trac.macports.org/ticket/65743 patchfiles-append patch-ct_filesystem-empty-string.diff
then you build cherrytree like this:
sudo port uninstall cherrytree sudo port -v -s -k install cherrytree +debug
and then when it is done, you do this:
lldb cherrytree
then hit r
to make it run, and when it crashes, you type bt
and copy and paste up the results here.
If you are really being helpful, you also read the frame variables, and do the same for the top four or five frames, like I did above.
Then we might have a chance of seeing what is going on with an error we (I at least) can't reproduce.
comment:31 follow-up: 33 Changed 2 years ago by kencu (Ken)
in particular, an issue here could be that our glibmm is WAY behind our glib2 (and glibmm-devel also).
perhaps I'll start updating stuff like that as time goes by, but others have traditionally been more interested in that than me.
comment:32 follow-up: 34 Changed 2 years ago by mascguy (Christopher Nielsen)
Replying to kencu:
Ah, too bad. I have no more ideas for you, unless you want to get fancy :>
You need to build cherrytree with the debug variant turned on, and ideally with optimizations turned off.
You're making things wayyyyyyy too complicated. ;-)
CherryTree has a working +debug
variant, courtesy of pg cmake. And it works quite nicely in my testing.
comment:33 follow-up: 35 Changed 2 years ago by mascguy (Christopher Nielsen)
Replying to kencu:
in particular, an issue here could be that our glibmm is WAY behind our glib2 (and glibmm-devel also).
perhaps I'll start updating stuff like that as time goes by, but others have traditionally been more interested in that than me.
Updating glibmm
is on my near-term work list, but haven't gotten too far into it. So if you're feeling up to it, please feel free!
One thing I did notice though, is a fun change in behavior with the later versions: Rather than using a fixed PkgConfig filename - it had remained glibmm-2.4.pc
for a long while - now the file is generated with the current lib version. (i.e., glibmm-2.68.pc
, for version 2.68.x.) Nor does there appear (?) to be a formal Meson build option to override that behavior, unless it's done via a core Meson option.
This is a royal PITA, as it complicates migrating to a path dep for dependents. (I was going to switch all of those over, so that we can use glibmm-devel
as a drop-in replacement.)
I suppose we can potentially rename the generated .pc
file back to a more general name? Assuming that doing so: 1) Doesn't violate standard PkgConfig practice; and 2) Doesn't break dependent projects.
Sigh...
comment:34 follow-up: 37 Changed 2 years ago by kencu (Ken)
Replying to mascguy:
Replying to kencu: You're making things wayyyyyyy too complicated. ;-)
CherryTree has a working
+debug
variant, courtesy of pg cmake. And it works quite nicely in my testing.
Oh no I’m not.
The cherrytree debug variant does nothing much useful for actual debugging :) Without optimizations turned off, and the code left behind to step through, you will get exactly nowhere.
Of course, I debugged my first software in 1985, so what would I know :)
comment:35 follow-up: 38 Changed 2 years ago by kencu (Ken)
Replying to mascguy:
Replying to kencu:
in particular, an issue here could be that our glibmm is WAY behind our glib2 (and glibmm-devel also).
perhaps I'll start updating stuff like that as time goes by, but others have traditionally been more interested in that than me.
Updating
glibmm
is on my near-term work list, but haven't gotten too far into it. So if you're feeling up to it, please feel free!
I did my local copies already, but other things need to come up at the same time, so I’m on glib2-upstream, now…
To start, can we roll glib2 up a version please? Make glib2-devel become glib, etc? That would help.
For the other issue, If you get stuck finding a consistent file to depend on in the build, just thrown in a cookie in post-destroot yourself… nothing says we can’t use our own cookie files (and it would actually be much simpler if that was all we used all the time on all ports, but I leave those politics for you to play with).
comment:36 Changed 2 years ago by Christopher Nielsen <mascguy@…>
comment:37 Changed 2 years ago by mascguy (Christopher Nielsen)
Replying to kencu:
The cherrytree debug variant does nothing much useful for actual debugging :) Without optimizations turned off, and the code left behind to step through, you will get exactly nowhere.
Sorry, I thought I had validated that we were using the proper cmake build type, etc. (Juggling quite a few ports at the moment, and hard to keep track of them all.) It's fixed now though.
Of course, I debugged my first software in 1985, so what would I know :)
I purchased my first PC - a blistering 12 MHz 286, sporting dual 1.2mb 5.25" floppy drives - a few short years later. So not too far behind you, Mate! ;-)
comment:38 Changed 2 years ago by mascguy (Christopher Nielsen)
Replying to kencu:
I did my local copies already, but other things need to come up at the same time, so I’m on glib2-upstream, now…
To start, can we roll glib2 up a version please? Make glib2-devel become glib, etc? That would help.
Absolutely, just need to validate that glib2-devel
is properly patched vis-a-vis glib2
, to avoid breaking our PPC users. And will take care of this today, as it's time for it anyway.
For the other issue, If you get stuck finding a consistent file to depend on in the build, just thrown in a cookie in post-destroot yourself… nothing says we can’t use our own cookie files (and it would actually be much simpler if that was all we used all the time on all ports, but I leave those politics for you to play with).
Never considered that option, but sounds like a great idea! Will use that going forward, where necessary.
comment:39 follow-up: 41 Changed 2 years ago by Christopher Nielsen <mascguy@…>
comment:40 Changed 2 years ago by kencu (Ken)
the cherrytree/cmake debug variant did not disable default optimizations, so I went looking to see why not, and looks like that is explained here:
Although I’m not sure that’s what I’d default it to, but that was the call… possibly should be reconsidered. So clearing the optflags in the portfiles manually seems the only way, without getting into more portgroups.
Re: building with the port -k
option and running it using lldb… well that is second week of CS101 I guess, but often the only effective method to get the needed info I find.
comment:41 Changed 2 years ago by kencu (Ken)
Replying to Christopher Nielsen <mascguy@…>:
In 3c156b3e2d1b51872e00f5e05259ea4d97fd4a24/macports-ports (master):
Thanks!
comment:42 Changed 2 years ago by Christopher Nielsen <mascguy@…>
comment:43 Changed 2 years ago by mascguy (Christopher Nielsen)
Just checked in an initial iteration of glibmm-devel
, version 2.70.0.
As for the pkg-config name change, the API version has been bumped from 2.4 to 2.68. So that makes more sense, and hopefully the API will remain consistent for at least a few years.
But the flip side is that it requires everything else - gtkmm
/gtkmm3
, atkXXX
, etc, etc - to be updated too. And we may need to support a legacy version of glibmm
for API 2.4, for old/outdated dependents. (But at least there's a 2.64.x release, providing some fixes/updates for that API rev.)
Anyhow, this is going to be a bit involved, as expected. But we're overdue to update all of these anyway, so all good.
We'll see where this goes. Stay Tuned...
comment:44 Changed 2 years ago by Christopher Nielsen <mascguy@…>
comment:45 Changed 2 years ago by afield1235
Replying to kencu:
To do that you edit the cherrytree Portfile:
bbedit `port file cherrytree`
and add a line like this:configure.optflags -gright under
compiler.cxx_standard 2017
so it looks like this:compiler.cxx_standard 2017 configure.optflags -g patchfiles-append patch-cherrytree-all-apple-is-not-homebrew-for-goodness-sake.diff # Fix crash on launch; see: https://trac.macports.org/ticket/65743 patchfiles-append patch-ct_filesystem-empty-string.diffthen you build cherrytree like this:
sudo port uninstall cherrytree sudo port -v -s -k install cherrytree +debug
I followed your instructions and was able to run Cherrytree without any issues other than the segmentation fault when quitting. I didn't even need to use 'lldb' debugger.
% cherrytree [2022-09-16 14:59:09.281] [gtk] [critical] Class::register_derived_type(): base_query.type_name is NULL. [2022-09-16 14:59:09.311] [ ] [warning] /Users/user/.config/cherrytree/config.cfg missing [2022-09-16 14:59:09.583] [ ] [debug] autosave is started [2022-09-16 14:59:32.175] [ ] [debug] shift images in MenuBar/context menu zsh: segmentation fault cherrytree
% cherrytree [2022-09-16 15:00:12.518] [gtk] [critical] Class::register_derived_type(): base_query.type_name is NULL. [2022-09-16 15:00:12.549] [ ] [debug] /Users/user/.config/cherrytree/config.cfg parsed [2022-09-16 15:00:12.813] [ ] [debug] autosave is started
I re-edited the config file and removed the 'configure.optflags -g' and reinstalled Cherrytree a variety of ways with no success!
sudo port -s install cherrytree sudo port -v -s -k install cherrytree sudo port -v -s -k install cherrytree +debug
It always resulted in a segmentation fault upon launch and the app not running.
[2022-09-16 15:06:43.540] [gtk] [critical] Class::register_derived_type(): base_query.type_name is NULL. zsh: segmentation fault cherrytree
Through process of elimination, if I simply added the 'configure.optflags -g' back and reinstalled Cherrytree normally, it would run again fine!
% sudo port install cherrytree
TLDR: What is it about that flag that fixes it for me?
comment:46 follow-up: 47 Changed 2 years ago by kencu (Ken)
well now, that is indeed very interesting… good observation. software debugging is a black art :)
presumably something in the optimizations is doing it then. Now that is indeed harder to sort, but having a function optimized right out ofv he code comes to mind.
comment:47 Changed 2 years ago by mascguy (Christopher Nielsen)
Replying to kencu:
presumably something in the optimizations is doing it then. Now that is indeed harder to sort, but having a function optimized right out ofv he code comes to mind.
We may need to start formally tracking cases where we're hit by an optimization-related bug. (Hard to say for sure whether this is one of those cases, but it certainly looks like it might be...)
comment:48 Changed 18 months ago by mascguy (Christopher Nielsen)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
This was ultimately fixed, courtesy of an upstream patch submitted by @kencu. As of this writing, said patch is now included in all releases going forward.
Issue tracking/details:
Upstream patch:
Thanks Ken!
Given the
dyld
error, can you runsudo port rev-upgrade
to check for issues?