Mailing List Archive

Still Failing: apache/httpd#896 (trunk - 9af2218)
Build Update for apache/httpd
-------------------------------------

Build: #896
Status: Still Failing

Duration: 9 mins and 44 secs
Commit: 9af2218 (trunk)
Author: Graham Leggett
Message: Add implementation of deliver_report and gather_reports to mod_dav.c.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1879307 13f79535-47bb-0310-9956-ffa450edef68

View the changeset: https://github.com/apache/httpd/compare/8556bcf4f44c...9af2218159e9

View the full build log and details: https://travis-ci.org/github/apache/httpd/builds/702872240?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=69847&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
Re: Still Failing: apache/httpd#896 (trunk - 9af2218) [ In reply to ]
On 28 Jun 2020, at 15:47, Travis CI <builds@travis-ci.org> wrote:

> apache / httpd
> trunk
> Build #896 is still failing9 mins and 44 secs

Travis mavens, I’ve been looking for the test/perl-framework directory as referred to in --with-test-suite=test/perl-framework but I’m coming up with a blank.

http-tests/trunk currently succeeds as follows:

[minfrin@bob httpd-test]$ t/TEST t/modules/dav.t
/tmp/httpd-trunk/bin/httpd -d /home/minfrin/src/apache/sandbox/httpd/httpd-test/t -f /home/minfrin/src/apache/sandbox/httpd/httpd-test/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS
using Apache/2.5.1-dev (event MPM)

waiting 60 seconds for server to start: .[Sun Jun 28 15:13:34.054340 2020] [core:warn] [pid 5058:tid 139811004360960] AH00111: Config variable ${DOCROOT} is not defined
[Sun Jun 28 15:13:34.058092 2020] [core:trace3] [pid 5058:tid 139811004360960] core.c(3552): Setting LogLevel for all modules to trace8
[Sun Jun 28 15:13:34.059108 2020] [core:trace6] [pid 5058:tid 139811004360960] core.c(3570): Cannot find module 'rewrite', trying 'rewrite_module'
[Sun Jun 28 15:13:34.059122 2020] [core:trace3] [pid 5058:tid 139811004360960] core.c(3581): Setting LogLevel for module mod_rewrite.c to trace8
[Sun Jun 28 15:13:34.060338 2020] [core:trace3] [pid 5058:tid 139811004360960] core.c(3552): Setting LogLevel for all modules to info
[Sun Jun 28 15:13:34.060356 2020] [core:trace6] [pid 5058:tid 139811004360960] core.c(3570): Cannot find module 'core', trying 'core_module'
[Sun Jun 28 15:13:34.060360 2020] [core:trace3] [pid 5058:tid 139811004360960] core.c(3581): Setting LogLevel for module core.c to crit
[Sun Jun 28 15:13:34.060365 2020] [core:trace3] [pid 5058:tid 139811004360960] core.c(3552): Setting LogLevel for all modules to crit
[Sun Jun 28 15:13:34.060370 2020] [core:trace6] [pid 5058:tid 139811004360960] core.c(3570): Cannot find module 'core', trying 'core_module'
[Sun Jun 28 15:13:34.060373 2020] [core:trace3] [pid 5058:tid 139811004360960] core.c(3581): Setting LogLevel for module core.c to info
[Sun Jun 28 15:13:34.060377 2020] [core:trace3] [pid 5058:tid 139811004360960] core.c(3552): Setting LogLevel for all modules to crit
[Sun Jun 28 15:13:34.060394 2020] [core:trace6] [pid 5058:tid 139811004360960] core.c(3570): Cannot find module 'core', trying 'core_module'
[Sun Jun 28 15:13:34.060401 2020] [core:trace3] [pid 5058:tid 139811004360960] core.c(3581): Setting LogLevel for module core.c to info
[Sun Jun 28 15:13:34.060408 2020] [core:trace3] [pid 5058:tid 139811004360960] core.c(3552): Setting LogLevel for all modules to crit
[Sun Jun 28 15:13:34.060413 2020] [core:trace3] [pid 5058:tid 139811004360960] core.c(3552): Setting LogLevel for all modules to info
[Sun Jun 28 15:13:34.060418 2020] [core:trace6] [pid 5058:tid 139811004360960] core.c(3570): Cannot find module 'core', trying 'core_module'
[Sun Jun 28 15:13:34.060422 2020] [core:trace3] [pid 5058:tid 139811004360960] core.c(3581): Setting LogLevel for module core.c to crit
[Sun Jun 28 15:13:34.060427 2020] [core:trace3] [pid 5058:tid 139811004360960] core.c(3552): Setting LogLevel for all modules to info
[Sun Jun 28 15:13:34.061870 2020] [core:trace6] [pid 5058:tid 139811004360960] core.c(3570): Cannot find module 'proxy_hcheck', trying 'proxy_hcheck_module'
[Sun Jun 28 15:13:34.061883 2020] [core:trace3] [pid 5058:tid 139811004360960] core.c(3581): Setting LogLevel for module mod_proxy_hcheck.c to trace4
[Sun Jun 28 15:13:34.063067 2020] [ssl:warn] [pid 5058:tid 139811004360960] AH10235: SSLRandomSeed is deprecated and has no effect with OpenSSL 1.1.1 and later
[Sun Jun 28 15:13:34.063079 2020] [ssl:warn] [pid 5058:tid 139811004360960] AH10235: SSLRandomSeed is deprecated and has no effect with OpenSSL 1.1.1 and later

