[macOS] Weird behavior and crash on launch on aarch64 and PowerPC

[barracuda156]

I get a very weird behavior of the binary upon launch. It seems to segfault, however the process is not stopped, and if I move cursor above terminal window, it flashes and displays those meaningless codes. Scrolling spits out a lot of those. This happens even after Control + C to terminate the process.

[barracuda156]

@NikolaDucak It also crashes on PowerPC, though I did initially see the calendar; then it crashed, and subsequent attempts lead to crash almost immediately.

Here is what GDB shows:

(gdb) run
Starting program: /opt/local/bin/caps-log 
Reading symbols for shared libraries +++++++........ done
terminate called after throwing an instance of 'std::system_error'
  what():  Invalid argument

Program received signal SIGABRT, Aborted.
0x00003a20 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (
(gdb) bt 
#0  0x00003a20 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_cou
#1  0x0003ce8c in ftxui::ComponentBase::Active ()
#2  0x0003cebc in ftxui::ComponentBase::Focused ()
#3  0x0003ba10 in ftxui::(anonymous namespace)::ButtonBase::Render ()
#4  0x000276b4 in _ZNSt17_Function_handlerIFSt10shared_ptrIN5ftxui4NodeEEvEZN8ca
#5  0x00048864 in ftxui::Renderer(std::function<std::shared_ptr<ftxui::Node> ()(
#6  0x00026964 in _ZNSt17_Function_handlerIFSt10shared_ptrIN5ftxui4NodeEEvEZN8ca
#7  0x00048864 in ftxui::Renderer(std::function<std::shared_ptr<ftxui::Node> ()(
#8  0x00027c94 in caps_log::view::Calendar::Render ()
#9  0x00022d0c in _ZZN8caps_log4view10AnnualView19makeFullUIComponentEvENUlvE_cl
#10 0x000231bc in _ZNSt17_Function_handlerIFSt10shared_ptrIN5ftxui4NodeEEvEZN8ca
#11 0x00048864 in ftxui::Renderer(std::function<std::shared_ptr<ftxui::Node> ()(
#12 0x0003ccc8 in ftxui::ComponentBase::Render ()
#13 0x0002ba18 in caps_log::view::Promptable::Render ()
#14 0x0004be8c in ftxui::ScreenInteractive::Draw ()
#15 0x0004c6d4 in ftxui::ScreenInteractive::RunOnce ()
#16 0x0004c89c in ftxui::ScreenInteractive::RunOnceBlocking ()
#17 0x00044748 in ftxui::Loop::RunOnceBlocking ()
#18 0x000447b0 in ftxui::Loop::Run ()
#19 0x00049f9c in ftxui::ScreenInteractive::Loop ()
#20 0x00022180 in caps_log::view::AnnualView::run ()
#21 0x00241fe0 in main ()
(gdb) info registers
r0             0x3ce8c	249484
r1             0xbfffe6b0	3221218992
r2             0x2	2
r3             0xbfffe73c	3221219132
r4             0x102606c	16932972
r5             0xbfffe8c8	3221219528
r6             0xffffffffffffffff	18446744073709551615
r7             0x11fc094	18858132
r8             0x0	0
r9             0x1022b54	16919380
r10            0x1026190	16933264
r11            0x28dfc4	2678724
r12            0x39f0	14832
r13            0x0	0
r14            0x0	0
r15            0x24924924	613566756
r16            0xb6db6db7	3067833783
r17            0xbfffea38	3221219896
r18            0xbfffe910	3221219600
r19            0x10260a0	16933024
r20            0x1024838	16926776
r21            0xbfffe91c	3221219612
r22            0xbfffe8c8	3221219528
r23            0xbfffe900	3221219584
r24            0x115f460	18216032
r25            0x19	25
r26            0x1024800	16926720
r27            0x0	0
r28            0xbfffe8c8	3221219528
r29            0x10253ec	16929772
r30            0x1022b50	16919376
r31            0x3b9e4	244196
pc             0x3a20	14880
ps             0x100000000000f930	1152921504606910768
cr             0x24000442	603980866
lr             0x3ce8c	249484
ctr            0x39f0	14832
xer            0x0	0
mq             0x0	0
fpscr          0x82002000	2181046272
vscr           0x10000	65536
vrsave         0x0	0

However, no rows of weird symbols.

[NikolaDucak]

Interesting, I'll take a look!

[barracuda156]

Thanks!

I can test/try whatever suggested on my end, but perhaps need guidance here, since I am not an expert in debugging and the code is unfamiliar.

(I will also try to build it on i386 to compare, when I get to the Intel machine.)

[NikolaDucak]

Thanks that will be helpful! I haven't been able to reproduce the issue, I'm running on aarch64 Mac too.

Can you tell me which compiler and (which version) are you using for arm64 Mac?
And also can you tell me from which commit you are building the caps-log?

[barracuda156]

Do you happen to have MacPorts installed? I can just share a portfile which I wrote. Since the issue is observed on arm64 as well, we can ignore powerpc for the time-being. Symptoms are similar.

[NikolaDucak]

No, but I'd like to try it to see if it will help me reproduce the issue. I know nothing of MacPorts but I'll look into it

[barracuda156]

@NikolaDucak On any recent MacOS using MacPorts should be trivial, and everything is provided pre-built, so it should be easy to try. (On PowerPC I have to build everything from scratch.)

[barracuda156]

And I was using 1.0.0 release. Let me try rebuilding from master, see how it behaves and make a portfile. Will be ready soon, gonna do it right now.

[barracuda156]

@NikolaDucak This builds: macports/macports-ports@baf52d5 (using the latest commit and adding a patch to find Boost).

You could place the portfile into a local overlay repo into sysutils, run sudo port -v sync and then install it via sudo port -v install caps-log.

Re local repos: https://guide.macports.org/chunked/development.local-repositories.html
Basically, you just add a line for an extra portfile repo into /opt/local/etc/macports/sources.conf.
For example, I have:

file:///opt/svacchanda/SonomaPorts
rsync://rsync.macports.org/macports/release/tarballs/ports.tar [default]

[barracuda156]

This is what I see on a ppc machine now:

[NikolaDucak]

I've managed to install it via MacPorts and run it.
No issues, the only thing I observed is that the "version" build does not contain the commit id.

➜  myports /opt/local/bin/caps-log --help
Capstains Log (caps-log)! A CLI journalig tool.
Version: commit-

other than that, no segfaults sigaborts or anything..

Are you successful in reproducing the original issue on arm64 with the Portfile referencing the lates master?

[barracuda156]

It does not segfault now indeed (earlier I used 1.0.0, not the master).

On Sonoma:

[barracuda156]

But on Sonoma I still get screen flashing and those letter+number symbols. Not sure how to use it, maybe I am just doing something wrong :)

