4 of 108 tests failed testing nmh

Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

4 of 108 tests failed testing nmh

Chris Richmond
4 of 108 tests failed testing nmh

All,

  Not sure what you need to know, but this is on a current Devuan 2.0.0 install.  This is what failed:

PASS: test/comp/test-comp-format

Segmentation fault

FAIL: test/dist/test-dist

PASS: test/folder/test-coverage

PASS: test/slocal/test-slocal

Segmentation fault

*** /home/crichmon/Downloads/nmh/test/testdir/2675.expectederr  Wed Nov  6 07:17:39 2019

--- /home/crichmon/Downloads/nmh/test/testdir/2675.actualerr    Wed Nov  6 07:17:39 2019

***************

*** 0 ****

--- 1,4 ----

+ Segmentation fault

+ Segmentation fault

+ Segmentation fault

+ Segmentation fault

./test/whatnow/test-attach-detach: test failed, outputs are in /home/crichmon/Downloads/nmh/test/testdir/2675.expectederr and /home/crichmon/Downloads/nmh/test/testdir/2675.actualerr.

FAIL: test/whatnow/test-attach-detach

Segmentation fault

*** /home/crichmon/Downloads/nmh/test/testdir/2720.expectederr  Wed Nov  6 07:17:39 2019

--- /home/crichmon/Downloads/nmh/test/testdir/2720.actualerr    Wed Nov  6 07:17:39 2019

***************

*** 0 ****

--- 1 ----

+ Segmentation fault

./test/whatnow/test-cd: test failed, outputs are in /home/crichmon/Downloads/nmh/test/testdir/2720.expectederr and /home/crichmon/Downloads/nmh/test/testdir/2720.actualerr.

FAIL: test/whatnow/test-cd

Segmentation fault

*** /home/crichmon/Downloads/nmh/test/testdir/2756.expectederr  Wed Nov  6 07:17:39 2019

--- /home/crichmon/Downloads/nmh/test/testdir/2756.actualerr    Wed Nov  6 07:17:39 2019

***************

*** 0 ****

--- 1 ----

+ Segmentation fault

./test/whatnow/test-ls: test failed, outputs are in /home/crichmon/Downloads/nmh/test/testdir/2756.expectederr and /home/crichmon/Downloads/nmh/test/testdir/2756.actualerr.

FAIL: test/whatnow/test-ls

PASS: test/whom/test-whom

PASS: test/cleanup

=======================================

4 of 108 tests failed

(7 tests were not run)

Please report to [hidden email]

=======================================

Makefile:4869: recipe for target 'check-TESTS' failed

make[1]: *** [check-TESTS] Error 1

make[1]: Leaving directory '/home/crichmon/Downloads/nmh'

Makefile:5125: recipe for target 'check-am' failed

make: *** [check-am] Error 2


Reply | Threaded
Open this post in threaded view
|

Re: 4 of 108 tests failed testing nmh

Valdis Klētnieks
On Wed, 06 Nov 2019 19:56:45 -0800, "Chris Richmond" said:

>   Not sure what you need to know, but this is on a current Devuan 2.0.0
> install.  This is what failed:

That's unusual behavior.  Can you tell us where you got the source tree,'
and what release of gcc you're using?

4 of 108 tests failed
(7 tests were not run)

Might be interesting to figure out which 7 weren't run - on my Fedora laptop,
all 115 tests run cleanly using gcc 9.2.1.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 4 of 108 tests failed testing nmh

Ken Hornstein-2
In reply to this post by Chris Richmond
>  Not sure what you need to know, but this is on a current Devuan 2.0.0
>install.  This is what failed:
>
>PASS: test/comp/test-comp-format
>Segmentation fault
>FAIL: test/dist/test-dist

Huh, I am a little suprised that this failed in so many places; I'm willing
to believe we got something wrong, but I guess I thought this would
have shown up before now.

But ... as to solving this problem ...

First, compile with debugging turned on (CFLAGS=-g and LDFLAGS=-g to
configure).  Be sure you do a "make clean" so you can make sure
everything is built with debugging symbols.

You can run a single test by running:

% make check TESTS="test/dist/test-dist test/cleanup"

The "cleanup" test removes the test working directory, so if you want
to see what is left over then you can omit that.  Since you are getting
segfaults, it might be easiest to turn on core dumps (using something
like "unlimit coredumpsize" or "ulimit coredumpsize", depending on
your shell), run the test to get a core dump, and then running the
debugger on that.  I can give you more information as to how to do
that if you are unfamiliar with that (forgive me for presuming that
you don't know how to do that already; it's very possible you know
this already!).  Once we figure out what is going wrong, we can work
on fixing it.

--Ken

Reply | Threaded
Open this post in threaded view
|

RE: 4 of 108 tests failed testing nmh

Chris Richmond
Hi, and thanks a bunch for being responsive!  No offence on assumptions
about what I know.
Part of my day job is supporting end customers of our code.  :^)

In any case;

devuan is a debian fork without systemd, and relative to me other box
(Centos 6), modern.  I've got
a few RPi's I can try this on if needed.