waiting 60 seconds for server to start: ok (waited 0 secs)
server localhost:8529 started
server localhost:8530 listening (mod_nntp_like)
server localhost:8531 listening (mod_nntp_like_ssl)
server localhost:8532 listening (mod_ssl)
server localhost:8533 listening (ssl_optional_cc)
server localhost:8534 listening (ssl_pr33791)
server localhost:8535 listening (ssl_ocsp)
server localhost:8536 listening (cve_2011_3368_rewrite)
server localhost:8537 listening (proxy_http_reverse)
server localhost:8538 listening (proxy_http_nofwd)
server localhost:8539 listening (cve_2011_3368)
server localhost:8540 listening (mod_headers)
server localhost:8541 listening (error_document)
server localhost:8542 listening (http_unsafe)
server localhost:8543 listening (http_strict)
server localhost:8544 listening (remote_ip)
server localhost:8545 listening (mod_proxy)
server localhost:8546 listening (proxy_http_bal1)
server localhost:8547 listening (proxy_http_bal2)
server localhost:8548 listening (proxy_http_balancer)
server localhost:8551 listening (proxy_fcgi)
server localhost:8552 listening (mod_cache)
server localhost:8553 listening (h2c)
server localhost:8554 listening (h2)
server localhost:8555 listening (core)
server localhost:8556 listening (mod_include)
server localhost:8557 listening (mod_vhost_alias)
server localhost:8558 listening (proxy_http_https)
server localhost:8559 listening (proxy_https_https)
server localhost:8560 listening (proxy_http_https_proxy_section)
server localhost:8561 listening (proxy_https_https_proxy_section)
server localhost:8562 listening (proxy_https_http)
t/modules/dav.t .. ok
All tests successful.
Files=1, Tests=19, 2 wallclock secs ( 0.02 usr 0.01 sys + 0.27 cusr 0.10 csys = 0.40 CPU)
Result: PASS
[warning] server localhost:8529 shutdown

Regards,
Graham
--
Re: Still Failing: apache/httpd#896 (trunk - 9af2218) [ In reply to ]
On Sun, Jun 28, 2020 at 05:15:03PM +0200, Graham Leggett wrote:
> On 28 Jun 2020, at 15:47, Travis CI <builds@travis-ci.org> wrote:
>
> > apache / httpd
> > trunk
> > Build #896 is still failing9 mins and 44 secs
>
> Travis mavens, I’ve been looking for the test/perl-framework directory
> as referred to in --with-test-suite=test/perl-framework but I’m coming
> up with a blank.

The litmus tests are failing, not the perl-framework tests:

https://travis-ci.org/github/apache/httpd/jobs/702768269#L2491

You can also see that there are segfaults logged from line 2519 onwards:

https://travis-ci.org/github/apache/httpd/jobs/702768269#L2519

Running litmus locally, the backtrace looks like this:

