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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Travis CI

apache

/

httpd

branch icontrunk

arrow to build time
clock icon9 mins and 44 secs

Graham Leggett avatarGraham Leggett

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

Want to know about upcoming build environment updates?

Would you like to stay up-to-date with the upcoming Travis CI build environment updates? We set up a mailing list for you!

SIGN UP HERE
book icon

Documentation about Travis CI

<script type="application/ld+json"> { "@context": "http://schema.org", "@type": "EmailMessage", "action": { "@type": "ViewAction", "url": "https://travis-ci.org/github/apache/httpd/builds/702872240?utm_medium=notification&amp;utm_source=email", "name": "View Build" }, "description": "View Build #896 on Travis CI" } </script>
Reply | Threaded
Open this post in threaded view
|

Re: Still Failing: apache/httpd#896 (trunk - 9af2218)

Graham Leggett
On 28 Jun 2020, at 15:47, Travis CI <[hidden email]> 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
--

Reply | Threaded
Open this post in threaded view
|

Re: Still Failing: apache/httpd#896 (trunk - 9af2218)

Joe Orton
On Sun, Jun 28, 2020 at 05:15:03PM +0200, Graham Leggett wrote:
> On 28 Jun 2020, at 15:47, Travis CI <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Still Failing: apache/httpd#896 (trunk - 9af2218)

Graham Leggett
On 29 Jun 2020, at 09:19, Joe Orton <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Still Failing: apache/httpd#896 (trunk - 9af2218)

Joe Orton
On Mon, Jun 29, 2020 at 11:16:54AM +0200, Graham Leggett wrote:

> On 29 Jun 2020, at 09:19, Joe Orton <[hidden email]> 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