dovecot 2.3.13 : make check FAILURE : Assert failed: buffer_append_full_file
After successfully building dovecot 2.3.13 (linux kernel 5.10.1 , glibc-2.32 , gcc-9.3)
make check had one failure as follows :
test-buffer-istream.c:54: Assert failed: buffer_append_full_file(result, TEST_FILENAME, SIZE_MAX, &error) == BUFFER_APPEND_READ_ERROR test-buffer-istream.c:56: Assert failed: error != NULL && *error != '\0' buffer_append_full_file .............................................. : FAILED
After a brief look at the referenced code in test-buffer-istream.c , I can't find out what this FAIL really means or whether it is serious.
The assert is finding that the result of the call to buffer_append_full_file is not BUFFER_APPEND_READ_ERROR, but it does not report what the result code actually was. Maybe errno was actually 0 and call succeeded? I don't know. Nor can I see how to add some code to find out.
Can anyone offer any advice on what this means and/or how to investigate?
Cheers, John Lumby
On 16/01/2021 16:36 J Lumby johnlumby@hotmail.com wrote:
After successfully building dovecot 2.3.13 (linux kernel 5.10.1 , glibc-2.32 , gcc-9.3)
make check had one failure as follows :
test-buffer-istream.c:54: Assert failed: buffer_append_full_file(result, TEST_FILENAME, SIZE_MAX, &error) == BUFFER_APPEND_READ_ERROR test-buffer-istream.c:56: Assert failed: error != NULL && *error != '\0' buffer_append_full_file .............................................. : FAILED
After a brief look at the referenced code in test-buffer-istream.c , I can't find out what this FAIL really means or whether it is serious.
The assert is finding that the result of the call to buffer_append_full_file is not BUFFER_APPEND_READ_ERROR, but it does not report what the result code actually was. Maybe errno was actually 0 and call succeeded? I don't know. Nor can I see how to add some code to find out.
Can anyone offer any advice on what this means and/or how to investigate?
Cheers, John Lumby
Hi!
You are running make check as root. Try running it as non-root user.
Aki
Thanks Aki.
On 1/16/21 10:18 AM, Aki Tuomi wrote:
On 16/01/2021 16:36 J Lumby johnlumby@hotmail.com wrote:
make check had one failure as follows :
test-buffer-istream.c:54: Assert failed: buffer_append_full_file(result, TEST_FILENAME, SIZE_MAX, &error) == BUFFER_APPEND_READ_ERROR test-buffer-istream.c:56: Assert failed: error != NULL && *error != '\0' buffer_append_full_file .............................................. : FAILED
Hi!
You are running make check as root. Try running it as non-root user.
You were absolutely correct with your diagnosis - yes I was running make check as root.
I did so because I run dovecot itself as root - as instructed by the wiki :
Running Dovecot : Starting :
"Dovecot can simply be started by running dovecot as root"
And (I assume) it is best to run the make check under same userid, i.e. root, otherwise it is not testing what will actually be running.
But anyway I tried running make check under non-root and the result was much worse - some indeterminate FAIL much earlier :
Making check in lib-ssl-iostream
make[2]: Entering directory
'/mnt/julywext/wextmisc/fed30GBroot/ahcombld/dovecot-2.3.13/src/lib-ssl-iostream'
make check-local
make[3]: Entering directory
'/mnt/julywext/wextmisc/fed30GBroot/ahcombld/dovecot-2.3.13/src/lib-ssl-iostream'
for bin in test-iostream-ssl; do
if ! /bin/sh ../../run-test.sh ../.. ./$bin; then exit 1; fi;
done
collect2: error: ld returned 213 exit status
Failed to run: ./test-iostream-ssl
I ran it with sh -x to see if it would tell me any more but all it indicated is that, somewhere during execution of valgrind, it hits this error from ld.
My valgrind is the latest, 3.16.1,
May we re-visit the FAIL I reported originally ? Why does it FAIL when run under userid root?
I am guessing that somehow root gets a higher limit for the count parameter on read(fd , *buf , count) than non-root? Although the man page for read() does not indicate any such distinction.
Or is dovecot implementing its own user-id-specific limit?
And, what code could I add to test-buffer-istream.c to make it print out the offending errno?
Or, perhaps easier - is it safe to ignore this one FAIL?
Aki .
Cheers, John Lumby
On 18/01/2021 00:35 J Lumby johnlumby@hotmail.com wrote:
Thanks Aki.
On 1/16/21 10:18 AM, Aki Tuomi wrote:
On 16/01/2021 16:36 J Lumby johnlumby@hotmail.com wrote:
make check had one failure as follows :
test-buffer-istream.c:54: Assert failed: buffer_append_full_file(result, TEST_FILENAME, SIZE_MAX, &error) == BUFFER_APPEND_READ_ERROR test-buffer-istream.c:56: Assert failed: error != NULL && *error != '\0' buffer_append_full_file .............................................. : FAILED
Hi!
You are running make check as root. Try running it as non-root user.
You were absolutely correct with your diagnosis - yes I was running make check as root.
I did so because I run dovecot itself as root - as instructed by the wiki :
Running Dovecot : Starting :
"Dovecot can simply be started by running dovecot as root"
And (I assume) it is best to run the make check under same userid, i.e. root, otherwise it is not testing what will actually be running.
But anyway I tried running make check under non-root and the result was much worse - some indeterminate FAIL much earlier :
Making check in lib-ssl-iostream make[2]: Entering directory '/mnt/julywext/wextmisc/fed30GBroot/ahcombld/dovecot-2.3.13/src/lib-ssl-iostream' make check-local make[3]: Entering directory '/mnt/julywext/wextmisc/fed30GBroot/ahcombld/dovecot-2.3.13/src/lib-ssl-iostream' for bin in test-iostream-ssl; do
if ! /bin/sh ../../run-test.sh ../.. ./$bin; then exit 1; fi;
done collect2: error: ld returned 213 exit status Failed to run: ./test-iostream-ssl
This is because you have also compiled the source as root and fails to write to those directories. You need to build as non-root, too.
I ran it with sh -x to see if it would tell me any more but all it indicated is that, somewhere during execution of valgrind, it hits this error from ld.
My valgrind is the latest, 3.16.1,
May we re-visit the FAIL I reported originally ? Why does it FAIL when run under userid root?
Because it's testing that it cannot read a file it has no permissions to read. root can read all files. You can see it does a chmod few lines before.
I am guessing that somehow root gets a higher limit for the count parameter on read(fd , *buf , count) than non-root? Although the man page for read() does not indicate any such distinction.
Or is dovecot implementing its own user-id-specific limit?
And, what code could I add to test-buffer-istream.c to make it print out the offending errno?
Or, perhaps easier - is it safe to ignore this one FAIL?
Aki .
Cheers, John Lumby
Aki
On 1/18/21 12:25 AM, Aki Tuomi wrote:
On 18/01/2021 00:35 J Lumby johnlumby@hotmail.com wrote:
Thanks Aki.
On 1/16/21 10:18 AM, Aki Tuomi wrote:
On 16/01/2021 16:36 J Lumby johnlumby@hotmail.com wrote:
make check had one failure as follows :
test-buffer-istream.c:54: Assert failed: buffer_append_full_file(result, TEST_FILENAME, SIZE_MAX, &error) == BUFFER_APPEND_READ_ERROR test-buffer-istream.c:56: Assert failed: error != NULL && *error != '\0' buffer_append_full_file .............................................. : FAILED
And (I assume) it is best to run the make check under same userid, i.e. root, otherwise it is not testing what will actually be running.
But anyway I tried running make check under non-root and the result was much worse - some indeterminate FAIL much earlier :
Making check in lib-ssl-iostream make[2]: Entering directory '/mnt/julywext/wextmisc/fed30GBroot/ahcombld/dovecot-2.3.13/src/lib-ssl-iostream' make check-local make[3]: Entering directory '/mnt/julywext/wextmisc/fed30GBroot/ahcombld/dovecot-2.3.13/src/lib-ssl-iostream' for bin in test-iostream-ssl; do
if ! /bin/sh ../../run-test.sh ../.. ./$bin; then exit 1; fi;
done collect2: error: ld returned 213 exit status Failed to run: ./test-iostream-sslThis is because you have also compiled the source as root and fails to write to those directories. You need to build as non-root, too. No, for this attempt I ran all steps as non-root including make.
May we re-visit the FAIL I reported originally ? Why does it FAIL when run under userid root?
Because it's testing that it cannot read a file it has no permissions to read. root can read all files. You can see it does a chmod few lines before.
You are in the wrong place -in the file - you are looking at line 61,my error occurred at line 54 - see error message earlier.
It is make some kind of test for size of record being read.
And, what code could I add to test-buffer-istream.c to make it print out the offending errno?
Or, perhaps easier - is it safe to ignore this one FAIL?
Hoping you will answer these ...
Aki . Cheers, John Lumby Aki .
On 18/01/2021 17:21 J Lumby johnlumby@hotmail.com wrote:
On 1/18/21 12:25 AM, Aki Tuomi wrote:
On 18/01/2021 00:35 J Lumby johnlumby@hotmail.com wrote:
Thanks Aki.
On 1/16/21 10:18 AM, Aki Tuomi wrote:
On 16/01/2021 16:36 J Lumby johnlumby@hotmail.com wrote:
make check had one failure as follows :
test-buffer-istream.c:54: Assert failed: buffer_append_full_file(result, TEST_FILENAME, SIZE_MAX, &error) == BUFFER_APPEND_READ_ERROR test-buffer-istream.c:56: Assert failed: error != NULL && *error != '\0' buffer_append_full_file .............................................. : FAILED
And (I assume) it is best to run the make check under same userid, i.e. root, otherwise it is not testing what will actually be running.
But anyway I tried running make check under non-root and the result was much worse - some indeterminate FAIL much earlier :
Making check in lib-ssl-iostream make[2]: Entering directory '/mnt/julywext/wextmisc/fed30GBroot/ahcombld/dovecot-2.3.13/src/lib-ssl-iostream' make check-local make[3]: Entering directory '/mnt/julywext/wextmisc/fed30GBroot/ahcombld/dovecot-2.3.13/src/lib-ssl-iostream' for bin in test-iostream-ssl; do
if ! /bin/sh ../../run-test.sh ../.. ./$bin; then exit 1; fi;
done collect2: error: ld returned 213 exit status Failed to run: ./test-iostream-sslThis is because you have also compiled the source as root and fails to write to those directories. You need to build as non-root, too. No, for this attempt I ran all steps as non-root including make.
May we re-visit the FAIL I reported originally ? Why does it FAIL when run under userid root?
Because it's testing that it cannot read a file it has no permissions to read. root can read all files. You can see it does a chmod few lines before.
You are in the wrong place -in the file - you are looking at line 61,my error occurred at line 54 - see error message earlier.
It is make some kind of test for size of record being read.
And, what code could I add to test-buffer-istream.c to make it print out the offending errno?
Or, perhaps easier - is it safe to ignore this one FAIL?
Hoping you will answer these ...
Aki . Cheers, John Lumby Aki .
line 52 does chmod to 0000 lines 54-55 attempts to read this file now, and expects it to fail line 56 ensures that there was actual error provided
Aki
On 1/18/21 11:22 AM, Aki Tuomi wrote:
line 52 does chmod to 0000 lines 54-55 attempts to read this file now, and expects it to fail line 56 ensures that there was actual error provided
Oh yes, of course you are correct. I was confused by the MAX_SIZE parameter.
I wrapped that test with
my_euid = geteuid(); if (0 == my_euid) { /* am I running as root ? */ seteuid(1); /* set effective uid to non-root */ }
[ run test ]
if (0 == my_euid) { /* was I running as root ? */ seteuid(0); /* reinstate effective uid to root again */ }
and now it does not fail.
Aki
I also discovered the cause of the ld errors from running some of the tests - the gcc link command was failing because the openssl libs were either not included in the command line or placed too early in the command line, before the libssl_iostream_openssl.so which references them. I had same problem with the make but fixed it up, but the same treatment is needed for the make check. My openssl libs are in /opt/openssl/lib, and I did follow the build instructions and specify
SSL_CFLAGS="-I/opt/openssl/include" SSL_LIBS="-L/opt/openssl/lib" LDFLAGS="-L/opt/openssl/lib"
but libtool did not do the right thing in some places. dovecot seems to have an unusual way of "linking" the openssl libs.
Eventually I think all is well. Thanks
Cheers, John Lumby
.SSL_CFLAGS="-I/opt/openssl/include" SSL_LIBS="-L/opt/openssl/lib" LDFLAGS="-L/opt/openssl/lib
participants (2)
-
Aki Tuomi
-
J Lumby