warning: Unexpected size of section `.reg-xstate/44301' in core file.
#0 0x00007fcea5f9059a in dav_fs_getetag (resource=<optimized out>) at repos.c:1869
1869 er.request_time = ctx->r->request_time;
[Current thread is 1 (Thread 0x7fcea6d70800 (LWP 44301))]
Missing separate debuginfos, use: dnf debuginfo-install pcre2-10.35-3.fc32.x86_64
(gdb) where
#0 0x00007fcea5f9059a in dav_fs_getetag (resource=<optimized out>) at repos.c:1869
#1 0x00007fcea5fda7af in dav_validate_resource_state (p=0xfb5288, resource=<optimized out>, lockdb=0xfcf060, if_header=0xfcf008,
flags=flags@entry=288, pbuf=pbuf@entry=0x7ffdc5916010, r=0xfb5300) at util.c:1046
#2 0x00007fcea5fdb9cf in dav_validate_request (r=r@entry=0xfb5300, resource=0xfcec70, depth=depth@entry=0,
locktoken=locktoken@entry=0x0, response=response@entry=0x7ffdc5916168, flags=flags@entry=32, lockdb=<optimized out>)
at util.c:1652
#3 0x00007fcea5fd1e4e in dav_method_put (r=0xfb5300) at mod_dav.c:985
#4 0x00000000004170d0 in ap_run_handler (r=r@entry=0xfb5300) at config.c:170
#5 0x0000000000417666 in ap_invoke_handler (r=r@entry=0xfb5300) at config.c:444
#6 0x000000000045a3eb in ap_process_async_request (r=r@entry=0xfb5300) at http_request.c:463
#7 0x000000000045a41f in ap_process_request (r=r@entry=0xfb5300) at http_request.c:498
#8 0x0000000000456fbe in ap_process_http_sync_connection (c=0xf90440) at http_core.c:214
#9 ap_process_http_connection (c=0xf90440) at http_core.c:255
#10 0x00000000004283c0 in ap_run_process_connection (c=c@entry=0xf90440) at connection.c:42
#11 0x0000000000428919 in ap_process_connection (c=c@entry=0xf90440, csd=<optimized out>) at connection.c:219
#12 0x00007fcea75439fe in child_main (child_num_arg=child_num_arg@entry=2, child_bucket=child_bucket@entry=0) at prefork.c:621
#13 0x00007fcea7543d7e in make_child (s=<optimized out>, slot=2) at prefork.c:723
#14 0x00007fcea75444bf in perform_idle_server_maintenance (p=<optimized out>) at prefork.c:827
#15 prefork_run (_pconf=<optimized out>, plog=<optimized out>, s=<optimized out>) at prefork.c:1020
#16 0x000000000042b7f0 in ap_run_mpm (pconf=pconf@entry=0x9f33f8, plog=0xa1e608, s=0xa1a750) at mpm_common.c:101
#17 0x0000000000415347 in main (argc=<optimized out>, argv=<optimized out>) at main.c:844
Re: Still Failing: apache/httpd#896 (trunk - 9af2218) [ In reply to ]
On 29 Jun 2020, at 09:19, Joe Orton <jorton@redhat.com> wrote:

> The litmus tests are failing, not the perl-framework tests:
>
> https://travis-ci.org/github/apache/httpd/jobs/702768269#L2491

Ah - that’s where I was going wrong.

> You can also see that there are segfaults logged from line 2519 onwards:
>
> https://travis-ci.org/github/apache/httpd/jobs/702768269#L2519
>
> Running litmus locally, the backtrace looks like this:

So the simple workaround is to be defensive against ctx->r being NULL, but I need to check - is there ever a legitimate reason for there to be a filled out ctx structure including a filename, but with no request?

Process 9883 stopped
* thread #62, stop reason = EXC_BAD_ACCESS (code=1, address=0x58)
frame #0: 0x0000000100203e09 httpd`dav_fs_getetag(resource=0x000000010106f1e0) at repos.c:1869:31
1866 }
1867
1868 er.vlist_validator = NULL;
-> 1869 er.request_time = ctx->r->request_time;
1870 er.finfo = &ctx->finfo;
1871 er.pathname = ctx->pathname;
1872 er.fd = NULL;
Target 0: (httpd) stopped.
(lldb) print ctx
(dav_resource_private *) $0 = 0x000000010106f110
(lldb) print *ctx
(dav_resource_private) $1 = {
pool = 0x0000000105098628
pathname = 0x000000010106f198 "/Users/minfrin/src/apache/sandbox/proxy/htdocs/dav/litmus/lockcoll"
finfo = {
pool = 0x0000000105098628
valid = 7598960
protection = 1877
filetype = APR_DIR
user = 501
group = 20
inode = 61244902
device = 16777220
nlink = 2
size = 64
csize = 0
atime = 1593421218000000
mtime = 1593421218000000
ctime = 1593421218000000
fname = 0x000000010106f198 "/Users/minfrin/src/apache/sandbox/proxy/htdocs/dav/litmus/lockcoll"
name = 0x0000000000000000
filehand = 0x0000000000000000
}
r = 0x0000000000000000
}
(lldb)

Regards,
Graham
Re: Still Failing: apache/httpd#896 (trunk - 9af2218) [ In reply to ]
On Mon, Jun 29, 2020 at 11:16:54AM +0200, Graham Leggett wrote:
> On 29 Jun 2020, at 09:19, Joe Orton <jorton@redhat.com> wrote:
>
> > The litmus tests are failing, not the perl-framework tests:
> >
> > https://travis-ci.org/github/apache/httpd/jobs/702768269#L2491
>
> Ah - that’s where I was going wrong.
>
> > You can also see that there are segfaults logged from line 2519 onwards:
> >
> > https://travis-ci.org/github/apache/httpd/jobs/702768269#L2519
> >
> > Running litmus locally, the backtrace looks like this:
>
> So the simple workaround is to be defensive against ctx->r being NULL,
> but I need to check - is there ever a legitimate reason for there to
> be a filled out ctx structure including a filename, but with no
> request?

I don't know, you added the ctx->r field in r823703 and it's not obvious
exactly what the semantics are supposed to be.

If the request_rec is supposed to correspond to the dav_resource object
then it makes sense that it is NULL when looking at the dav_resource
representing the parent collection (in this case) or some other resource
during a walk. It would be good to document this!

Regards, Joe