The source tree is the official one or very close (git clone maybe).

router1_/home/crichmon/Downloads/nmh> gcc --version
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516

The skipped tests are 1/7 because valgrind isn't installed.  The other 6 are
because oauth isn't enabled.
Neither for any particular reason.

I've rebuilt and generated a core file.  That's about where I get lost with
what to do with it.
This is the result of trying:
> make check TESTS="test/dist/test-dist"
> gdb core
....
Type "apropos word" to search for commands related to "word"...
"/home/crichmon/Downloads/nmh/core": not in executable format: File format
not recognized
(gdb) q

router1_/home/crichmon/Downloads/nmh> d core
-rw------- 1 crichmon users 667648 Nov  7 15:54 core
router1_/home/crichmon/Downloads/nmh> file core
core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from
'dist -noedit -to [hidden email]', real uid: 1000, effective uid:
1000, real gid: 1000, effective gid: 1000, execfn:
'/home/crichmon/Downloads/nmh/test/testdir/inst/usr/local/bin/dist',
platform: 'x86_64'

Making the core executable didn't help (same msg).

Thx, Chris

-----Original Message-----
From: Ken Hornstein <[hidden email]>
Sent: Thursday, November 7, 2019 8:59 AM
To: Chris Richmond <[hidden email]>
Cc: [hidden email]
Subject: Re: 4 of 108 tests failed testing nmh

>  Not sure what you need to know, but this is on a current Devuan 2.0.0
>install.  This is what failed:
>
>PASS: test/comp/test-comp-format
>Segmentation fault
>FAIL: test/dist/test-dist

Huh, I am a little suprised that this failed in so many places; I'm willing
to believe we got something wrong, but I guess I thought this would have
shown up before now.

But ... as to solving this problem ...

First, compile with debugging turned on (CFLAGS=-g and LDFLAGS=-g to
configure).  Be sure you do a "make clean" so you can make sure everything
is built with debugging symbols.

You can run a single test by running:

% make check TESTS="test/dist/test-dist test/cleanup"

