Mailing List Archive: Broken: apache/httpd#1667 (2.4.x

Broken: apache/httpd#1667 (2.4.x - 59393dd)

Jun 3, 2021, 10:23 AM

Post #1 of 7 (409 views)

Build Update for apache/httpd
-------------------------------------

Build: #1667
Status: Broken

Duration: 19 mins and 23 secs
Commit: 59393dd (2.4.x)
Author: Eric Covener
Message: correct CVE year

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1890439 13f79535-47bb-0310-9956-ffa450edef68

View the changeset: https://github.com/apache/httpd/compare/e4bbe0e31a52...59393dd87f5e

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

--

You can unsubscribe from build emails from the apache/httpd repository going to https://travis-ci.com/account/preferences/unsubscribe?repository=16806660&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at https://travis-ci.com/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: Broken: apache/httpd#1667 (2.4.x - 59393dd) [ In reply to ]

rpluem at apache

Jun 3, 2021, 11:27 AM

Post #2 of 7 (409 views)

Permalink

On 6/3/21 7:23 PM, Travis CI wrote:
> apache
>
> /
>
> httpd
>
> <https://travis-ci.com/github/apache/httpd?utm_medium=notification&utm_source=email>
>
> branch icon2.4.x <https://github.com/apache/httpd/tree/2.4.x>
>
> build has failed
> Build #1667 was broken <https://travis-ci.com/github/apache/httpd/builds/227897922?utm_medium=notification&utm_source=email>
> arrow to build time
> clock icon19 mins and 23 secs
>
> Eric Covener avatarEric Covener
>
> 59393dd CHANGESET ? <https://github.com/apache/httpd/compare/e4bbe0e31a52...59393dd87f5e>
>
> correct CVE year
>

Looking at the stack trace, would we need to call apr_setup_signal_thread() (if we have APR_THREADS) before we run
ap_run_child_init and unblock all signals afterwards in case one of the init child hooks creates threads like mod_watchdog does?

Thread 2 (Thread 0x7f4c98b2cbc0 (LWP 6768)):
#0 run_cleanups (cref=0x55753eaa5930) at memory/unix/apr_pools.c:2704
#1 pool_clear_debug (pool=pool@entry=0x55753eaa58a0, file_line=0x7f4c971a9eda "prefork.c:227") at memory/unix/apr_pools.c:1839
#2 0x00007f4c982540e9 in pool_destroy_debug (pool=0x55753eaa58a0, file_line=<optimized out>) at memory/unix/apr_pools.c:1937
#3 0x00007f4c98254960 in apr_pool_destroy_debug (pool=0x55753eaa58a0, file_line=0x7f4c971a9eda "prefork.c:227") at
memory/unix/apr_pools.c:1986
#4 0x00007f4c971a825a in clean_child_exit (code=code@entry=0) at prefork.c:227
#5 0x00007f4c971a829b in just_die (sig=<optimized out>) at prefork.c:355
#6 <signal handler called>
#7 0x00007f4c97d36cb9 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#8 0x00007f4c9825e24b in poll (__timeout=2000, __nfds=1, __fds=0x7ffd22f53c90) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#9 apr_wait_for_io_or_timeout (f=f@entry=0x0, s=s@entry=0x55753e85a9a0, for_read=for_read@entry=1) at support/unix/waitio.c:51
#10 0x00007f4c9825796a in apr_socket_recv (sock=sock@entry=0x55753e85a9a0, buf=buf@entry=0x7ffd22f53cf0 "\220\063\310>uU",
len=len@entry=0x7ffd22f53ce8) at network_io/unix/sendrecv.c:87
#11 0x000055753da86db4 in ap_lingering_close (c=c@entry=0x55753e8879f0) at connection.c:182
#12 0x00007f4c971a883d in child_main (child_num_arg=child_num_arg@entry=6, child_bucket=child_bucket@entry=0) at prefork.c:616
#13 0x00007f4c971a8b34 in make_child (s=0x55753eb0a1a0, slot=6) at prefork.c:717
#14 0x00007f4c971a958e in perform_idle_server_maintenance (p=<optimized out>) at prefork.c:821
#15 prefork_run (_pconf=<optimized out>, plog=<optimized out>, s=<optimized out>) at prefork.c:1014
#16 0x000055753da5e9fe in ap_run_mpm (pconf=0x55753e703bb0, plog=0x55753e732c10, s=0x55753eb0a1a0) at mpm_common.c:94
#17 0x000055753da568d5 in main (argc=<optimized out>, argv=<optimized out>) at main.c:819

