Re: neomutt segmentation fault

2021-10-18 Thread Bjorn Ketelaars 
On Mon 18/10/2021 23:48, Theo Buehler wrote:
> +Cc maintainer
> 
> On Mon, Oct 18, 2021 at 09:07:07PM +, James Cook wrote:
> > I don't know if this is related to the other recent neomutt segfault
> > thread.
> 
> Unlikely.
> 
> > falsifian moth ~ $ pkg_info neomutt
> > Information for inst:neomutt-20211015
> 
> So it seems you're running -current, right?
> 
> > Thread 1 received signal SIGSEGV, Segmentation fault.
> > _libc_freeaddrinfo (ai=0x0) at /usr/src/lib/libc/net/freeaddrinfo.c:46
> > 46  free(p->ai_canonname);
> > (gdb) bt
> > #0  _libc_freeaddrinfo (ai=0x0) at /usr/src/lib/libc/net/freeaddrinfo.c:46
> > #1  0x079ac809e2b6 in getdnsdomainname ()
> 
> freeaddrinfo(3) is not NULL safe.
> 
> > falsifian moth ~ $ dmesg|head -n1
> > OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT 2021
> > 
> > falsifian moth ~ $ uname -a
> > OpenBSD moth.falsifian.org 7.0 GENERIC.MP#43 amd64
> 
> These two kernel lines don't match and don't immediately tell me if
> you're on release or -current. 'sysctl kern.version' is better.

I'm reading your mail just after committing a similar diff:

I sent this diff yesterday afternoon, offlist, to sthen@ who Ok'ed it. I
did not commit earlier because of other things. However, I did manage to
open a PR upstream [0].

Hope I did not ruin your plans?

https://github.com/neomutt/neomutt/pull/3077

Re: neomutt segmentation fault

2021-10-18 Thread James Cook 
> > falsifian moth ~ $ pkg_info neomutt
> > Information for inst:neomutt-20211015
> 
> So it seems you're running -current, right?

Yes.

> > falsifian moth ~ $ dmesg|head -n1
> > OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT 2021
> > 
> > falsifian moth ~ $ uname -a
> > OpenBSD moth.falsifian.org 7.0 GENERIC.MP#43 amd64
> 
> These two kernel lines don't match and don't immediately tell me if
> you're on release or -current. 'sysctl kern.version' is better.

Sorry, the dmesg line must have been preserved from a previous boot.

falsifian moth ~ $ sysctl kern.version
kern.version=OpenBSD 7.0-current (GENERIC.MP) #43: Mon Oct 18 07:58:26 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

> The diff below should fix your problem. Could you check, please?

Yes, that fixes it, thanks. Using it now.

-- 
James

Re: neomutt segmentation fault

2021-10-18 Thread Theo Buehler 
+Cc maintainer

On Mon, Oct 18, 2021 at 09:07:07PM +, James Cook wrote:
> I don't know if this is related to the other recent neomutt segfault
> thread.

Unlikely.

> falsifian moth ~ $ pkg_info neomutt
> Information for inst:neomutt-20211015

So it seems you're running -current, right?

> Thread 1 received signal SIGSEGV, Segmentation fault.
> _libc_freeaddrinfo (ai=0x0) at /usr/src/lib/libc/net/freeaddrinfo.c:46
> 46  free(p->ai_canonname);
> (gdb) bt
> #0  _libc_freeaddrinfo (ai=0x0) at /usr/src/lib/libc/net/freeaddrinfo.c:46
> #1  0x079ac809e2b6 in getdnsdomainname ()

freeaddrinfo(3) is not NULL safe.

> falsifian moth ~ $ dmesg|head -n1
> OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT 2021
> 
> falsifian moth ~ $ uname -a
> OpenBSD moth.falsifian.org 7.0 GENERIC.MP#43 amd64

These two kernel lines don't match and don't immediately tell me if
you're on release or -current. 'sysctl kern.version' is better.

The diff below should fix your problem. Could you check, please?

Index: Makefile
===
RCS file: /cvs/ports/mail/neomutt/Makefile,v
retrieving revision 1.67
diff -u -p -r1.67 Makefile
--- Makefile15 Oct 2021 11:09:00 -  1.67
+++ Makefile18 Oct 2021 21:15:46 -
@@ -5,6 +5,7 @@ COMMENT=tty-based e-mail client, Mutt w
 GH_ACCOUNT=neomutt
 GH_PROJECT=neomutt
 GH_TAGNAME=20211015
+REVISION=  0
 
 CATEGORIES=mail
 HOMEPAGE=  https://neomutt.org/
Index: patches/patch-conn_getdomain_c
===
RCS file: patches/patch-conn_getdomain_c
diff -N patches/patch-conn_getdomain_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-conn_getdomain_c  18 Oct 2021 21:15:34 -
@@ -0,0 +1,15 @@
+$OpenBSD$
+
+Index: conn/getdomain.c
+--- conn/getdomain.c.orig
 conn/getdomain.c
+@@ -149,7 +149,8 @@ int getdnsdomainname(struct Buffer *result)
+ rc = 0;
+ mutt_debug(LL_DEBUG1, "Hostname: %s\n", mutt_buffer_string(result));
+   }
+-  freeaddrinfo(lookup_result);
++  if (lookup_result)
++freeaddrinfo(lookup_result);
+ #endif
+ 
+   return rc;

Re: neomutt segmentation fault

2021-10-18 Thread Jon Fineman 
Under 6.9 I had submitted several seq fault traces and had even more 
not submitted. I was experiencing a fault once a day at least.


Stuart provided a patch under 6.9 that greatly reduced the dumps. I 
had I think two with the patch.


With the new version of neomutt (20210205) using 7.0 release I have 
had it up since 15 Oct and I have not had one dump.


With your release I guess you upgraded to snapshots?


On Mon, Oct 18, 2021 at 09:07:07PM +, James Cook wrote:

I don't know if this is related to the other recent neomutt segfault
thread.

After sysupgrade -s and pkg_add -u, neomutt crashes immediately when I
start it. Is anyone else seeing this? Details below. I took filesystem
backups before upgrading, so I can probably figure out the exact
(working) neomutt version I had before if that's useful.

I guess my next step will be to see whether it's related to my
some particular part of my .neomuttrc.

falsifian moth ~ $ pkg_info neomutt
Information for inst:neomutt-20211015

...

falsifian moth ~ $ egdb neomutt
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from neomutt...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/local/bin/neomutt
[New process 13376]

Thread 1 received signal SIGSEGV, Segmentation fault.
_libc_freeaddrinfo (ai=0x0) at /usr/src/lib/libc/net/freeaddrinfo.c:46
46  free(p->ai_canonname);
(gdb) bt
#0  _libc_freeaddrinfo (ai=0x0) at /usr/src/lib/libc/net/freeaddrinfo.c:46
#1  0x079ac809e2b6 in getdnsdomainname ()
#2  0x079ac800ee1f in mutt_init ()
#3  0x079ac80171f4 in main ()
(gdb)

falsifian moth ~ $ dmesg|head -n1
OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT 2021

falsifian moth ~ $ uname -a
OpenBSD moth.falsifian.org 7.0 GENERIC.MP#43 amd64

Let me know if more details would be useful.

--
James