The "cleanup" test removes the test working directory, so if you want to see
what is left over then you can omit that.  Since you are getting segfaults,
it might be easiest to turn on core dumps (using something like "unlimit
coredumpsize" or "ulimit coredumpsize", depending on your shell), run the
test to get a core dump, and then running the debugger on that.  I can give
you more information as to how to do that if you are unfamiliar with that
(forgive me for presuming that you don't know how to do that already; it's
very possible you know this already!).  Once we figure out what is going
wrong, we can work on fixing it.

--Ken


Reply | Threaded
Open this post in threaded view
|

Re: 4 of 108 tests failed testing nmh

Ken Hornstein-2
>> gdb core
>....
>Type "apropos word" to search for commands related to "word"...
>"/home/crichmon/Downloads/nmh/core": not in executable format: File format
>not recognized

Ah, okay, we're very close.

You need to run gdb on the executable AND the core file.  Given the
above information, it's probably something like:

% gdb /home/crichmon/Downloads/nmh/test/testdir/inst/usr/local/bin/dist core

Or if that complains about no symbols being loaded, maybe:

% gdb uip/dist core

At the gdb prompt you can get a backtrace with the "bt" command and that
should show us the complete stack trace and where things are going wrong.

--Ken

Reply | Threaded
Open this post in threaded view
|

RE: 4 of 108 tests failed testing nmh

Chris Richmond
The stack is pretty short...

Reading symbols from test/testdir/inst/usr/local/bin/dist...done.
[New LWP 16558]
Core was generated by `dist -noedit -to [hidden email]'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000559ecc4d1816 in WhatNow (argc=1, argv=0x7ffebd4a6980) at
uip/whatnowsbr.c:263
263             switch (smatch (*argp, aleqs)) {
(gdb) bt
#0  0x0000559ecc4d1816 in WhatNow (argc=1, argv=0x7ffebd4a6980) at
uip/whatnowsbr.c:263
#1  0x0000559ecc4d1241 in what_now (ed=0x0, nedit=1, use=0,
file=0x7ffebd4aa9d0 "/home/crichmon/Downloads/nmh/test/testdir/Mail/draft",
altmsg=0x559ecde18100 "1",
    dist=1, mp=0x559ecde17590, text=0x0, inplace=1, cwd=0x559ecde17520
"/home/crichmon/Downloads/nmh", atfile=0) at uip/whatnowproc.c:122
#2  0x0000559ecc4d0cce in main (argc=4, argv=0x7ffebd4aeb78) at
uip/dist.c:354

Thx, Chris

-----Original Message-----
From: Ken Hornstein <[hidden email]>
Sent: Thursday, November 7, 2019 4:13 PM
To: Chris Richmond <[hidden email]>
Cc: [hidden email]
Subject: Re: 4 of 108 tests failed testing nmh

>> gdb core
>....
>Type "apropos word" to search for commands related to "word"...
>"/home/crichmon/Downloads/nmh/core": not in executable format: File
>format not recognized

Ah, okay, we're very close.

You need to run gdb on the executable AND the core file.  Given the above
information, it's probably something like:

% gdb /home/crichmon/Downloads/nmh/test/testdir/inst/usr/local/bin/dist core

Or if that complains about no symbols being loaded, maybe:

% gdb uip/dist core

At the gdb prompt you can get a backtrace with the "bt" command and that
should show us the complete stack trace and where things are going wrong.

--Ken


Reply | Threaded
Open this post in threaded view
|

Re: 4 of 108 tests failed testing nmh

Ken Hornstein-2
>263             switch (smatch (*argp, aleqs)) {

Huh, I wasn't expecting that.  Was this built with or without readline
support?  What happens if you say "print argp" at the (gdb) prompt?

--Ken

Reply | Threaded
Open this post in threaded view
|

Re: 4 of 108 tests failed testing nmh

Ken Hornstein-2
>>263             switch (smatch (*argp, aleqs)) {
>
>Huh, I wasn't expecting that.  Was this built with or without readline
>support?  What happens if you say "print argp" at the (gdb) prompt?

I was able to answer my own question ... it is NOT built with readline
support, is it?  I am able to reproduce this when I disable readline
support.  So clearly there's a bug in the non-readline code.  It is
late tonight, so I will look at it tomorow or the weekend, but a simple
fix for right now would be to install a readline package and re-run
configure.

--Ken

Reply | Threaded
Open this post in threaded view
|

Re: 4 of 108 tests failed testing nmh

Ken Hornstein-2
>I was able to answer my own question ... it is NOT built with readline
>support, is it?  I am able to reproduce this when I disable readline
>support.  So clearly there's a bug in the non-readline code.  It is
>late tonight, so I will look at it tomorow or the weekend, but a simple
>fix for right now would be to install a readline package and re-run
>configure.

ANOTHER follow-up ... that bug is not present in 1.7.1.  I would advise
you use that.

--Ken

Reply | Threaded
Open this post in threaded view
|

Re: 4 of 108 tests failed testing nmh

David Levine-3
Ken writes:

> ANOTHER follow-up ... that bug is not present in 1.7.1.  I would advise
> you use that.

Confirmed.  There is a compile warning due to not including a correct
header without READLINE_SUPPORT, I just fixed that.

nmh 1.7.1 is available at
http://download.savannah.nongnu.org/releases/nmh/nmh-1.7.1.tar.gz

"mhpath -version" will show the nmh version.

David

Reply | Threaded
Open this post in threaded view
|

RE: 4 of 108 tests failed testing nmh

Chris Richmond
In reply to this post by Ken Hornstein-2
Found the source:  git clone git://git.savannah.nongnu.org/nmh.git
The version is nmh> cat VERSION
1.7+dev

I'll try the 1.7.1 version in the morning.

Thx, Chris

-----Original Message-----
From: Ken Hornstein <[hidden email]>
Sent: Thursday, November 7, 2019 6:37 PM
To: Chris Richmond <[hidden email]>; [hidden email]
Subject: Re: 4 of 108 tests failed testing nmh

>I was able to answer my own question ... it is NOT built with readline
>support, is it?  I am able to reproduce this when I disable readline
>support.  So clearly there's a bug in the non-readline code.  It is
>late tonight, so I will look at it tomorow or the weekend, but a simple
>fix for right now would be to install a readline package and re-run
>configure.

ANOTHER follow-up ... that bug is not present in 1.7.1.  I would advise you
use that.

--Ken


Reply | Threaded
Open this post in threaded view
|

RE: 4 of 108 tests failed testing nmh

Chris Richmond
In reply to this post by David Levine-3
As expected.  The skipped tests are for valgrind and oauth.

======================
All 105 tests passed
(7 tests were not run)
======================
make[1]: Leaving directory '/home/crichmon/Downloads/nmh-1.7.1'

Thanks a bunch!

Chris

-----Original Message-----
From: David Levine <[hidden email]>
Sent: Thursday, November 7, 2019 6:57 PM
To: Chris Richmond <[hidden email]>
Cc: [hidden email]
Subject: Re: 4 of 108 tests failed testing nmh

Ken writes:

> ANOTHER follow-up ... that bug is not present in 1.7.1.  I would
> advise you use that.

Confirmed.  There is a compile warning due to not including a correct header without READLINE_SUPPORT, I just fixed that.

nmh 1.7.1 is available at
http://download.savannah.nongnu.org/releases/nmh/nmh-1.7.1.tar.gz

"mhpath -version" will show the nmh version.

David


Reply | Threaded
Open this post in threaded view
|

Re: 4 of 108 tests failed testing nmh

Ken Hornstein-2
In reply to this post by David Levine-3
>> ANOTHER follow-up ... that bug is not present in 1.7.1.  I would advise
>> you use that.
>
>Confirmed.  There is a compile warning due to not including a correct
>header without READLINE_SUPPORT, I just fixed that.

Huh, I guess the core problem was without a prototype that function
had a default return type of "int", not "char **", and the return pointer
was getting mangled.  At least that was an easy one!

--Ken