~rjarry/aerc#5: 
notmuch: reto's fork and segmentation faults

Back when we were using the upstream https://github.com/zenhack/go.notmuch, the backend would frequently segfault and crash aerc. Reto ripped out a lot of memory-related code in his fork, which fixed the problem. However, I'm not sure what the deal was - we can't be the only ones using the library and coming across the issue.

This ticket is to keep in mind that we should explore this issue in more detail, and see whether we need to continue using a fork, or we're doing something else wrong and can go back to using upstream (preferable).

Status
REPORTED
Submitter
~coder_kalyan
Assigned to
No-one
Submitted
10 months ago
Updated
11 days ago
Labels
bug notmuch

~rockorager 2 months ago

Can anyone confirm if the notmuch backend crashes? I haven’t experienced it, and since we’re back to using zenhack, I wonder if we need this ticket anymore

~rockorager 2 months ago*

Can anyone confirm if the notmuch backend crashes? I haven’t experienced it, and since we’re back to using zenhack, I wonder if we need this ticket anymore.

EDIT: I just saw the replace directive in go.mod, we are still using the fork.

~ferdinandyb 11 days ago*

Not explicitly related, but since the discussion also includes which library to even use I thought it fits here.

What I'm experiencing is that we're using deprecated calls:

❯ GOFLAGS=-tags=notmuch make
go build -trimpath -tags=notmuch -ldflags "-X main.Version=0.12.0-35-gddca71bcfd41 -X main.Flags=LS0gLXRhZ3M9bm90bXVjaAo= -X git.sr.ht/~rjarry/aerc/config.shareDir=/usr/local/share/aerc" -o aerc
# github.com/zenhack/go.notmuch
cgo-gcc-prolog: In function ‘_cgo_c02956f23830_Cfunc_notmuch_database_open’:
cgo-gcc-prolog:347:2: warning: ‘notmuch_database_open’ is deprecated: function deprecated as of libnotmuch 5.4 [-Wdeprecated-declarations]
In file included from ../../../go/pkg/mod/github.com/brunnre8/go.notmuch@v0.0.0-20201126061756-caa2daf7093c/db.go:9:
/usr/local/include/notmuch.h:336:1: note: declared here
  336 | notmuch_database_open (const char *path,
      | ^~~~~~~~~~~~~~~~~~~~~

although it seems if I switch to zenhack it also has this issue. Currently, it's just irritating, but sooner or later it's going to be more than that. Is this zenhack the official go binding?

Register here or Log in to comment, or comment via email.