cherrytree @0.99.48: crash on launch

[afield1235]

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

[mascguy (Christopher Nielsen)]

Given the dyld error, can you run sudo port rev-upgrade to check for issues?

[mascguy (Christopher Nielsen)]

Also, can you verify that all dependencies - including gtk3 and gtkmm3, among others - are installed with +quartz?

[afield1235]

error

[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)

[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.

[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)

[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.

[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> ???

[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

[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.

[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

[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…

[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.

[kencu (Ken)]

fixed - let's see if upstream has a better plan, though:

​https://github.com/giuspen/cherrytree/pull/2118

[Christopher Nielsen <mascguy@…>]

In 7e0cc603b01062ca0949309aa2a5b38d0f93bc11/macports-ports (master):

cherrytree: fix crash on launch
See: #65743

[mascguy (Christopher Nielsen)]

Replying to kencu:

fixed - let's see if upstream has a better plan, though:

​https://github.com/giuspen/cherrytree/pull/2118

Looks good, thanks Ken!

Any thoughts on the crash at shutdown?

[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…

[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.

[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.

[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

[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.

[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.

[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.

[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.

[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

[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.

[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.

[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.

[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.

[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...

[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 :)

[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).

[Christopher Nielsen <mascguy@…>]

In 46074d290ad4e4d0a36ee152492d5170cb69673b/macports-ports (master):

cherrytree: cmake: set build type for debug/release
See: #65743

[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! ;-)

[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.

[Christopher Nielsen <mascguy@…>]

In 3c156b3e2d1b51872e00f5e05259ea4d97fd4a24/macports-ports (master):

glib2: update to 2.70.5
See: #65743

[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:

​https://github.com/macports/macports-ports/blob/46074d290ad4e4d0a36ee152492d5170cb69673b/_resources/port1.0/group/cmake-1.1.tcl#L266

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.

[kencu (Ken)]

Replying to Christopher Nielsen <mascguy@…>:

In 3c156b3e2d1b51872e00f5e05259ea4d97fd4a24/macports-ports (master):

glib2: update to 2.70.5
See: #65743

Thanks!

[Christopher Nielsen <mascguy@…>]

In d2494eaba50b3a40838e3ea03d9d78009a24268b/macports-ports (master):

cherrytree: clear optflags; set by project
See: #65743

[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...

[Christopher Nielsen <mascguy@…>]

In 04e909d5945557a659b2ab065bbbdd3e6447045f/macports-ports (master):

glib2-devel: update to 2.72.3
See: #65743

[afield1235]

Replying to kencu:

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

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?

[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.

[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...)

[mascguy (Christopher Nielsen)]

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:

• ​https://github.com/giuspen/cherrytree/issues/2112

Upstream patch:

• ​https://github.com/giuspen/cherrytree/pull/2118

Thanks Ken!