Re: dovecot 2.3.13 : make check FAILURE : Assert failed: buffer_append_full_file
On 1/18/21 11:22 AM, Aki Tuomi wrote:
line 52 does chmod to
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
Re: dovecot 2.3.13 : make check FAILURE : Assert failed: buffer_append_full_file
> On 18/01/2021 17:21 J Lumby wrote: > > > On 1/18/21 12:25 AM, Aki Tuomi wrote: > >> On 18/01/2021 00:35 J Lumby wrote: > >> > >> > >> Thanks Aki. > >> > >> > >> On 1/16/21 10:18 AM, Aki Tuomi wrote: > On 16/01/2021 16:36 J Lumby wrote: > > > > make check had one failure as follows : > > test-buffer-istream.c:54: Assert failed: buffer_append_full_file(result, > TEST_FILENAME, SIZE_MAX, ) == 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-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. > 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 lines 54-55 attempts to read this file now, and expects it to fail line 56 ensures that there was actual error provided Aki
Re: dovecot 2.3.13 : make check FAILURE : Assert failed: buffer_append_full_file
On 1/18/21 12:25 AM, Aki Tuomi wrote: On 18/01/2021 00:35 J Lumby wrote: Thanks Aki. On 1/16/21 10:18 AM, Aki Tuomi wrote: On 16/01/2021 16:36 J Lumby wrote: make check had one failure as follows : test-buffer-istream.c:54: Assert failed: buffer_append_full_file(result, TEST_FILENAME, SIZE_MAX, ) == 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-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. 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 .
Re: dovecot 2.3.13 : make check FAILURE : Assert failed: buffer_append_full_file
> On 18/01/2021 00:35 J Lumby wrote: > > > Thanks Aki. > > > On 1/16/21 10:18 AM, Aki Tuomi wrote: > >> On 16/01/2021 16:36 J Lumby wrote: > >> > >> > >> > >> make check had one failure as follows : > >> > >> test-buffer-istream.c:54: Assert failed: buffer_append_full_file(result, > >> TEST_FILENAME, SIZE_MAX, ) == 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
Re: dovecot 2.3.13 : make check FAILURE : Assert failed: buffer_append_full_file
Thanks Aki. On 1/16/21 10:18 AM, Aki Tuomi wrote: On 16/01/2021 16:36 J Lumby wrote: make check had one failure as follows : test-buffer-istream.c:54: Assert failed: buffer_append_full_file(result, TEST_FILENAME, SIZE_MAX, ) == 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
Re: dovecot 2.3.13 : make check FAILURE : Assert failed: buffer_append_full_file
I was experiencing multiple failures with make check on a fresh installation of CentOS 8.3.The solution for me was to use mock instead of rpmbuild. (I was not building as root with rpmbuild.) With mock all tests were successful. Sent from my T-Mobile 4G LTE device-- Original message--From: J LumbyDate: Sat, Jan 16, 2021 11:31 AMTo: dovecot@dovecot.org;Cc: Subject:dovecot 2.3.13 : make check FAILURE : Assert failed: buffer_append_full_fileAfter 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, ) == 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
Re: dovecot 2.3.13 : make check FAILURE : Assert failed: buffer_append_full_file
> On 16/01/2021 16:36 J Lumby 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, ) == 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
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, ) == 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