--

Re: neomutt segmentation fault

2021-10-10 Thread Jon Fineman 



On Thu, Oct 07, 2021 at 01:31:29PM +0100, Stuart Henderson wrote:

On 2021/10/06 21:14, Jon Fineman wrote:

Not sure I built this correctly. I applied the patch, ran make in
./mail/neomutt under my userid, then with doas after pkg_add issued errors.
I did not run make install.

Is it valid to run neomutt out of the pobj directory? While it launched and
I was able to interact with it I did get the below errors about my config
file. The new neomutt is built without notmuch support, which I use.


you can use FLAVOR=notmuch make [...]


> desktop(/usr/ports/pobj/neomutt-20211004/build-amd64)$: ./neomutt
> Error in /home/.config/neomutt/muttrc, line 9: nm_default_url: unknown
> variable
> Error in /home/.config/neomutt/muttrc, line 10: nm_query_type: unknown
> variable
> Error in /home/.config/neomutt/muttrc, line 11: Function
> 'vfolder-from-query' not available for menu 'index'
> Error in /home/.config/neomutt/muttrc, line 12: nm_db_limit: unknown
> variable
> Error in /home/.config/neomutt/maildir-muttrc, line 18:
> virtual-mailboxes: unknown command
> Error in /home/.config/neomutt/maildir-muttrc, line 24:
> virtual-mailboxes: unknown command
> Error in /home/.config/neomutt/maildir-muttrc, line 28:
> virtual-mailboxes: unknown command
> Error in /home/.config/neomutt/muttrc, line 190: source: file
> /home/.config/neomutt/maildir-muttrc could not be sourced
> source: errors in /home/.config/neomutt/muttrc
> Press any key to continue...


those are all notmuch-related



Also another dataum. I realized I often run neomutt and emacs/notmuch at the
same time. While I don't have a great recollection of the timing I am
starting to wonder if that is causing a conflict. The last day or so I have
not used emacs/notmuch and neomutt has been fine.

Jon


