Seg Fault on note create or list

[kmluce]

🐛 Describe the bug

I attempted to install and use lst, but it seg faults immediately on the -l or -a options. I've reproduced this on a mac running Catalina and one running Mojave, and when installed via brew and when installed via downloaded package.

⚠️ Current behavior

$ lst
Liszt is an open-source note-taking software designed for personal use.

If you need help in general, type 'lst -help' or 'lst -h'
If you need help with a specific command, type 'lst -h <name_of_command>', such as for help with adding memories ('lst -h -') or removing a note ('lst -h -rm')
To view your version of Liszt, type 'lst -version' or 'lst -v'

Liszt uses the GNU General Public License v3, so you can edit, distribute, and otherwise meddle with any of the source code.
The only thing you can't do is take this software and make it closed-source and try to sell it. Liszt was designed to be free for everyone, forever.

Checkout Transcendental Etudes by Franz Liszt!
$ lst -l
Segmentation fault: 11
$ lst -a
lst error: command '-a' not recognized. Please try again.
(hint: did you include the necessary arguments for this command? Run 'lst -h' to find out)
$ lst -a foo
Segmentation fault: 11

$ lldb lst -- -a foo
(lldb) target create "lst"
Current executable set to 'lst' (x86_64).
(lldb) settings set -- target.run-args "-a" "foo"
(lldb) r
Process 76140 launched: '/usr/local/bin/lst' (x86_64)
Process 76140 stopped

• thread Documentation Lacking #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  frame #0: 0x00007fff6e1bee52 libsystem_platform.dylib_platform_strlen + 18 libsystem_platform.dylib_platform_strlen:
  -> 0x7fff6e1bee52 <+18>: pcmpeqb (%rdi), %xmm0
  0x7fff6e1bee56 <+22>: pmovmskb %xmm0, %esi
  0x7fff6e1bee5a <+26>: andq $0xf, %rcx
  0x7fff6e1bee5e <+30>: orq $-0x1, %rax
  Target 0: (lst) stopped.

✅ Expected behavior

I expected when I run lst -l, it will show an empty list of notes. And then when I run lst -a foo, it will add a note called foo.

💣 Steps to reproduce

$ brew tap liszt-music/liszt
$ brew install lst
$ lst -a

or alternatively:
select pkg file in github, download pkg, open pkg
$ /Library/Liszt/1.1.8/lst -a foo

📷 Screenshots

📱 Tech info

Darwin kathleen 19.6.0 Darwin Kernel Version 19.6.0: Thu Jun 18 20:49:00 PDT 2020; root:xnu-6153.141.1~1/RELEASE_X86_64 x86_64

and

$ uname -a
Darwin mudita 18.7.0 Darwin Kernel Version 18.7.0: Thu Jun 18 20:50:10 PDT 2020; root:xnu-4903.278.43~1/RELEASE_X86_64 x86_64

[scamacho23]

Thanks, @kmluce! I'll look into what the issue is and get back to you as soon as I figure out what might be causing the segfault.

[amildahl]

Was looking into this for Hacktoberfest and discovered it's been fixed in code (for fresh installs at least -- upgraded installs without data_file will still crash), but the version installed by brew still has the issue.

The issue is that at some point the data_file changed from ~/.liszt/background/data_file.json -- installing from brew gets you a version that creates the data file as ~/.liszt/background/data_file.json but lst is looking for ~/.liszt/background/data_file and tries to read from it before checking if the file exists.

If desired, I could add a check that creates the file if it doesn't exist, but either way it looks like the version being installed through brew needs to be updated. I've never worked with brew packaging, so not sure if that's something I can create a PR for or not 😅

From brew:

> lst -v
Liszt v1.1.7

From local build:

> lst -v
Liszt v1.1.8

[amildahl]

Digging a bit more, it looks like your v1.1.8 tag on this repo happened before a lot of the package information was changed, so that's why -v is reporting v1.1.7

As well, it looks like this commit: 2f54514 is where this bug was likely fixed (didn't dig too far, but it looks like that's where data_file.json was dropped)

[amildahl]

@scamacho23 I opened #59 which should make the upgrade path for Mac users better. Feel free to close it if you don't like the approach, but I hope it helps 😃

As outlined above, either way you'll likely want to push a new tag for v1.1.9 and update your brew tap to include all the fixes. (I'd be happy to work on PRs for that if you'd like -- just let me know!)

[scamacho23]

@amildahl Ah thanks so much. Haven't had the opportunity to work much on this recently so appreciate the suggestions!

[amildahl]

@scamacho23 You're welcome! I'll take a look through the rest of the issues on the project and see if there's anything else I can help out with. And of course let me know if you think of anything 😄

Also, I did just notice your repo isn't participating in Hacktoberfest. If you wouldn't mind adding the hacktoberfest-accepted label to my PR or adding the hacktoberfest topic to your repository, that'd be really appreciated 😄 If not, no worries!