On powerpc calendar opens as I show above, colors are not there perhaps due to limitations of old Apple terminal. I will see what happens in VTE.

[barracuda156]

@NikolaDucak Oh wait, it DOES crash on a second launch, both Sonoma and powerpc.

Try quitting and launching it again. I got abort on both machines now.

[NikolaDucak]

Ah I may have reproduced it..
can you share which configuration you are using for running the caps-log?
(~/.caps-log/config.ini and command line arguments if you are setting any)

[barracuda156]

Apparently ~/.caps-log/config.ini is not created automatically, so nothing there (I assumed that installing and running a binary should create some basic sane settings, if those are needed). No arguments used.

What should I put into the config? I will need to produce some initial config via portfile code them, otherwise whoever installs this, gonna think it is broken.

P. S. On a side note, would you like to be a port [co]maintainer?

[barracuda156]

I think it is better to have either a configurable folder for having this file or let the binary check for several reasonable locations. Because we will not want to install anything directly into a home folder, but rather use /opt/local/something (/opt/local/etc? /opt/local/share/caps-log?).

[NikolaDucak]

Apparently ~/.caps-log/config.ini is not created automatically, so nothing there (I assumed that installing and running a binary should create some basic sane settings, if those are needed).

No settings are required, so no config file is created. What made me think that you have something set there is the "pulling from remote" message on startup, that shouldn't happen unless you configured it manually.

Turns out there is an issue where event if the remote repo is not configured, the app still uses the uninitialized memory of it :/ , I've opened a pr that should fix it.

P. S. On a side note, would you like to be a port [co]maintainer?

Sure!

I think it is better to have either a configurable folder for having this file or let the binary check for several reasonable locations. Because we will not want to install anything directly into a home folder, but rather use /opt/local/something (/opt/local/etc? /opt/local/share/caps-log?).

Since installing into a home folder is not needed that this would not be an issue I assume?

[NikolaDucak]

P. S. On a side note, would you like to be a port [co]maintainer?
Sure!

Note that I have next to none experience with MacPorts, tho

[NikolaDucak]

Let me know if this fixes the issue on your end as well then I'll close the issue

[barracuda156]

@NikolaDucak Okay, great. I will rebuild from the new commit now. Hopefully it works fine then.

Could you make a new release then? MacPorts generally dislikes commit-based ports, unless those are -devel, and otherwise we need to have multiple patches on top of 1.0.0.

[barracuda156]

Aside of issue with finding Boost, looks like it is now working:

Older macOS will need to use a custom Terminal, apparently. In default system one no colors are displayed for some reason.

[NikolaDucak]

I've added a new release (1.0.1), that should do it

Older macOS will need to use a custom Terminal, apparently. In default system one no colors are displayed for some reason.

I guess so, probably the old terminal emulator does not support colors

[barracuda156]

I guess so, probably the old terminal emulator does not support colors

It does not support true colors, but it does support some limited colors, and it works with git-tui, for example, which also uses FTXUI library.

I've added a new release (1.0.1), that should do it

Awesome, I will update the port then.

UPD: macports/macports-ports#24371

[NikolaDucak]

It does not support true colors, but it does support some limited colors, and it works with git-tui, for example, which also uses FTXUI library.

interesting, I'll look into that