On Tue, Oct 05, 2021 at 08:43:38AM +0100, Stuart Henderson wrote:
> On 2021/10/04 19:47, Stuart Henderson wrote:
> > On 2021/10/04 09:22, Jon Fineman wrote:
> > > I had been using it about 5 minutes and just entered a few commands.
> > > Hopefully one of these will help. dmesg follows. It is rather random with
> > > staying up days to just a few minutes.
> >
> > It probably needs reporting upstream, but there's a new release of
> > neomutt due this week so it would be better to test with that first, in
> > case the poblems you're running into have been fixed already.
> >
>
>
> Not the released version yet but you can try this:
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/neomutt/Makefile,v
> retrieving revision 1.66
> diff -u -p -r1.66 Makefile
> --- Makefile   5 Feb 2021 13:18:19 -   1.66
> +++ Makefile   5 Oct 2021 07:42:41 -
> @@ -4,7 +4,9 @@ COMMENT=   tty-based e-mail client, Mutt w
>
> GH_ACCOUNT=neomutt
> GH_PROJECT=neomutt
> -GH_TAGNAME=   20210205
> +#GH_TAGNAME=  20210205
> +GH_COMMIT=a1660b20c3792075281d58ba1f902acfe1db0880
> +DISTNAME= neomutt-20211004
>
> CATEGORIES=mail
> HOMEPAGE=  https://neomutt.org/
> Index: distinfo
> ===
> RCS file: /cvs/ports/mail/neomutt/distinfo,v
> retrieving revision 1.41
> diff -u -p -r1.41 distinfo
> --- distinfo   5 Feb 2021 13:18:19 -   1.41
> +++ distinfo   5 Oct 2021 07:42:41 -
> @@ -1,2 +1,2 @@
> -SHA256 (neomutt-20210205.tar.gz) = 
d+F3eA/C2Ku0ddnKxDQsfmHVPCQ/bOL5vIbYGfyWLNs=
> -SIZE (neomutt-20210205.tar.gz) = 3476980
> +SHA256 (neomutt-20211004-a1660b20.tar.gz) = 
Xl5IibCPVrlq30lx0L81C9YBQ+C++H6CgZcT7e/7Evk=
> +SIZE (neomutt-20211004-a1660b20.tar.gz) = 3726113
> Index: patches/patch-auto_def
> ===
> RCS file: /cvs/ports/mail/neomutt/patches/patch-auto_def,v
> retrieving revision 1.13
> diff -u -p -r1.13 patch-auto_def
> --- patches/patch-auto_def 5 Feb 2021 13:18:19 -   1.13
> +++ patches/patch-auto_def 5 Oct 2021 07:42:41 -
> @@ -3,7 +3,7 @@ $OpenBSD: patch-auto_def,v 1.13 2021/02/
> Index: auto.def
> --- auto.def.orig
> +++ auto.def
> -@@ -555,6 +555,7 @@ if {[get-define want-sasl]} {
> +@@ -579,6 +579,7 @@ if {[get-define want-sasl]} {
>  define USE_SASL
>  define-feature SASL
>} else {
> @@ -11,7 +11,7 @@ Index: auto.def
>  foreach sasl_lib {sasl2 sasl} {
>if {[check-inc-and-lib sasl [opt-val with-sasl $prefix] \
>   sasl/sasl.h sasl_encode64 $sasl_lib]} {
> -@@ -564,6 +565,7 @@ if {[get-define want-sasl]} {
> +@@ -588,6 +589,7 @@ if {[get-define want-sasl]} {
>  break
>}
>  }
> @@ -19,7 +19,7 @@ Index: auto.def
>  if {![get-define USE_SASL]} {
>user-error "Unable to find SASL"
>  }
> -@@ -1289,13 +1291,6 @@ set bare_rep {
> +@@ -1311,13 +1313,6 @@ set bare_rep {
>  }
>  set str_rep {
>PACKAGE_VERSION
> Index: patches/patch-nntp_newsrc_c
> ===
> RCS file:

Re: neomutt segmentation fault

2021-10-07 Thread Stuart Henderson 
On 2021/10/06 21:14, Jon Fineman wrote:
> Not sure I built this correctly. I applied the patch, ran make in
> ./mail/neomutt under my userid, then with doas after pkg_add issued errors.
> I did not run make install.
> 
> Is it valid to run neomutt out of the pobj directory? While it launched and
> I was able to interact with it I did get the below errors about my config
> file. The new neomutt is built without notmuch support, which I use.

you can use FLAVOR=notmuch make [...]

> > desktop(/usr/ports/pobj/neomutt-20211004/build-amd64)$: ./neomutt
> > Error in /home/.config/neomutt/muttrc, line 9: nm_default_url: unknown
> > variable
> > Error in /home/.config/neomutt/muttrc, line 10: nm_query_type: unknown
> > variable
> > Error in /home/.config/neomutt/muttrc, line 11: Function
> > 'vfolder-from-query' not available for menu 'index'
> > Error in /home/.config/neomutt/muttrc, line 12: nm_db_limit: unknown
> > variable
> > Error in /home/.config/neomutt/maildir-muttrc, line 18:
> > virtual-mailboxes: unknown command
> > Error in /home/.config/neomutt/maildir-muttrc, line 24:
> > virtual-mailboxes: unknown command
> > Error in /home/.config/neomutt/maildir-muttrc, line 28:
> > virtual-mailboxes: unknown command
> > Error in /home/.config/neomutt/muttrc, line 190: source: file
> > /home/.config/neomutt/maildir-muttrc could not be sourced
> > source: errors in /home/.config/neomutt/muttrc
> > Press any key to continue...

those are all notmuch-related

> 
> Also another dataum. I realized I often run neomutt and emacs/notmuch at the
> same time. While I don't have a great recollection of the timing I am
> starting to wonder if that is causing a conflict. The last day or so I have
> not used emacs/notmuch and neomutt has been fine.
> 
> Jon
> 
> 
> On Tue, Oct 05, 2021 at 08:43:38AM +0100, Stuart Henderson wrote:
> > On 2021/10/04 19:47, Stuart Henderson wrote:
> > > On 2021/10/04 09:22, Jon Fineman wrote:
> > > > I had been using it about 5 minutes and just entered a few commands.
> > > > Hopefully one of these will help. dmesg follows. It is rather random 
> > > > with
> > > > staying up days to just a few minutes.
> > > 
> > > It probably needs reporting upstream, but there's a new release of
> > > neomutt due this week so it would be better to test with that first, in
> > > case the poblems you're running into have been fixed already.
> > > 
> > 
> > 
> > Not the released version yet but you can try this:
> > 
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/mail/neomutt/Makefile,v
> > retrieving revision 1.66
> > diff -u -p -r1.66 Makefile
> > --- Makefile5 Feb 2021 13:18:19 -   1.66
> > +++ Makefile5 Oct 2021 07:42:41 -
> > @@ -4,7 +4,9 @@ COMMENT=tty-based e-mail client, Mutt w
> > 
> > GH_ACCOUNT= neomutt
> > GH_PROJECT= neomutt
> > -GH_TAGNAME=20210205
> > +#GH_TAGNAME=   20210205
> > +GH_COMMIT= a1660b20c3792075281d58ba1f902acfe1db0880
> > +DISTNAME=  neomutt-20211004
> > 
> > CATEGORIES= mail
> > HOMEPAGE=   https://neomutt.org/
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/mail/neomutt/distinfo,v
> > retrieving revision 1.41
> > diff -u -p -r1.41 distinfo
> > --- distinfo5 Feb 2021 13:18:19 -   1.41
> > +++ distinfo5 Oct 2021 07:42:41 -
> > @@ -1,2 +1,2 @@
> > -SHA256 (neomutt-20210205.tar.gz) = 
> > d+F3eA/C2Ku0ddnKxDQsfmHVPCQ/bOL5vIbYGfyWLNs=
> > -SIZE (neomutt-20210205.tar.gz) = 3476980
> > +SHA256 (neomutt-20211004-a1660b20.tar.gz) = 
> > Xl5IibCPVrlq30lx0L81C9YBQ+C++H6CgZcT7e/7Evk=
> > +SIZE (neomutt-20211004-a1660b20.tar.gz) = 3726113
> > Index: patches/patch-auto_def
> > ===
> > RCS file: /cvs/ports/mail/neomutt/patches/patch-auto_def,v
> > retrieving revision 1.13
> > diff -u -p -r1.13 patch-auto_def
> > --- patches/patch-auto_def  5 Feb 2021 13:18:19 -   1.13
> > +++ patches/patch-auto_def  5 Oct 2021 07:42:41 -
> > @@ -3,7 +3,7 @@ $OpenBSD: patch-auto_def,v 1.13 2021/02/
> > Index: auto.def
> > --- auto.def.orig
> > +++ auto.def
> > -@@ -555,6 +555,7 @@ if {[get-define want-sasl]} {
> > +@@ -579,6 +579,7 @@ if {[get-define want-sasl]} {
> >  define USE_SASL
> >  define-feature SASL
> >} else {
> > @@ -11,7 +11,7 @@ Index: auto.def
> >  foreach sasl_lib {sasl2 sasl} {
> >if {[check-inc-and-lib sasl [opt-val with-sasl $prefix] \
> >   sasl/sasl.h sasl_encode64 $sasl_lib]} {
> > -@@ -564,6 +565,7 @@ if {[get-define want-sasl]} {
> > +@@ -588,6 +589,7 @@ if {[get-define want-sasl]} {
> >  break
> >}
> >  }
> > @@ -19,7 +19,7 @@ Index: auto.def
> >  if {![get-define USE_SASL]} {
> >user-error "Unable to find SASL"
> >  }
> > -@@ -1289,13 +1291,6 @@ set bare_rep {
> > +@@ -1311,13 +1313,6 @@ set bare_rep {
> >  }
> >  set

Re: neomutt segmentation fault

2021-10-07 Thread Jon Fineman 



On Wed, Oct 06, 2021 at 09:14:47PM -0400, Jon Fineman wrote:
Not sure I built this correctly. I applied the patch, ran make in 
./mail/neomutt under my userid, then with doas after pkg_add issued 
errors. I did not run make install.


Is it valid to run neomutt out of the pobj directory? While it 
launched and I was able to interact with it I did get the below 
errors about my config file. The new neomutt is built without 
notmuch support, which I use.


desktop(/usr/ports/pobj/neomutt-20211004/build-amd64)$: ./neomutt   
Error in /home/.config/neomutt/muttrc, line 9: nm_default_url: 
unknown variable
Error in /home/.config/neomutt/muttrc, line 10: nm_query_type: 
unknown variable
Error in /home/.config/neomutt/muttrc, line 11: Function 
'vfolder-from-query' not available for menu 'index'
Error in /home/.config/neomutt/muttrc, line 12: nm_db_limit: 
unknown variable
Error in /home/.config/neomutt/maildir-muttrc, line 18: 
virtual-mailboxes: unknown command
Error in /home/.config/neomutt/maildir-muttrc, line 24: 
virtual-mailboxes: unknown command
Error in /home/.config/neomutt/maildir-muttrc, line 28: 
virtual-mailboxes: unknown command
Error in /home/.config/neomutt/muttrc, line 190: source: file 
/home/.config/neomutt/maildir-muttrc could not be sourced

source: errors in /home/.config/neomutt/muttrc
Press any key to continue...


Also another dataum. I realized I often run neomutt and 
emacs/notmuch at the same time. While I don't have a great 
recollection of the timing I am starting to wonder if that is 
causing a conflict. The last day or so I have not used emacs/notmuch 
and neomutt has been fine.


Jon


On Tue, Oct 05, 2021 at 08:43:38AM +0100, Stuart Henderson wrote:

On 2021/10/04 19:47, Stuart Henderson wrote:

On 2021/10/04 09:22, Jon Fineman wrote:

I had been using it about 5 minutes and just entered a few commands.
Hopefully one of these will help. dmesg follows. It is rather random with
staying up days to just a few minutes.


It probably needs reporting upstream, but there's a new release of
neomutt due this week so it would be better to test with that first, in
case the poblems you're running into have been fixed already.




Not the released version yet but you can try this:

Index: Makefile
===
RCS file: /cvs/ports/mail/neomutt/Makefile,v
retrieving revision 1.66
diff -u -p -r1.66 Makefile
--- Makefile5 Feb 2021 13:18:19 -   1.66
+++ Makefile5 Oct 2021 07:42:41 -
@@ -4,7 +4,9 @@ COMMENT=tty-based e-mail client, Mutt w

GH_ACCOUNT= neomutt
GH_PROJECT= neomutt
-GH_TAGNAME=20210205
+#GH_TAGNAME=   20210205
+GH_COMMIT= a1660b20c3792075281d58ba1f902acfe1db0880
+DISTNAME=  neomutt-20211004

CATEGORIES= mail
HOMEPAGE=   https://neomutt.org/
Index: distinfo
===
RCS file: /cvs/ports/mail/neomutt/distinfo,v
retrieving revision 1.41
diff -u -p -r1.41 distinfo
--- distinfo5 Feb 2021 13:18:19 -   1.41
+++ distinfo5 Oct 2021 07:42:41 -
@@ -1,2 +1,2 @@
-SHA256 (neomutt-20210205.tar.gz) = d+F3eA/C2Ku0ddnKxDQsfmHVPCQ/bOL5vIbYGfyWLNs=
-SIZE (neomutt-20210205.tar.gz) = 3476980
+SHA256 (neomutt-20211004-a1660b20.tar.gz) = 
Xl5IibCPVrlq30lx0L81C9YBQ+C++H6CgZcT7e/7Evk=
+SIZE (neomutt-20211004-a1660b20.tar.gz) = 3726113
Index: patches/patch-auto_def
===
RCS file: /cvs/ports/mail/neomutt/patches/patch-auto_def,v
retrieving revision 1.13
diff -u -p -r1.13 patch-auto_def
--- patches/patch-auto_def  5 Feb 2021 13:18:19 -   1.13
+++ patches/patch-auto_def  5 Oct 2021 07:42:41 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-auto_def,v 1.13 2021/02/
Index: auto.def
--- auto.def.orig
+++ auto.def
-@@ -555,6 +555,7 @@ if {[get-define want-sasl]} {
+@@ -579,6 +579,7 @@ if {[get-define want-sasl]} {
define USE_SASL
define-feature SASL
  } else {
@@ -11,7 +11,7 @@ Index: auto.def
foreach sasl_lib {sasl2 sasl} {
  if {[check-inc-and-lib sasl [opt-val with-sasl $prefix] \
 sasl/sasl.h sasl_encode64 $sasl_lib]} {
-@@ -564,6 +565,7 @@ if {[get-define want-sasl]} {
+@@ -588,6 +589,7 @@ if {[get-define want-sasl]} {
break
  }
}
@@ -19,7 +19,7 @@ Index: auto.def
if {![get-define USE_SASL]} {
  user-error "Unable to find SASL"
}
-@@ -1289,13 +1291,6 @@ set bare_rep {
+@@ -1311,13 +1313,6 @@ set bare_rep {
}
set str_rep {
  PACKAGE_VERSION
Index: patches/patch-nntp_newsrc_c
===
RCS file: /cvs/ports/mail/neomutt/patches/patch-nntp_newsrc_c,v
retrieving revision 1.5
diff -u -p -r1.5 patch-nntp_newsrc_c
--- patches/patch-nntp_newsrc_c 1 Sep 2020 10:50:55 -   1.5
+++ patches/patch-nntp_newsrc_c 5 Oct 2021 07:42:41 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-nntp_newsrc_c,v 1.5 2020
Index: nntp/newsrc.c
--- nntp/newsrc.c.orig

Re: neomutt segmentation fault

2021-10-06 Thread Jon Fineman 
Not sure I built this correctly. I applied the patch, ran make in 
./mail/neomutt under my userid, then with doas after pkg_add issued 
errors. I did not run make install.


Is it valid to run neomutt out of the pobj directory? While it 
launched and I was able to interact with it I did get the below errors 
about my config file. The new neomutt is built without notmuch 
support, which I use.


desktop(/usr/ports/pobj/neomutt-20211004/build-amd64)$: ./neomutt   
Error in /home/.config/neomutt/muttrc, line 9: nm_default_url: 
unknown variable
Error in /home/.config/neomutt/muttrc, line 10: nm_query_type: 
unknown variable
Error in /home/.config/neomutt/muttrc, line 11: Function 
'vfolder-from-query' not available for menu 'index'
Error in /home/.config/neomutt/muttrc, line 12: nm_db_limit: 
unknown variable
Error in /home/.config/neomutt/maildir-muttrc, line 18: 
virtual-mailboxes: unknown command
Error in /home/.config/neomutt/maildir-muttrc, line 24: 
virtual-mailboxes: unknown command
Error in /home/.config/neomutt/maildir-muttrc, line 28: 
virtual-mailboxes: unknown command
Error in /home/.config/neomutt/muttrc, line 190: source: file 
/home/.config/neomutt/maildir-muttrc could not be sourced

source: errors in /home/.config/neomutt/muttrc
Press any key to continue...


Also another dataum. I realized I often run neomutt and emacs/notmuch 
at the same time. While I don't have a great recollection of the 
timing I am starting to wonder if that is causing a conflict. The last 
day or so I have not used emacs/notmuch and neomutt has been fine.


Jon


On Tue, Oct 05, 2021 at 08:43:38AM +0100, Stuart Henderson wrote:

On 2021/10/04 19:47, Stuart Henderson wrote:

On 2021/10/04 09:22, Jon Fineman wrote:
> I had been using it about 5 minutes and just entered a few commands.
> Hopefully one of these will help. dmesg follows. It is rather random with
> staying up days to just a few minutes.

It probably needs reporting upstream, but there's a new release of
neomutt due this week so it would be better to test with that first, in
case the poblems you're running into have been fixed already.




Not the released version yet but you can try this:

Index: Makefile
===
RCS file: /cvs/ports/mail/neomutt/Makefile,v
retrieving revision 1.66
diff -u -p -r1.66 Makefile
--- Makefile5 Feb 2021 13:18:19 -   1.66
+++ Makefile5 Oct 2021 07:42:41 -
@@ -4,7 +4,9 @@ COMMENT=tty-based e-mail client, Mutt w

GH_ACCOUNT= neomutt
GH_PROJECT= neomutt
-GH_TAGNAME=20210205
+#GH_TAGNAME=   20210205
+GH_COMMIT= a1660b20c3792075281d58ba1f902acfe1db0880
+DISTNAME=  neomutt-20211004

CATEGORIES= mail
HOMEPAGE=   https://neomutt.org/
Index: distinfo
===
RCS file: /cvs/ports/mail/neomutt/distinfo,v
retrieving revision 1.41
diff -u -p -r1.41 distinfo
--- distinfo5 Feb 2021 13:18:19 -   1.41
+++ distinfo5 Oct 2021 07:42:41 -
@@ -1,2 +1,2 @@
-SHA256 (neomutt-20210205.tar.gz) = d+F3eA/C2Ku0ddnKxDQsfmHVPCQ/bOL5vIbYGfyWLNs=
-SIZE (neomutt-20210205.tar.gz) = 3476980
+SHA256 (neomutt-20211004-a1660b20.tar.gz) = 
Xl5IibCPVrlq30lx0L81C9YBQ+C++H6CgZcT7e/7Evk=
+SIZE (neomutt-20211004-a1660b20.tar.gz) = 3726113
Index: patches/patch-auto_def
===
RCS file: /cvs/ports/mail/neomutt/patches/patch-auto_def,v
retrieving revision 1.13
diff -u -p -r1.13 patch-auto_def
--- patches/patch-auto_def  5 Feb 2021 13:18:19 -   1.13
+++ patches/patch-auto_def  5 Oct 2021 07:42:41 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-auto_def,v 1.13 2021/02/
Index: auto.def
--- auto.def.orig
+++ auto.def
-@@ -555,6 +555,7 @@ if {[get-define want-sasl]} {
+@@ -579,6 +579,7 @@ if {[get-define want-sasl]} {
 define USE_SASL
 define-feature SASL
   } else {
@@ -11,7 +11,7 @@ Index: auto.def
 foreach sasl_lib {sasl2 sasl} {
   if {[check-inc-and-lib sasl [opt-val with-sasl $prefix] \
  sasl/sasl.h sasl_encode64 $sasl_lib]} {
-@@ -564,6 +565,7 @@ if {[get-define want-sasl]} {
+@@ -588,6 +589,7 @@ if {[get-define want-sasl]} {
 break
   }
 }
@@ -19,7 +19,7 @@ Index: auto.def
 if {![get-define USE_SASL]} {
   user-error "Unable to find SASL"
 }
-@@ -1289,13 +1291,6 @@ set bare_rep {
+@@ -1311,13 +1313,6 @@ set bare_rep {
 }
 set str_rep {
   PACKAGE_VERSION
Index: patches/patch-nntp_newsrc_c
===
RCS file: /cvs/ports/mail/neomutt/patches/patch-nntp_newsrc_c,v
retrieving revision 1.5
diff -u -p -r1.5 patch-nntp_newsrc_c
--- patches/patch-nntp_newsrc_c 1 Sep 2020 10:50:55 -   1.5
+++ patches/patch-nntp_newsrc_c 5 Oct 2021 07:42:41 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-nntp_newsrc_c,v 1.5 2020
Index: nntp/newsrc.c
--- nntp/newsrc.c.orig
+++ nntp/newsrc.c
-@@ -623,7 +623,7 @@ static

Re: neomutt segmentation fault

2021-10-05 Thread Stuart Henderson 
On 2021/10/04 19:47, Stuart Henderson wrote:
> On 2021/10/04 09:22, Jon Fineman wrote:
> > I had been using it about 5 minutes and just entered a few commands.
> > Hopefully one of these will help. dmesg follows. It is rather random with
> > staying up days to just a few minutes.
> 
> It probably needs reporting upstream, but there's a new release of
> neomutt due this week so it would be better to test with that first, in
> case the poblems you're running into have been fixed already.
> 


Not the released version yet but you can try this:

Index: Makefile
===
RCS file: /cvs/ports/mail/neomutt/Makefile,v
retrieving revision 1.66
diff -u -p -r1.66 Makefile
--- Makefile5 Feb 2021 13:18:19 -   1.66
+++ Makefile5 Oct 2021 07:42:41 -
@@ -4,7 +4,9 @@ COMMENT=tty-based e-mail client, Mutt w
 
 GH_ACCOUNT=neomutt
 GH_PROJECT=neomutt
-GH_TAGNAME=20210205
+#GH_TAGNAME=   20210205
+GH_COMMIT= a1660b20c3792075281d58ba1f902acfe1db0880
+DISTNAME=  neomutt-20211004
 
 CATEGORIES=mail
 HOMEPAGE=  https://neomutt.org/
Index: distinfo
===
RCS file: /cvs/ports/mail/neomutt/distinfo,v
retrieving revision 1.41
diff -u -p -r1.41 distinfo
--- distinfo5 Feb 2021 13:18:19 -   1.41
+++ distinfo5 Oct 2021 07:42:41 -
@@ -1,2 +1,2 @@
-SHA256 (neomutt-20210205.tar.gz) = d+F3eA/C2Ku0ddnKxDQsfmHVPCQ/bOL5vIbYGfyWLNs=
-SIZE (neomutt-20210205.tar.gz) = 3476980
+SHA256 (neomutt-20211004-a1660b20.tar.gz) = 
Xl5IibCPVrlq30lx0L81C9YBQ+C++H6CgZcT7e/7Evk=
+SIZE (neomutt-20211004-a1660b20.tar.gz) = 3726113
Index: patches/patch-auto_def
===
RCS file: /cvs/ports/mail/neomutt/patches/patch-auto_def,v
retrieving revision 1.13
diff -u -p -r1.13 patch-auto_def
--- patches/patch-auto_def  5 Feb 2021 13:18:19 -   1.13
+++ patches/patch-auto_def  5 Oct 2021 07:42:41 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-auto_def,v 1.13 2021/02/
 Index: auto.def
 --- auto.def.orig
 +++ auto.def
-@@ -555,6 +555,7 @@ if {[get-define want-sasl]} {
+@@ -579,6 +579,7 @@ if {[get-define want-sasl]} {
  define USE_SASL
  define-feature SASL
} else {
@@ -11,7 +11,7 @@ Index: auto.def
  foreach sasl_lib {sasl2 sasl} {
if {[check-inc-and-lib sasl [opt-val with-sasl $prefix] \
   sasl/sasl.h sasl_encode64 $sasl_lib]} {
-@@ -564,6 +565,7 @@ if {[get-define want-sasl]} {
+@@ -588,6 +589,7 @@ if {[get-define want-sasl]} {
  break
}
  }
@@ -19,7 +19,7 @@ Index: auto.def
  if {![get-define USE_SASL]} {
user-error "Unable to find SASL"
  }
-@@ -1289,13 +1291,6 @@ set bare_rep {
+@@ -1311,13 +1313,6 @@ set bare_rep {
  }
  set str_rep {
PACKAGE_VERSION
Index: patches/patch-nntp_newsrc_c
===
RCS file: /cvs/ports/mail/neomutt/patches/patch-nntp_newsrc_c,v
retrieving revision 1.5
diff -u -p -r1.5 patch-nntp_newsrc_c
--- patches/patch-nntp_newsrc_c 1 Sep 2020 10:50:55 -   1.5
+++ patches/patch-nntp_newsrc_c 5 Oct 2021 07:42:41 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-nntp_newsrc_c,v 1.5 2020
 Index: nntp/newsrc.c
 --- nntp/newsrc.c.orig
 +++ nntp/newsrc.c
-@@ -623,7 +623,7 @@ static int active_get_cache(struct NntpAccountData *ad
+@@ -625,7 +625,7 @@ static int active_get_cache(struct NntpAccountData *ad
if (!fp)
  return -1;
  
Index: pkg/PLIST
===
RCS file: /cvs/ports/mail/neomutt/pkg/PLIST,v
retrieving revision 1.16
diff -u -p -r1.16 PLIST
--- pkg/PLIST   20 Nov 2020 17:17:21 -  1.16
+++ pkg/PLIST   5 Oct 2021 07:42:41 -
@@ -60,6 +60,9 @@ share/doc/neomutt/mime.types
 @sample ${SYSCONFDIR}/mime.types
 share/doc/neomutt/mimesupport.html
 share/doc/neomutt/miscellany.html
+share/doc/neomutt/oauth2/
+share/doc/neomutt/oauth2/mutt_oauth2.py
+share/doc/neomutt/oauth2/mutt_oauth2.py.README
 share/doc/neomutt/optionalfeatures.html
 share/doc/neomutt/reference.html
 share/doc/neomutt/samples/
@@ -110,11 +113,15 @@ share/locale/ko/LC_MESSAGES/neomutt.mo
 share/locale/lt/
 share/locale/lt/LC_MESSAGES/
 share/locale/lt/LC_MESSAGES/neomutt.mo
+share/locale/nb_NO/
+share/locale/nb_NO/LC_MESSAGES/
+share/locale/nb_NO/LC_MESSAGES/neomutt.mo
 share/locale/nl/LC_MESSAGES/neomutt.mo
 share/locale/pl/LC_MESSAGES/neomutt.mo
 share/locale/pt_BR/LC_MESSAGES/neomutt.mo
 share/locale/ru/LC_MESSAGES/neomutt.mo
 share/locale/sk/LC_MESSAGES/neomutt.mo
+share/locale/sr/LC_MESSAGES/neomutt.mo
 share/locale/sv/LC_MESSAGES/neomutt.mo
 share/locale/tr/LC_MESSAGES/neomutt.mo
 share/locale/uk/LC_MESSAGES/neomutt.mo

Re: neomutt segmentation fault

2021-10-04 Thread Stuart Henderson 
On 2021/10/04 09:22, Jon Fineman wrote:
> I had been using it about 5 minutes and just entered a few commands.
> Hopefully one of these will help. dmesg follows. It is rather random with
> staying up days to just a few minutes.

It probably needs reporting upstream, but there's a new release of
neomutt due this week so it would be better to test with that first, in
case the poblems you're running into have been fixed already.

Re: neomutt Segmentation fault (core dumped)

2021-07-10 Thread Jon Fineman 



egdb neomutt neomutt_20210710.core 
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.9".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from neomutt...Reading symbols from 
/usr/local/bin/.debug/neomutt.dbg...done.
done.
[New process 113151]
Core was generated by `neomutt'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  mutt_addrlist_clear (al=0x840c03c7600) at 
../neomutt-20210205/address/address.c:1476
1476../neomutt-20210205/address/address.c: No such file or directory.
(gdb) bt
#0  mutt_addrlist_clear (al=0x840c03c7600) at 
../neomutt-20210205/address/address.c:1476
#1  0x083e1373d056 in mutt_env_free (ptr=0x841060433a0)
at ../neomutt-20210205/email/envelope.c:103
#2  0x083e1373c65c in mutt_body_free (ptr=0x84090cf3e78)
at ../neomutt-20210205/email/body.c:94
#3  0x083e1373c669 in mutt_body_free (ptr=0x8405bac8850)
at ../neomutt-20210205/email/body.c:95
#4  0x083e1373c96a in email_free (ptr=0x840f296c800)
at ../neomutt-20210205/email/email.c:54
#5  0x083e1366f792 in update_tables (ctx=)
at ../neomutt-20210205/context.c:288
#6  ctx_mailbox_observer (nc=) at 
../neomutt-20210205/context.c:316
#7  0x083e137546c8 in send (source=0x840a3d65a40, current=0x840a3d65a40, 
event_type=NT_MAILBOX, event_subtype=8, event_data=0x7f7c36a0)
at ../neomutt-20210205/mutt/notify.c:122
#8  0x083e13733fd2 in mailbox_changed (m=, action=3205699744)
at ../neomutt-20210205/core/mailbox.c:190
#9  0x083e136a6825 in mx_mbox_sync (m=0x840ccae9a00) at 
../neomutt-20210205/mx.c:1057
#10 0x083e136873e2 in mutt_index_menu (dlg=0x84106042b00)
at ../neomutt-20210205/index.c:2061
#11 0x083e13694799 in main (argc=, argv=, 
envp=) at ../neomutt-20210205/main.c:1238
(gdb) 



- Original message -
From: Stuart Henderson 
To: Jon Fineman 
Cc: ports@openbsd.org
Subject: Re: neomutt Segmentation fault (core dumped)
Date: Saturday, July 10, 2021 7:08 AM

On 2021/07/10 06:44, Jon Fineman wrote:
> It had been running for several days. Ran the '$' command to purge messages 
> marked for deletion. I have the debug package installed, not sure why I am 
> not getting more info from egdb.
> 
> 
> desktop(~)$: egdb debug-neomutt-20210205-notmuch neomutt.core

That should just be "egdb neomutt neomutt.core", hopefully that will give
more information. It will quite likely need to go upstream, but let's
see how the backtrace looks with that.

> debug-neomutt-20210205-notmuch: No such file or directory.
> [New process 113151]
> Core was generated by `neomutt'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x083e13746300 in ?? ()
> (gdb) bt
> #0  0x083e13746300 in ?? ()
> #1  0xdfdfdfdfdfdfdfdf in ?? ()

0xdfdf[...] is a pattern used by OpenBSD malloc when freeing
allocations so this strongly suggests a use-after-free.

> #2  0x in ?? ()
> (gdb) 
> 
> 
> 
> 
> OpenBSD 6.9 (GENERIC.MP) #3: Mon Jun  7 08:21:26 MDT 2021
> 
> r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 17047867392 (16258MB)
> avail mem = 16515813376 (15750MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x8b1d7000 (57 entries)
> bios0: vendor Intel Corp. version "SYSKLi35.86A.0042.2016.0409.1246" date 
> 04/09/2016
> bios0: Intel corporation NUC6i5SYB
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET LPIT SSDT SSDT SSDT SSDT 
> DBGP DBG2 SSDT SSDT UEFI SSDT BGRT DMAR
> acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) 
> SIO1(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) 
> PXSX(S4) RP13(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.65 MHz, 06-4e-03
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,

Re: neomutt Segmentation fault (core dumped)

2021-07-10 Thread Stuart Henderson 
On 2021/07/10 06:44, Jon Fineman wrote:
> It had been running for several days. Ran the '$' command to purge messages 
> marked for deletion. I have the debug package installed, not sure why I am 
> not getting more info from egdb.
> 
> 
> desktop(~)$: egdb debug-neomutt-20210205-notmuch neomutt.core

That should just be "egdb neomutt neomutt.core", hopefully that will give
more information. It will quite likely need to go upstream, but let's
see how the backtrace looks with that.

> debug-neomutt-20210205-notmuch: No such file or directory.
> [New process 113151]
> Core was generated by `neomutt'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x083e13746300 in ?? ()
> (gdb) bt
> #0  0x083e13746300 in ?? ()
> #1  0xdfdfdfdfdfdfdfdf in ?? ()

0xdfdf[...] is a pattern used by OpenBSD malloc when freeing
allocations so this strongly suggests a use-after-free.

> #2  0x in ?? ()
> (gdb) 
> 
> 
> 
> 
> OpenBSD 6.9 (GENERIC.MP) #3: Mon Jun  7 08:21:26 MDT 2021
> 
> r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 17047867392 (16258MB)
> avail mem = 16515813376 (15750MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x8b1d7000 (57 entries)
> bios0: vendor Intel Corp. version "SYSKLi35.86A.0042.2016.0409.1246" date 
> 04/09/2016
> bios0: Intel corporation NUC6i5SYB
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET LPIT SSDT SSDT SSDT SSDT 
> DBGP DBG2 SSDT SSDT UEFI SSDT BGRT DMAR
> acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) 
> SIO1(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) 
> PXSX(S4) RP13(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.65 MHz, 06-4e-03
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 24MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.06 MHz, 06-4e-03
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 1 (application processor)
> cpu2: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.05 MHz, 06-4e-03
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 1, core 0, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.05 MHz, 06-4e-03
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 1, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0,

Re: neomutt-20200501: not an update patch

2020-05-05 Thread Stuart Henderson 
On 2020/05/05 20:13, Groot wrote:
> I understand openbsd is near release and this is
> not an attempt to send an update patch. I was facing
> bug #2145 and it is fixed in the newest release. To 
> test it I simply changed 'GH_TAGNAME=20200501'. Build 
> and the fake installation was successfully and there
> were no changes (aside from COPYRIGHT.md file) in the 
> PLIST. 
> 
> 'env FLAVOR=sasl make package'
> (env FLAVOR=sasl was used for all intermediate commands)
> gives following error
> 
> '/usr/portsdir/pobj/neomutt-20200501-sasl/fake-amd64-sasl/.fake_done' is up
> to date.
> ===>  Building package for neomutt-20200501-sasl
> Create /usr/portsdir/packages/amd64/all/neomutt-20200501-sasl.tgz
> Creating package neomutt-20200501-sasl
> Creating package debug-neomutt-20200501-sasl
> checking dependencies|mail/neomutt,sasl
> Error: Dependency neomutt-20200501-sasl doesn't match FULLPKGNAME:
> neomutt-20200320-sasl
> checksumming...
> pkg_create: can't continue
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2113
> '/usr/portsdir/packages/amd64/all/neomutt-20200501-sasl.tgz': @trap "cd
> /usr...)
> *** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2594
> '_internal-package': @case X${_DEPENDS_CACHE} in  X)
> _DEPENDS_CACHE=$(sudo -...)
> *** Error 2 in /usr/ports/mystuff/mail/neomutt
> (/usr/ports/infrastructure/mk/bsd.port.mk:2573 'package':
> @lock=neomutt-20200501-sasl;  expor...)
> ttps://man.openbsd.org/pkg_add.1#snap
> 
> I don't understand how the ports system knows the name of the old
> release? (Check FULLPKGNAME above) I never built neomutt through ports.  
> I checked all the files in 'mail/neomutt' there is no mention of it. 
> I got rid of the currently installed version 'neomutt-2020320-sasl' 
> (even though I didn't think it would make a difference) and tried again 
> same error occurs. Help me out?

You are working in /usr/ports/mystuff but probably still have the
original version in /usr/ports.

Either set PORTSDIR_PATH (see bsd.port.mk(5)) to put mystuff before
/usr/ports, or just modify directly in /usr/ports/mail/neomutt
(if you do that and want to reset to the original version from cvs
you can use "cvs up -C").

Re: neomutt-20200313-gpgme-sasl error sending from command line

2020-03-18 Thread Tom Wong-Cornall 
On Thu, Mar 19 '20 at 08.14 NZDT, myportslist20190...@nym.hush.com wrote:
> Synopsis: neomutt-20200313-gpgme-sasl error sending command line email

Looks like it's a known bug, see 
https://github.com/neomutt/neomutt/issues/2176 (caused by commit 331702b 
with comment "abort if run without a terminal" heh; quality control not 
quite as good as mainline mutt yet).

Fixed a couple of days ago but not included in a release yet.

Re: neomutt-20191025p0 dumps core on alias -group command

2019-11-02 Thread Klemens Nanni 
On Sat, Nov 02, 2019 at 06:33:15PM +, Stuart Henderson wrote:
> https://github.com/neomutt/neomutt/issues/1882
Thanks, I'll just wait for today's release to come around then.

Re: neomutt-20191025p0 dumps core on alias -group command

2019-11-02 Thread Stuart Henderson 

https://github.com/neomutt/neomutt/issues/1882
--
Sent from a phone, apologies for poor formatting.

On 2 November 2019 15:38:14 Klemens Nanni  wrote:


Latest neomutt dumps core when assigning aliases to groups;  this is
independent of the user configuration:

$ sysctl -n kern.version
OpenBSD 6.6-current (GENERIC.MP) #424: Fri Nov  1 14:12:12 MDT 2019
   dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

$ cd /usr/ports/mail/neomutt
$ make show=FULLPKGNAME
mutt-20191025p0
$ make DEBUG='-g3 -O0'

$ $(make show=WRKBUILD)/neomutt -e 'alias -group foo bar baz' -F /dev/null 
-A foo

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.6"...
Core was generated by `neomutt'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.26.1...done.
Loaded symbols for /usr/lib/libpthread.so.26.1
Loaded symbols for /usr/ports/pobj/neomutt-20191025/build-amd64/neomutt
Reading symbols from /usr/local/lib/libkyotocabinet.so.0.0...done.
Loaded symbols for /usr/local/lib/libkyotocabinet.so.0.0
Reading symbols from /usr/local/lib/libidn2.so.1.0...done.
Loaded symbols for /usr/local/lib/libidn2.so.1.0
Reading symbols from /usr/lib/libz.so.5.0...done.
Loaded symbols for /usr/lib/libz.so.5.0
Reading symbols from /usr/lib/libssl.so.48.0...done.
Loaded symbols for /usr/lib/libssl.so.48.0
Reading symbols from /usr/lib/libcrypto.so.46.0...done.
Loaded symbols for /usr/lib/libcrypto.so.46.0
Reading symbols from /usr/lib/libcurses.so.14.0...done.
Loaded symbols for /usr/lib/libcurses.so.14.0
Reading symbols from /usr/local/lib/libintl.so.6.0...done.
Loaded symbols for /usr/local/lib/libintl.so.6.0
Reading symbols from /usr/local/lib/libiconv.so.7.0...done.
Loaded symbols for /usr/local/lib/libiconv.so.7.0
Reading symbols from /usr/lib/libc.so.96.0...done.
Loaded symbols for /usr/lib/libc.so.96.0
Reading symbols from /usr/lib/libc++.so.3.0...done.
Loaded symbols for /usr/lib/libc++.so.3.0
Reading symbols from /usr/lib/libc++abi.so.1.0...done.
Loaded symbols for /usr/lib/libc++abi.so.1.0
Symbols already loaded for /usr/lib/libpthread.so.26.1
Reading symbols from /usr/lib/libm.so.10.1...done.
Loaded symbols for /usr/lib/libm.so.10.1
Reading symbols from /usr/local/lib/libunistring.so.0.1...done.
Loaded symbols for /usr/local/lib/libunistring.so.0.1
Reading symbols from /usr/libexec/ld.so...Error while reading shared 
library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) 
[in module /usr/libexec/ld.so]
#0  0x0399634b199a in mutt_addrlist_append (al=0x39bf3219f00, 
a=0x39bdaa9a040) at ../neomutt-2019-10-25/address/address.c:1404

1404TAILQ_INSERT_TAIL(al, a, entries);
(gdb) bt
#0  0x0399634b199a in mutt_addrlist_append (al=0x39bf3219f00, 
a=0x39bdaa9a040) at ../neomutt-2019-10-25/address/address.c:1404
#1  0x0399634b493c in group_add_addrlist (g=0x39bf3219f00, 
al=0x39c1f7280c8) at ../neomutt-2019-10-25/address/group.c:189
#2  0x0399634b4846 in mutt_grouplist_add_addrlist (gl=0x7f7c94b8, 
al=0x39c1f7280c8) at ../neomutt-2019-10-25/address/group.c:233
#3  0x0399633c1b17 in parse_alias (buf=0x39c5dc38300, s=0x7f7c9558, 
data=0, err=0x39c5dc383e0) at ../neomutt-2019-10-25/init.c:953
#4  0x0399633c9738 in mutt_parse_rc_line (line=0x39be46adfe0 "alias 
-group foo bar baz", token=0x39c5dc38300, err=0x39c5dc383e0) at 
../neomutt-2019-10-25/init.c:3257
#5  0x0399633c90e7 in execute_commands (p=0x7f7cb440) at 
../neomutt-2019-10-25/init.c:291
#6  0x0399633c838f in mutt_init (skip_sys_rc=false, 
commands=0x7f7cb440) at ../neomutt-2019-10-25/init.c:3170
#7  0x0399633d303c in main (argc=1, argv=0x7f7cb538, 
envp=0x7f7cb578) at ../neomutt-2019-10-25/main.c:726

Current language:  auto; currently minimal
(gdb)

Re: neomutt

2016-10-18 Thread Peter Hessler 
On 2016 Oct 18 (Tue) at 11:16:35 +0100 (+0100), Stuart Henderson wrote:
:(My original plan was to replace mutt completely

MASSIVE NAK on that, please.

Re: neomutt

2016-10-18 Thread Stefan Sperling 
On Tue, Oct 18, 2016 at 11:16:35AM +0100, Stuart Henderson wrote:
> Here's a newer one which has fixed a crash which I was able to trigger
> which I think may be the one you saw too.
> 
> At this point I would like to import it as a separate port alongside mutt.
> Any OKs for that?
> 
> (My original plan was to replace mutt completely, but at this point I think
> it's better to have a clean mutt-1.7.1 without the big array of patch options
> to allow it to be updated sanely, and a separate clean neomutt).

OK to import this version. I agree with this approach.

If this still crashes people can fall back to the old mutt port
or help fixing up neomutt if they really need all the patches.

Thanks!

Re: neomutt

2016-10-18 Thread Stuart Henderson 
On 2016/10/17 13:11, Stefan Sperling wrote:
> On Sun, Oct 16, 2016 at 11:23:28PM +0200, Stefan Sperling wrote:
> > On Mon, Sep 26, 2016 at 01:07:30PM +0100, Stuart Henderson wrote:
> > > People who were seeing crashes with neomutt, please test this, and get
> > > me backtraces if you still see them (the port Makefile here is setup to
> > > build with symbols so you don't need to set DEBUG in this case).
> > > 
> > 
> > I've been running this with no issues.
> 
> Ugh. Apparently, I spoke too soon.

Here's a newer one which has fixed a crash which I was able to trigger
which I think may be the one you saw too.

At this point I would like to import it as a separate port alongside mutt.
Any OKs for that?

(My original plan was to replace mutt completely, but at this point I think
it's better to have a clean mutt-1.7.1 without the big array of patch options
to allow it to be updated sanely, and a separate clean neomutt).



neomutt.tgz
Description: application/tar-gz

Re: neomutt

2016-10-17 Thread Stefan Sperling 
On Sun, Oct 16, 2016 at 11:23:28PM +0200, Stefan Sperling wrote:
> On Mon, Sep 26, 2016 at 01:07:30PM +0100, Stuart Henderson wrote:
> > People who were seeing crashes with neomutt, please test this, and get
> > me backtraces if you still see them (the port Makefile here is setup to
> > build with symbols so you don't need to set DEBUG in this case).
> > 
> 
> I've been running this with no issues.

Ugh. Apparently, I spoke too soon.

GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.0"...
Core was generated by `mutt'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.23.0...done.
Loaded symbols for /usr/lib/libpthread.so.23.0
Loaded symbols for /usr/local/bin/mutt
Reading symbols from /usr/lib/libncurses.so.14.0...done.
Loaded symbols for /usr/lib/libncurses.so.14.0
Reading symbols from /usr/lib/libssl.so.39.1...done.
Loaded symbols for /usr/lib/libssl.so.39.1
Reading symbols from /usr/lib/libcrypto.so.38.1...done.
Loaded symbols for /usr/lib/libcrypto.so.38.1
Reading symbols from /usr/lib/libz.so.5.0...done.
Loaded symbols for /usr/lib/libz.so.5.0
Reading symbols from /usr/local/lib/libkyotocabinet.so.0.0...done.
Loaded symbols for /usr/local/lib/libkyotocabinet.so.0.0
Reading symbols from /usr/local/lib/libidn.so.17.2...done.
Loaded symbols for /usr/local/lib/libidn.so.17.2
Reading symbols from /usr/local/lib/libintl.so.6.0...done.
Loaded symbols for /usr/local/lib/libintl.so.6.0
Reading symbols from /usr/local/lib/libiconv.so.6.0...done.
Loaded symbols for /usr/local/lib/libiconv.so.6.0
Reading symbols from /usr/lib/libc.so.89.2...done.
Loaded symbols for /usr/lib/libc.so.89.2
Symbols already loaded for /usr/lib/libpthread.so.23.0
Reading symbols from /usr/lib/libstdc++.so.57.0...done.
Loaded symbols for /usr/lib/libstdc++.so.57.0
Reading symbols from /usr/lib/libm.so.10.0...done.
Loaded symbols for /usr/lib/libm.so.10.0
Reading symbols from /usr/libexec/ld.so...done.
oaded symbols for /usr/libexec/ld.so
#0  0x09f79e71bde2 in index_color (index_no=0) at curs_main.c:269
269   HEADER *h = Context->hdrs[Context->v2r[index_no]];
(gdb) bt
#0  0x09f79e71bde2 in index_color (index_no=0) at curs_main.c:269
#1  0x09f79e7409ac in menu_redraw_index (menu=0x9fa696e0800) at menu.c:324
#2  0x09f79e74d97c in mutt_pager (banner=0x0, fname=Variable "fname" is not 
available.
) at pager.c:1857
#3  0x09f79e7122e9 in mutt_display_message (cur=0x9fa696e0200) at 
commands.c:225
#4  0x09f79e71dc4d in mutt_index_menu () at curs_main.c:1911
#5  0x09f79e73c973 in main (argc=1, argv=0x7f7f9b38) at main.c:906
(gdb) p Context
$1 = (CONTEXT *) 0x0
(gdb)

Re: neomutt

2016-10-16 Thread Stefan Sperling 
On Mon, Sep 26, 2016 at 01:07:30PM +0100, Stuart Henderson wrote:
> People who were seeing crashes with neomutt, please test this, and get
> me backtraces if you still see them (the port Makefile here is setup to
> build with symbols so you don't need to set DEBUG in this case).
> 

I've been running this with no issues.