Thread 1 (Thread 0x7f4c7a55d700 (LWP 6769)):
#0 0x00007f4c7fe70be0 in ?? () from /lib/x86_64-linux-gnu/libgpg-error.so.0
#1 0x00007f4c97c65161 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007f4c97c6525a in exit () from /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007f4c971a827a in clean_child_exit (code=code@entry=0) at prefork.c:236
#4 0x00007f4c971a829b in just_die (sig=<optimized out>) at prefork.c:355
#5 <signal handler called>
#6 0x00007f4c97d38e1f in select () from /lib/x86_64-linux-gnu/libc.so.6
#7 0x00007f4c9825ff75 in apr_sleep (t=t@entry=100000) at time/unix/time.c:246
#8 0x00007f4c8f625e58 in wd_worker (thread=<optimized out>, data=0x55753ec281f0) at mod_watchdog.c:159
#9 0x00007f4c9825f53f in dummy_worker (opaque=0x55753eb5c160) at threadproc/unix/thread.c:147
#10 0x00007f4c9801a6db in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#11 0x00007f4c97d4371f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Regards

Rüdiger

Re: Broken: apache/httpd#1667 (2.4.x - 59393dd) [ In reply to ]

ylavic.dev at gmail

Jun 3, 2021, 1:36 PM

Post #3 of 7 (409 views)

Permalink

On Thu, Jun 3, 2021 at 8:27 PM Ruediger Pluem <rpluem@apache.org> wrote:
>
> Looking at the stack trace, would we need to call apr_setup_signal_thread() (if we have APR_THREADS) before we run
> ap_run_child_init and unblock all signals afterwards in case one of the init child hooks creates threads like mod_watchdog does?

Agreed, what about the attached patch?

Regards;
Yann.

Re: Broken: apache/httpd#1667 (2.4.x - 59393dd) [ In reply to ]

rpluem at apache

Jun 3, 2021, 9:53 PM

Post #4 of 7 (408 views)

Permalink

On 6/3/21 10:36 PM, Yann Ylavic wrote:
> On Thu, Jun 3, 2021 at 8:27 PM Ruediger Pluem <rpluem@apache.org> wrote:
>>
>> Looking at the stack trace, would we need to call apr_setup_signal_thread() (if we have APR_THREADS) before we run
>> ap_run_child_init and unblock all signals afterwards in case one of the init child hooks creates threads like mod_watchdog does?
>
> Agreed, what about the attached patch?

Looks good to me.

Regards

Rüdiger

Re: Broken: apache/httpd#1667 (2.4.x - 59393dd) [ In reply to ]

npopov at cloudlinux

Jun 3, 2021, 11:35 PM

Post #5 of 7 (407 views)

Permalink

Is it ok that we include an os-specific API into the main code, not
into the APR project?

On Fri, Jun 4, 2021 at 9:53 AM Ruediger Pluem <rpluem@apache.org> wrote:
>
>
>
> On 6/3/21 10:36 PM, Yann Ylavic wrote:
> > On Thu, Jun 3, 2021 at 8:27 PM Ruediger Pluem <rpluem@apache.org> wrote:
> >>
> >> Looking at the stack trace, would we need to call apr_setup_signal_thread() (if we have APR_THREADS) before we run
> >> ap_run_child_init and unblock all signals afterwards in case one of the init child hooks creates threads like mod_watchdog does?
> >
> > Agreed, what about the attached patch?
>
> Looks good to me.
>
> Regards
>
> Rüdiger
>

Re: Broken: apache/httpd#1667 (2.4.x - 59393dd) [ In reply to ]

rpluem at apache

Jun 4, 2021, 12:00 AM

Post #6 of 7 (407 views)

Permalink

On 6/4/21 8:35 AM, Nikita Popov wrote:
> Is it ok that we include an os-specific API into the main code, not
> into the APR project?

You mean because the patch uses pthread_sigmask / sigprocmask?
IMHO this is ok as:

1. Prefork is not OS generic.
2. APR currently does not offer what we need here. Getting an appropriate API in a stable version of APR would require
to release a new minor version of APR (1.8.x) first.
3. It would require raising the minimum version for APR in httpd to 1.8. This might be fine for trunk, but should not be
done for 2.4.x where we would like to backport this fix to.

Regards

Rüdiger

Re: Broken: apache/httpd#1667 (2.4.x - 59393dd) [ In reply to ]

npopov at cloudlinux

Jun 4, 2021, 1:20 AM

Post #7 of 7 (407 views)

Permalink

Thanks for the explanation!

On Fri, Jun 4, 2021 at 12:00 PM Ruediger Pluem <rpluem@apache.org> wrote:
>
>
>
> On 6/4/21 8:35 AM, Nikita Popov wrote:
> > Is it ok that we include an os-specific API into the main code, not
> > into the APR project?
>
> You mean because the patch uses pthread_sigmask / sigprocmask?
> IMHO this is ok as:
>
> 1. Prefork is not OS generic.
> 2. APR currently does not offer what we need here. Getting an appropriate API in a stable version of APR would require
> to release a new minor version of APR (1.8.x) first.
> 3. It would require raising the minimum version for APR in httpd to 1.8. This might be fine for trunk, but should not be
> done for 2.4.x where we would like to backport this fix to.
>
> Regards
>
> Rüdiger
>

Mailing List Archive

Mailing List Archive

Attached Files: