date:20170121

Bug report for Apache httpd-2 [2017/01/22]

2017-01-21 Thread bugzilla

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
| 8713|Inf|Min|2002-05-01|No Errorlog on PROPFIND/Depth:Infinity|
| 8867|Opn|Cri|2002-05-07|exports.c generation fails when using a symlink to|
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11294|New|Enh|2002-07-30|desired vhost_alias option|
|11580|Opn|Enh|2002-08-09|generate Content-Location headers |
|12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long|
|13599|Inf|Nor|2002-10-14|autoindex formating broken for multibyte sequences|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|14496|New|Enh|2002-11-13|Cannot upgrade any version on Windows. Must uninst|
|14922|Inf|Enh|2002-11-28| is currently hardcoded to 'apache2'  |
|15719|Inf|Nor|2002-12-30|WebDAV MOVE to destination URI which is content-ne|
|16761|Inf|Nor|2003-02-04|CustomLog with pipe spawns process during config  |
|16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.|
|17107|New|Min|2003-02-16|Windows should not install printenv   |
|17114|New|Enh|2003-02-17|Please add strip and install-strip targets to Make|
|17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi|
|17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header|
|18325|New|Enh|2003-03-25|PAM support for suEXEC|
|18334|Inf|Cri|2003-03-25|Server crashes when authenticating users against L|
|19670|New|Enh|2003-05-05|content type header supplied upon PUT is thrown aw|
|20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment |
|21260|New|Nor|2003-07-02|CacheMaxExpire directive not enforced !   |
|21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut|
|22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down|
|22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7|
|22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header  |
|23167|Inf|Cri|2003-09-14|--enable-layout never goes to apr apr-util|
|23181|New|Nor|2003-09-15|Status 304 (Not modified) and chunking leads to an|
|23238|New|Cri|2003-09-18|non-async-signal-safe operations from signal handl|
|23330|New|Enh|2003-09-22|Enhance ApacheMonitor to view and control Tomcat s|
|23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54|
|24031|New|Enh|2003-10-23|Passphrase protected private key in SSLProxyMachin|
|24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32|
|24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact|
|24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g|
|25014|New|Enh|2003-11-26|A flexible interface for mod_log_config   |
|25201|New|Enh|2003-12-04|Provide Cache Purge operation |
|25240|Inf|Enh|2003-12-05|SSL Library Error: 336105671 logged as information|
|25435|New|Enh|2003-12-11|sethandler and directoryindex not playing nice|
|25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files  |
|25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP |
|25543|Inf|Nor|2003-12-15|mod_proxy_ajp overwrites existing response headers|
|25667|New|Nor|2003-12-19|Memory leak in function ssl_scache_dbm_retrieve().|
|25863|New|Enh|2004-01-02|new per-host initialization hooks |
|26005|New|Nor|2004-01-08|SERVER_NAME incorrect when using IPv6 address in U|
|26142|New|Maj|2004-01-14|EnableSendFile Off for Windows XP Home|
|26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability   |
|26368|New|Min|2004-01-23|File extensions in AddDescription treated as part |
|26446|New|Nor|2004-01-26|flush buckets followed by eos bucket emit multiple|
|26478|New|Enh|2004-01-28|mod_dav does not expose a method for setting the D|

Pwn2own and $200k bounty on httpd

2017-01-21 Thread Eric Covener

http://blog.trendmicro.com/pwn2own-returns-for-2017-to-celebrate-10-years-of-exploits/

Server Side

This is another new category for Pwn2Own, but one that should prove
noteworthy. A successful exploit against Apache Web Server on Ubuntu
Server will net the researcher $200,000 and earn a whopping 25 Master
of Pwn points. Considering this setup accounts for roughly half of all
websites, it’s pretty clear the impact a bug here would have. An
attempt in this category must be launched from the contestant laptops
within the contest network.

-- 
Eric Covener
cove...@gmail.com

Re: mod_http2 and Frequent wake-ups for mpm_event

2017-01-21 Thread Stefan Priebe

All last traces come from event, proces_longering_close ap_push_pool but 
end in different functions. It looks like a race somewhere and it just 
races at different function in the event of close and pool clear.


Might there be two places where the same pool gets cleared?

Stefan

Am 21.01.2017 um 19:07 schrieb Stefan Priebe:

Hi Stefan,

thanks. No crashes where h2 comes up. But i still have these and no idea
how to find out who and why they're crashing.

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/apache2/bin/httpd -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  allocator_free (node=0x0, allocator=0x7f6e08066540)
at memory/unix/apr_pools.c:381
#0  allocator_free (node=0x0, allocator=0x7f6e08066540)
at memory/unix/apr_pools.c:381
#1  apr_pool_clear (pool=0x7f6e0808d238) at memory/unix/apr_pools.c:793
#2  0x004fe528 in ap_push_pool (queue_info=0x0,
pool_to_recycle=0x7f6e08066548) at fdqueue.c:234
#3  0x004fa2c8 in process_lingering_close (cs=0x7f6e0808d4c8,
pfd=0x1d3bf98) at event.c:1439
#4  0x004fd410 in listener_thread (thd=0x1d3cb70,
dummy=0x7f6e0808d4c8)
at event.c:1704
#5  0x7f6e1aed20a4 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f6e1aa0362d in clone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) (gdb) quit

Reading symbols from /usr/local/apache/bin/httpd...Reading symbols from
/usr/lib/debug//usr/local/apache2/bin/httpd...done.
done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/apache2/bin/httpd -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  allocator_free (node=0x0, allocator=0x7f6e08053ae0)
at memory/unix/apr_pools.c:381
#0  allocator_free (node=0x0, allocator=0x7f6e08053ae0)
at memory/unix/apr_pools.c:381
#1  apr_pool_clear (pool=0x7f6e08076bb8) at memory/unix/apr_pools.c:793
#2  0x004fe528 in ap_push_pool (queue_info=0x0,
pool_to_recycle=0x7f6e08053ae8) at fdqueue.c:234
#3  0x004fa2c8 in process_lingering_close (cs=0x7f6e08076e48,
pfd=0x1d3bf98) at event.c:1439
#4  0x004fd410 in listener_thread (thd=0x1d3cb70,
dummy=0x7f6e08076e48)
at event.c:1704
#5  0x7f6e1aed20a4 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f6e1aa0362d in clone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) (gdb) quit

Stefan

Am 21.01.2017 um 17:03 schrieb Stefan Eissing:

Stefan,

made a release at https://github.com/icing/mod_h2/releases/tag/v1.8.9
with all patches and improved (hopefully) on them a bit. If you dare
to drop that into your installation, that'd be great.

Cheers,

Stefan


Am 21.01.2017 um 15:25 schrieb Stefan Priebe :

and i got another crash here:

2346 static void run_cleanups(cleanup_t **cref)
2347 {
2348 cleanup_t *c = *cref;
2349
2350 while (c) {
2351 *cref = c->next;
2352 (*c->plain_cleanup_fn)((void *)c->data);   <== here
2353 c = *cref;
2354

which looks similar to the other crash.

#0  0x7fe4bbd33e1b in run_cleanups (cref=) at
memory/unix/apr_pools.c:2352
#1  apr_pool_clear (pool=0x7fe4a804dac8) at memory/unix/apr_pools.c:772
#2  0x004feb38 in ap_push_pool
(queue_info=0x6d616e79642d3733, pool_to_recycle=0x2) at fdqueue.c:234
#3  0x004fa8d8 in process_lingering_close (cs=0x7fe4a804dd58,
pfd=0x25d3f98) at event.c:1439

Details:
(gdb) print c
$1 = (cleanup_t *) 0x7fe4a804e9f0
(gdb) print *c
$2 = {next = 0x7fe4a804e870, data = 0x6d616e79642d3733,
plain_cleanup_fn = 0x392d3734322e6369,
 child_cleanup_fn = 0x617465722e722d35}
(gdb) print *c->data
Attempt to dereference a generic pointer.
(gdb) print *c->plain_cleanup_fn
Cannot access memory at address 0x392d3734322e6369
(gdb)

Stefan

Am 21.01.2017 um 15:18 schrieb Stefan Priebe:

Hi,

#0  apr_pool_cleanup_kill (p=0x7fe4a8072358,
data=data@entry=0x7fe4a80723e0,
   cleanup_fn=cleanup_fn@entry=0x7fe4bbd38a40 ) at
memory/unix/apr_pools.c:2276

it crashes here in apr:
2276 if (c->data == data && c->plain_cleanup_fn ==
cleanup_fn) {

some lines before c becomes this
2264 c = p->cleanups;

p is:
(gdb) print *p
$1 = {parent = 0x256f138, child = 0x7fe46c0751c8, sibling =
0x7fe4a8096888, ref = 0x7fe4a8069fe8, cleanups = 0x7fe478159748,
 free_cleanups = 0x7fe478159788, allocator = 0x7fe4a803b490,
subprocesses = 0x0, abort_fn = 0x43da00 ,
 user_data = 0x0, tag = 0x502285 "transaction", active =
0x7fe478158d70, self = 0x7fe4a8072330,
 self_first_avail = 0x7fe4a80723d0 "X#\a\250\344\177", pre_cleanups =
0x7fe4a8072ab8}

wouldn't the error mean that p->cleanups is NULL?

(gdb) print *p->cleanups
$2 = {next = 0x7fe478159628, data = 0x7fe478159648, plain_cleanup_fn =
0x7fe4bbd2ffd0 ,
 child_cleanup_fn = 0x7fe4bbd2ff70 }

So p->cleanups->data is 0x7fe478159648 and data is 0x7fe4a80723e0?

I don't get

Re: mod_http2 and Frequent wake-ups for mpm_event

2017-01-21 Thread Stefan Priebe


Hi Stefan,

thanks. No crashes where h2 comes up. But i still have these and no idea 
how to find out who and why they're crashing.


Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/apache2/bin/httpd -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  allocator_free (node=0x0, allocator=0x7f6e08066540)
at memory/unix/apr_pools.c:381
#0  allocator_free (node=0x0, allocator=0x7f6e08066540)
at memory/unix/apr_pools.c:381
#1  apr_pool_clear (pool=0x7f6e0808d238) at memory/unix/apr_pools.c:793
#2  0x004fe528 in ap_push_pool (queue_info=0x0,
pool_to_recycle=0x7f6e08066548) at fdqueue.c:234
#3  0x004fa2c8 in process_lingering_close (cs=0x7f6e0808d4c8,
pfd=0x1d3bf98) at event.c:1439
#4  0x004fd410 in listener_thread (thd=0x1d3cb70, 
dummy=0x7f6e0808d4c8)

at event.c:1704
#5  0x7f6e1aed20a4 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f6e1aa0362d in clone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) (gdb) quit

Reading symbols from /usr/local/apache/bin/httpd...Reading symbols from 
/usr/lib/debug//usr/local/apache2/bin/httpd...done.

done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/apache2/bin/httpd -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  allocator_free (node=0x0, allocator=0x7f6e08053ae0)
at memory/unix/apr_pools.c:381
#0  allocator_free (node=0x0, allocator=0x7f6e08053ae0)
at memory/unix/apr_pools.c:381
#1  apr_pool_clear (pool=0x7f6e08076bb8) at memory/unix/apr_pools.c:793
#2  0x004fe528 in ap_push_pool (queue_info=0x0,
pool_to_recycle=0x7f6e08053ae8) at fdqueue.c:234
#3  0x004fa2c8 in process_lingering_close (cs=0x7f6e08076e48,
pfd=0x1d3bf98) at event.c:1439
#4  0x004fd410 in listener_thread (thd=0x1d3cb70, 
dummy=0x7f6e08076e48)

at event.c:1704
#5  0x7f6e1aed20a4 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f6e1aa0362d in clone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) (gdb) quit

Stefan

Am 21.01.2017 um 17:03 schrieb Stefan Eissing:

Stefan,

made a release at https://github.com/icing/mod_h2/releases/tag/v1.8.9 with all 
patches and improved (hopefully) on them a bit. If you dare to drop that into 
your installation, that'd be great.

Cheers,

Stefan


Am 21.01.2017 um 15:25 schrieb Stefan Priebe :

and i got another crash here:

2346 static void run_cleanups(cleanup_t **cref)
2347 {
2348 cleanup_t *c = *cref;
2349
2350 while (c) {
2351 *cref = c->next;
2352 (*c->plain_cleanup_fn)((void *)c->data);   <== here
2353 c = *cref;
2354

which looks similar to the other crash.

#0  0x7fe4bbd33e1b in run_cleanups (cref=) at 
memory/unix/apr_pools.c:2352
#1  apr_pool_clear (pool=0x7fe4a804dac8) at memory/unix/apr_pools.c:772
#2  0x004feb38 in ap_push_pool (queue_info=0x6d616e79642d3733, 
pool_to_recycle=0x2) at fdqueue.c:234
#3  0x004fa8d8 in process_lingering_close (cs=0x7fe4a804dd58, 
pfd=0x25d3f98) at event.c:1439

Details:
(gdb) print c
$1 = (cleanup_t *) 0x7fe4a804e9f0
(gdb) print *c
$2 = {next = 0x7fe4a804e870, data = 0x6d616e79642d3733, plain_cleanup_fn = 
0x392d3734322e6369,
 child_cleanup_fn = 0x617465722e722d35}
(gdb) print *c->data
Attempt to dereference a generic pointer.
(gdb) print *c->plain_cleanup_fn
Cannot access memory at address 0x392d3734322e6369
(gdb)

Stefan

Am 21.01.2017 um 15:18 schrieb Stefan Priebe:

Hi,

#0  apr_pool_cleanup_kill (p=0x7fe4a8072358,
data=data@entry=0x7fe4a80723e0,
   cleanup_fn=cleanup_fn@entry=0x7fe4bbd38a40 ) at
memory/unix/apr_pools.c:2276

it crashes here in apr:
2276 if (c->data == data && c->plain_cleanup_fn == cleanup_fn) {

some lines before c becomes this
2264 c = p->cleanups;

p is:
(gdb) print *p
$1 = {parent = 0x256f138, child = 0x7fe46c0751c8, sibling =
0x7fe4a8096888, ref = 0x7fe4a8069fe8, cleanups = 0x7fe478159748,
 free_cleanups = 0x7fe478159788, allocator = 0x7fe4a803b490,
subprocesses = 0x0, abort_fn = 0x43da00 ,
 user_data = 0x0, tag = 0x502285 "transaction", active =
0x7fe478158d70, self = 0x7fe4a8072330,
 self_first_avail = 0x7fe4a80723d0 "X#\a\250\344\177", pre_cleanups =
0x7fe4a8072ab8}

wouldn't the error mean that p->cleanups is NULL?

(gdb) print *p->cleanups
$2 = {next = 0x7fe478159628, data = 0x7fe478159648, plain_cleanup_fn =
0x7fe4bbd2ffd0 ,
 child_cleanup_fn = 0x7fe4bbd2ff70 }

So p->cleanups->data is 0x7fe478159648 and data is 0x7fe4a80723e0?

I don't get why it's segfaulting

Stefan
Am 21.01.2017 um 09:50 schrieb Yann Ylavic:

Hi Stefan,

On Sat, Jan 21, 2017 at 9:45 AM, Stefan Priebe 
wrote:


after running the whole night. These are the only ones still happening.
Should i revert the mpm patch to check whether it's the source?


Yes please,

Re: mod_http2 and Frequent wake-ups for mpm_event

2017-01-21 Thread Stefan Priebe


Am 21.01.2017 um 17:03 schrieb Stefan Eissing:

Stefan,

made a release at https://github.com/icing/mod_h2/releases/tag/v1.8.9 with all 
patches and improved (hopefully) on them a bit. If you dare to drop that into 
your installation, that'd be great.


thx it's running - will report back shortly.

Stefan


Cheers,

Stefan


Am 21.01.2017 um 15:25 schrieb Stefan Priebe :

and i got another crash here:

2346 static void run_cleanups(cleanup_t **cref)
2347 {
2348 cleanup_t *c = *cref;
2349
2350 while (c) {
2351 *cref = c->next;
2352 (*c->plain_cleanup_fn)((void *)c->data);   <== here
2353 c = *cref;
2354

which looks similar to the other crash.

#0  0x7fe4bbd33e1b in run_cleanups (cref=) at 
memory/unix/apr_pools.c:2352
#1  apr_pool_clear (pool=0x7fe4a804dac8) at memory/unix/apr_pools.c:772
#2  0x004feb38 in ap_push_pool (queue_info=0x6d616e79642d3733, 
pool_to_recycle=0x2) at fdqueue.c:234
#3  0x004fa8d8 in process_lingering_close (cs=0x7fe4a804dd58, 
pfd=0x25d3f98) at event.c:1439

Details:
(gdb) print c
$1 = (cleanup_t *) 0x7fe4a804e9f0
(gdb) print *c
$2 = {next = 0x7fe4a804e870, data = 0x6d616e79642d3733, plain_cleanup_fn = 
0x392d3734322e6369,
 child_cleanup_fn = 0x617465722e722d35}
(gdb) print *c->data
Attempt to dereference a generic pointer.
(gdb) print *c->plain_cleanup_fn
Cannot access memory at address 0x392d3734322e6369
(gdb)

Stefan

Am 21.01.2017 um 15:18 schrieb Stefan Priebe:

Hi,

#0  apr_pool_cleanup_kill (p=0x7fe4a8072358,
data=data@entry=0x7fe4a80723e0,
   cleanup_fn=cleanup_fn@entry=0x7fe4bbd38a40 ) at
memory/unix/apr_pools.c:2276

it crashes here in apr:
2276 if (c->data == data && c->plain_cleanup_fn == cleanup_fn) {

some lines before c becomes this
2264 c = p->cleanups;

p is:
(gdb) print *p
$1 = {parent = 0x256f138, child = 0x7fe46c0751c8, sibling =
0x7fe4a8096888, ref = 0x7fe4a8069fe8, cleanups = 0x7fe478159748,
 free_cleanups = 0x7fe478159788, allocator = 0x7fe4a803b490,
subprocesses = 0x0, abort_fn = 0x43da00 ,
 user_data = 0x0, tag = 0x502285 "transaction", active =
0x7fe478158d70, self = 0x7fe4a8072330,
 self_first_avail = 0x7fe4a80723d0 "X#\a\250\344\177", pre_cleanups =
0x7fe4a8072ab8}

wouldn't the error mean that p->cleanups is NULL?

(gdb) print *p->cleanups
$2 = {next = 0x7fe478159628, data = 0x7fe478159648, plain_cleanup_fn =
0x7fe4bbd2ffd0 ,
 child_cleanup_fn = 0x7fe4bbd2ff70 }

So p->cleanups->data is 0x7fe478159648 and data is 0x7fe4a80723e0?

I don't get why it's segfaulting

Stefan
Am 21.01.2017 um 09:50 schrieb Yann Ylavic:

Hi Stefan,

On Sat, Jan 21, 2017 at 9:45 AM, Stefan Priebe 
wrote:


after running the whole night. These are the only ones still happening.
Should i revert the mpm patch to check whether it's the source?


Yes please, we need to determine...

Thanks,
Yann.



Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: mod_http2 and Frequent wake-ups for mpm_event

2017-01-21 Thread Stefan Eissing

Stefan,

made a release at https://github.com/icing/mod_h2/releases/tag/v1.8.9 with all 
patches and improved (hopefully) on them a bit. If you dare to drop that into 
your installation, that'd be great.

Cheers,

Stefan

> Am 21.01.2017 um 15:25 schrieb Stefan Priebe :
> 
> and i got another crash here:
> 
> 2346 static void run_cleanups(cleanup_t **cref)
> 2347 {
> 2348 cleanup_t *c = *cref;
> 2349
> 2350 while (c) {
> 2351 *cref = c->next;
> 2352 (*c->plain_cleanup_fn)((void *)c->data);   <== here
> 2353 c = *cref;
> 2354
> 
> which looks similar to the other crash.
> 
> #0  0x7fe4bbd33e1b in run_cleanups (cref=) at 
> memory/unix/apr_pools.c:2352
> #1  apr_pool_clear (pool=0x7fe4a804dac8) at memory/unix/apr_pools.c:772
> #2  0x004feb38 in ap_push_pool (queue_info=0x6d616e79642d3733, 
> pool_to_recycle=0x2) at fdqueue.c:234
> #3  0x004fa8d8 in process_lingering_close (cs=0x7fe4a804dd58, 
> pfd=0x25d3f98) at event.c:1439
> 
> Details:
> (gdb) print c
> $1 = (cleanup_t *) 0x7fe4a804e9f0
> (gdb) print *c
> $2 = {next = 0x7fe4a804e870, data = 0x6d616e79642d3733, plain_cleanup_fn = 
> 0x392d3734322e6369,
>  child_cleanup_fn = 0x617465722e722d35}
> (gdb) print *c->data
> Attempt to dereference a generic pointer.
> (gdb) print *c->plain_cleanup_fn
> Cannot access memory at address 0x392d3734322e6369
> (gdb)
> 
> Stefan
> 
> Am 21.01.2017 um 15:18 schrieb Stefan Priebe:
>> Hi,
>> 
>> #0  apr_pool_cleanup_kill (p=0x7fe4a8072358,
>> data=data@entry=0x7fe4a80723e0,
>>cleanup_fn=cleanup_fn@entry=0x7fe4bbd38a40 ) at
>> memory/unix/apr_pools.c:2276
>> 
>> it crashes here in apr:
>> 2276 if (c->data == data && c->plain_cleanup_fn == cleanup_fn) {
>> 
>> some lines before c becomes this
>> 2264 c = p->cleanups;
>> 
>> p is:
>> (gdb) print *p
>> $1 = {parent = 0x256f138, child = 0x7fe46c0751c8, sibling =
>> 0x7fe4a8096888, ref = 0x7fe4a8069fe8, cleanups = 0x7fe478159748,
>>  free_cleanups = 0x7fe478159788, allocator = 0x7fe4a803b490,
>> subprocesses = 0x0, abort_fn = 0x43da00 ,
>>  user_data = 0x0, tag = 0x502285 "transaction", active =
>> 0x7fe478158d70, self = 0x7fe4a8072330,
>>  self_first_avail = 0x7fe4a80723d0 "X#\a\250\344\177", pre_cleanups =
>> 0x7fe4a8072ab8}
>> 
>> wouldn't the error mean that p->cleanups is NULL?
>> 
>> (gdb) print *p->cleanups
>> $2 = {next = 0x7fe478159628, data = 0x7fe478159648, plain_cleanup_fn =
>> 0x7fe4bbd2ffd0 ,
>>  child_cleanup_fn = 0x7fe4bbd2ff70 }
>> 
>> So p->cleanups->data is 0x7fe478159648 and data is 0x7fe4a80723e0?
>> 
>> I don't get why it's segfaulting
>> 
>> Stefan
>> Am 21.01.2017 um 09:50 schrieb Yann Ylavic:
>>> Hi Stefan,
>>> 
>>> On Sat, Jan 21, 2017 at 9:45 AM, Stefan Priebe 
>>> wrote:
 
 after running the whole night. These are the only ones still happening.
 Should i revert the mpm patch to check whether it's the source?
>>> 
>>> Yes please, we need to determine...
>>> 
>>> Thanks,
>>> Yann.
>>> 

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: mod_http2 and Frequent wake-ups for mpm_event

2017-01-21 Thread Stefan Priebe


and i got another crash here:

2346 static void run_cleanups(cleanup_t **cref)
2347 {
2348 cleanup_t *c = *cref;
2349
2350 while (c) {
2351 *cref = c->next;
2352 (*c->plain_cleanup_fn)((void *)c->data);   <== here
2353 c = *cref;
2354

which looks similar to the other crash.

#0  0x7fe4bbd33e1b in run_cleanups (cref=) at 
memory/unix/apr_pools.c:2352

#1  apr_pool_clear (pool=0x7fe4a804dac8) at memory/unix/apr_pools.c:772
#2  0x004feb38 in ap_push_pool (queue_info=0x6d616e79642d3733, 
pool_to_recycle=0x2) at fdqueue.c:234
#3  0x004fa8d8 in process_lingering_close (cs=0x7fe4a804dd58, 
pfd=0x25d3f98) at event.c:1439


Details:
(gdb) print c
$1 = (cleanup_t *) 0x7fe4a804e9f0
(gdb) print *c
$2 = {next = 0x7fe4a804e870, data = 0x6d616e79642d3733, plain_cleanup_fn 
= 0x392d3734322e6369,

  child_cleanup_fn = 0x617465722e722d35}
(gdb) print *c->data
Attempt to dereference a generic pointer.
(gdb) print *c->plain_cleanup_fn
Cannot access memory at address 0x392d3734322e6369
(gdb)

Stefan

Am 21.01.2017 um 15:18 schrieb Stefan Priebe:

Hi,

#0  apr_pool_cleanup_kill (p=0x7fe4a8072358,
data=data@entry=0x7fe4a80723e0,
cleanup_fn=cleanup_fn@entry=0x7fe4bbd38a40 ) at
memory/unix/apr_pools.c:2276

it crashes here in apr:
2276 if (c->data == data && c->plain_cleanup_fn == cleanup_fn) {

some lines before c becomes this
2264 c = p->cleanups;

p is:
(gdb) print *p
$1 = {parent = 0x256f138, child = 0x7fe46c0751c8, sibling =
0x7fe4a8096888, ref = 0x7fe4a8069fe8, cleanups = 0x7fe478159748,
  free_cleanups = 0x7fe478159788, allocator = 0x7fe4a803b490,
subprocesses = 0x0, abort_fn = 0x43da00 ,
  user_data = 0x0, tag = 0x502285 "transaction", active =
0x7fe478158d70, self = 0x7fe4a8072330,
  self_first_avail = 0x7fe4a80723d0 "X#\a\250\344\177", pre_cleanups =
0x7fe4a8072ab8}

wouldn't the error mean that p->cleanups is NULL?

(gdb) print *p->cleanups
$2 = {next = 0x7fe478159628, data = 0x7fe478159648, plain_cleanup_fn =
0x7fe4bbd2ffd0 ,
  child_cleanup_fn = 0x7fe4bbd2ff70 }

So p->cleanups->data is 0x7fe478159648 and data is 0x7fe4a80723e0?

I don't get why it's segfaulting

Stefan
Am 21.01.2017 um 09:50 schrieb Yann Ylavic:

Hi Stefan,

On Sat, Jan 21, 2017 at 9:45 AM, Stefan Priebe 
wrote:


after running the whole night. These are the only ones still happening.
Should i revert the mpm patch to check whether it's the source?


Yes please, we need to determine...

Thanks,
Yann.

Re: mod_http2 and Frequent wake-ups for mpm_event

2017-01-21 Thread Stefan Priebe


Hi,

#0  apr_pool_cleanup_kill (p=0x7fe4a8072358, 
data=data@entry=0x7fe4a80723e0,
cleanup_fn=cleanup_fn@entry=0x7fe4bbd38a40 ) at 
memory/unix/apr_pools.c:2276


it crashes here in apr:
2276 if (c->data == data && c->plain_cleanup_fn == cleanup_fn) {

some lines before c becomes this
2264 c = p->cleanups;

p is:
(gdb) print *p
$1 = {parent = 0x256f138, child = 0x7fe46c0751c8, sibling = 
0x7fe4a8096888, ref = 0x7fe4a8069fe8, cleanups = 0x7fe478159748,
  free_cleanups = 0x7fe478159788, allocator = 0x7fe4a803b490, 
subprocesses = 0x0, abort_fn = 0x43da00 ,
  user_data = 0x0, tag = 0x502285 "transaction", active = 
0x7fe478158d70, self = 0x7fe4a8072330,
  self_first_avail = 0x7fe4a80723d0 "X#\a\250\344\177", pre_cleanups = 
0x7fe4a8072ab8}


wouldn't the error mean that p->cleanups is NULL?

(gdb) print *p->cleanups
$2 = {next = 0x7fe478159628, data = 0x7fe478159648, plain_cleanup_fn = 
0x7fe4bbd2ffd0 ,

  child_cleanup_fn = 0x7fe4bbd2ff70 }

So p->cleanups->data is 0x7fe478159648 and data is 0x7fe4a80723e0?

I don't get why it's segfaulting

Stefan
Am 21.01.2017 um 09:50 schrieb Yann Ylavic:

Hi Stefan,

On Sat, Jan 21, 2017 at 9:45 AM, Stefan Priebe  wrote:


after running the whole night. These are the only ones still happening.
Should i revert the mpm patch to check whether it's the source?


Yes please, we need to determine...

Thanks,
Yann.

Re: mod_http2 and Frequent wake-ups for mpm_event

2017-01-21 Thread Stefan Priebe


Hi Yann,

looks better so far. This is the only one i got without mpm patch:
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/apache2/bin/httpd -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  apr_pool_cleanup_kill (p=0x7fe4a808b538, 
data=data@entry=0x7fe4a808b5c0,

cleanup_fn=cleanup_fn@entry=0x7fe4bbd38a40 )
at memory/unix/apr_pools.c:2276
#0  apr_pool_cleanup_kill (p=0x7fe4a808b538, 
data=data@entry=0x7fe4a808b5c0,

cleanup_fn=cleanup_fn@entry=0x7fe4bbd38a40 )
at memory/unix/apr_pools.c:2276
#1  0x7fe4bbd34e91 in apr_pool_cleanup_run (p=,
data=0x7fe4a808b5c0, cleanup_fn=0x7fe4bbd38a40 )
at memory/unix/apr_pools.c:2342
#2  0x7fe4bbd38d22 in apr_socket_close (thesocket=)
at network_io/unix/sockets.c:183
#3  0x004fa88f in process_lingering_close (cs=0x7fe4a808b7c8,
pfd=0x25d3f98) at event.c:1432
#4  0x004fda20 in listener_thread (thd=0x25d4b70, 
dummy=0x7fe4a808b7c8)

at event.c:1704
#5  0x7fe4bb4bf0a4 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7fe4baff062d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Stefan

Am 21.01.2017 um 09:50 schrieb Yann Ylavic:

Hi Stefan,

On Sat, Jan 21, 2017 at 9:45 AM, Stefan Priebe  wrote:


after running the whole night. These are the only ones still happening.
Should i revert the mpm patch to check whether it's the source?


Yes please, we need to determine...

Thanks,
Yann.

Re: HTTP/2 frame prioritization not honored

2017-01-21 Thread Stefan Eissing


> Am 20.01.2017 um 03:57 schrieb Kyriakos Zarifis :
> 
> * ... and by "here" I meant "here" 

:)

> On Thu, Jan 19, 2017 at 6:54 PM, Kyriakos Zarifis  
> wrote:
> Sounds great!
> 
> 
> Very interested. I'd like to add a page over at 
> https://icing.github.io/mod_h2/ about it, so that people can easily grasp 
> what the advantages are. For that, your numbers (do you have screenshots of 
> browser timelines maybe?) would be very welcome. Also that someone besides 
> the module author has measured it adds credibility. :-)
> 
> If you write yourself somewhere about it, I am happy to link that.
> 
> Since anything I write would be incomplete without your description of what 
> caused it and how you resolved it, I put together a WIP write up here, with 
> screenshots / link to logs*. Feel free to use it as you want or let me know 
> if you'd like more details; I'm happy to help write the complete story for a 
> page on https://icing.github.io/mod_h2/ , which is probably the most 
> reasonable place to gather the relevant bits.
> 
> Cheers
> 
> 
> 
> * I rerun the tests to capture timeline screenshots, so the server-logs don't 
> exactly correspond to those screenshots, but the behaviors were the same
> * Note that the delays in the timeline pictures are worse than those seen on 
> server logs, which have been more helpful for understanding application-layer 
> behavior. I think what's causing this is a bloated output buffer in the case 
> where the server aggressively writes low-prio data (verified this by 
> monitoring the buffer size which keeps increasing during the test)

Certainly an area to improve upon. mod_http2 is still writing so much into the 
socket that responsiveness suffers. This gives the best throughput performance, 
though. I know that the h2o server guys also experimented with interrogating 
TCP windows to prevent bloat. Have to look at that again.

Cheers,

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: JSON for mod_status

2017-01-21 Thread Marion & Christophe JAILLET


++1

:)


Author: jailletc36
Date: Fri Jan  6 07:19:20 2017
New Revision: 1777535

URL:http://svn.apache.org/viewvc?rev=1777535=rev
Log:
update

Modified:
httpd/httpd/trunk/STATUS

Modified: httpd/httpd/trunk/STATUS
URL:http://svn.apache.org/viewvc/httpd/httpd/trunk/STATUS?rev=1777535=1777534=1777535=diff
==
--- httpd/httpd/trunk/STATUS (original)
+++ httpd/httpd/trunk/STATUS Fri Jan  6 07:19:20 2017
@@ -140,6 +140,14 @@ THINGS THAT SHOULD BE CONSIDERED EARLY I
   * REST-based administration for existing (balancer/etc) and new dynamic
 runtime changes (see above)
 
+  * Improve the look of generated pages (status, load-balancer...) with dynamic

+update of the values. Generate HTML5 pages, instead of 3.2, Get rid of 
XHTML
+in the generated pages.
+
+  * Add performance monitoring of the server, of each module (?), in order to 
help
+understanding what worth looking at in order to improve overall 
performance.
+
(https://cdn.wp.nginx.com/wp-content/uploads/2016/12/Amplify-Dashboards-page-base-for-filters.png)
+
 OLD ISSUES THAT WERE THOUGHT TO BE SHOWSTOPPERS FOR 2.4 BUT OBVIOUSLY WEREN'T:
 
   * Handling of non-trailing / config by non-default handler is broken




Le 18/01/2017 à 10:56, Daniel Gruno a écrit :

On 01/17/2017 07:33 PM, Jim Jagielski wrote:

It all depends on what Bill decides regarding mod_bmx and if
it is something we intent to backport to 2.4.x

Still not sure on how to *use* BMX, or how other modules
"hook in" (right now we have several modules hook into
mod_status so the "how" is well known and documented), so
I would require some sort of docs in addition to the actual
code, of course.

Some JFDI in the meantime; https://httpd.apache.org/server-status :)
JSON: http://httpd.apache.org/server-status?view=json_status

With regards,
Daniel.


On Jan 17, 2017, at 12:35 PM, Luca Toscano  wrote:



2016-11-30 18:54 GMT+01:00 Jim Jagielski :
I'm thinking about adding JSON support to mod_status...
the "plain" version output really stinks and lacks parity
w/ the info we provide via HTML, and it would be nice
to produce a really easily parseable format.

Thoughts...?

I know it was extensively discussed, but do we have an agreement about a plan 
to add this feature?  :)

Luca

Re: svn commit: r1779700 - /httpd/httpd/trunk/modules/filters/mod_brotli.c

2017-01-21 Thread Yann Ylavic

Hi,

On Sat, Jan 21, 2017 at 7:40 AM,   wrote:
> Author: jailletc36
> Date: Sat Jan 21 06:40:23 2017
> New Revision: 1779700
>
> URL: http://svn.apache.org/viewvc?rev=1779700=rev
> Log:
> Save a few bytes and a few cycles.
>
> Modified:
> httpd/httpd/trunk/modules/filters/mod_brotli.c
>
> Modified: httpd/httpd/trunk/modules/filters/mod_brotli.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_brotli.c?rev=1779700=1779699=1779700=diff
> ==
> --- httpd/httpd/trunk/modules/filters/mod_brotli.c (original)
> +++ httpd/httpd/trunk/modules/filters/mod_brotli.c Sat Jan 21 06:40:23 2017
> @@ -443,9 +443,9 @@ static apr_status_t compress_filter(ap_f
>  apr_size_t len = strlen(etag);
>
>  if (len > 2 && etag[len - 1] == '"') {
> -etag = apr_pstrndup(r->pool, etag, len - 1);
> +etag = apr_pstrmemdup(r->pool, etag, len - 1);
>  etag = apr_pstrcat(r->pool, etag, "-br\"", NULL);

We could possibly save more bytes yet with something like:
   etag = apr_psnprintf(r->pool, etag, "%.*s-br\"",
(int)(len - 1), etag);

Regards,
Yann.

Re: mod_http2 and Frequent wake-ups for mpm_event

2017-01-21 Thread Yann Ylavic

Hi Stefan,

On Sat, Jan 21, 2017 at 9:45 AM, Stefan Priebe  wrote:
>
> after running the whole night. These are the only ones still happening.
> Should i revert the mpm patch to check whether it's the source?

Yes please, we need to determine...

Thanks,
Yann.

Re: mod_http2 and Frequent wake-ups for mpm_event

2017-01-21 Thread Stefan Priebe


Hi,

after running the whole night. These are the only ones still happening. 
Should i revert the mpm patch to check whether it's the source? I'm only 
seeing one related to mod_http2.


[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/apache2/bin/httpd -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  apr_pool_cleanup_kill (p=0x7f128c039378, 
data=data@entry=0x7f128c039400,

cleanup_fn=cleanup_fn@entry=0x7f129fe89a40 )
at memory/unix/apr_pools.c:2276
#0  apr_pool_cleanup_kill (p=0x7f128c039378, 
data=data@entry=0x7f128c039400,

cleanup_fn=cleanup_fn@entry=0x7f129fe89a40 )
at memory/unix/apr_pools.c:2276
#1  0x7f129fe85e91 in apr_pool_cleanup_run (p=,
data=0x7f128c039400, cleanup_fn=0x7f129fe89a40 )
at memory/unix/apr_pools.c:2342
#2  0x7f129fe89d22 in apr_socket_close (thesocket=)
at network_io/unix/sockets.c:183
#3  0x004fa54e in process_lingering_close (cs=0x7f128c039608,
pfd=0x1a4afa8) at event.c:1510
#4  0x004fdc30 in listener_thread (thd=0x7f128c039378,
dummy=0x7f128c039608) at event.c:1837
#5  0x7f129f6100a4 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f129f14162d in clone () from /lib/x86_64-linux-gnu/libc.so.6


Reading symbols from /usr/local/apache/bin/httpd...Reading symbols from 
/usr/lib/debug//usr/local/apache2/bin/httpd...done.

done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/apache2/bin/httpd -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  apr_pool_cleanup_kill (p=0x7f128c075f88, 
data=data@entry=0x7f128c076010,

cleanup_fn=cleanup_fn@entry=0x7f129fe89a40 )
at memory/unix/apr_pools.c:2276
#0  apr_pool_cleanup_kill (p=0x7f128c075f88, 
data=data@entry=0x7f128c076010,

cleanup_fn=cleanup_fn@entry=0x7f129fe89a40 )
at memory/unix/apr_pools.c:2276
#1  0x7f129fe85e91 in apr_pool_cleanup_run (p=,
data=0x7f128c076010, cleanup_fn=0x7f129fe89a40 )
at memory/unix/apr_pools.c:2342
#2  0x7f129fe89d22 in apr_socket_close (thesocket=)
at network_io/unix/sockets.c:183
#3  0x004fa54e in process_lingering_close (cs=0x7f128c076218,
pfd=0x1a4afa8) at event.c:1510
#4  0x004fdc30 in listener_thread (thd=0x7f128c075f88,
dummy=0x7f128c076218) at event.c:1837
#5  0x7f129f6100a4 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f129f14162d in clone () from /lib/x86_64-linux-gnu/libc.so.6


Reading symbols from /usr/local/apache/bin/httpd...Reading symbols from 
/usr/lib/debug//usr/local/apache2/bin/httpd...done.

done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/apache2/bin/httpd -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f12a02ce832 in apr_bucket_free (mem=0x7f11d802d838)
at buckets/apr_buckets_alloc.c:200
#0  0x7f12a02ce832 in apr_bucket_free (mem=0x7f11d802d838)
at buckets/apr_buckets_alloc.c:200
#1  0x7f12a02ced97 in heap_bucket_destroy (data=0x7f11d00769c8)
at buckets/apr_buckets_heap.c:36
#2  0x0045b9d3 in writev_nonblocking (s=0x7f128c086b20,
vec=0x7f12837ed890, nvec=4, bb=0x7f128c087378,
cumulative_bytes_written=0x7f11d007f7e8, c=0x7f128c086db8)
at core_filters.c:796
#3  0x0045bba1 in send_brigade_nonblocking (s=0x7f128c086b20,
bb=0x7f128c087378, bytes_written=0x76ce00 ,
c=0x7f128c087380) at core_filters.c:704
#4  0x0045c996 in ap_core_output_filter (f=0x7f11d802d838,
new_bb=0x7f128c087378) at core_filters.c:556
#5  0x004aac18 in bio_filter_out_pass (
outctx=outctx@entry=0x7f128c087358) at ssl_engine_io.c:139
#6  0x004aacbe in bio_filter_out_write (bio=,
in=0x7f11d803b8a3 "\027\003\003\005,\f\037h<5-O\005\272", inl=1329)
at ssl_engine_io.c:234
#7  0x7f12a0cc124c in BIO_write ()
   from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#8  0x7f12a1024fe2 in ?? () from 
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
#9  0x7f12a10256c5 in ?? () from 
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

#10 0x004ae04a in ssl_filter_write (f=,
f=, len=, data=)
at ssl_engine_io.c:793
#11 ssl_io_filter_output (f=0x7f128c087330, bb=0x7f11d007f898)
at ssl_engine_io.c:1746
#12 0x004ab30a in ssl_io_filter_coalesce (f=0x7f11d802d838,
bb=0x7f11d007f898) at ssl_engine_io.c:1663
#13 0x004db9ed in pass_output (io=0x7f11d0026148, session_eoc=0x0,
flush=) at h2_conn_io.c:296
#14 0x004dbf20 in h2_conn_io_flush (io=0x7f11d0026148)
at h2_conn_io.c:346
#15 0x004d012d in h2_session_process (session=0x7f11d0026100, 
async=1)

at h2_session.c:2248
#16 0x004bf641 in

Bug report for Apache httpd-2 [2017/01/22]

Pwn2own and $200k bounty on httpd

Re: mod_http2 and Frequent wake-ups for mpm_event

Re: mod_http2 and Frequent wake-ups for mpm_event

Re: mod_http2 and Frequent wake-ups for mpm_event

Re: mod_http2 and Frequent wake-ups for mpm_event

Re: mod_http2 and Frequent wake-ups for mpm_event

Re: mod_http2 and Frequent wake-ups for mpm_event

Re: mod_http2 and Frequent wake-ups for mpm_event

Re: HTTP/2 frame prioritization not honored

Re: JSON for mod_status

Re: svn commit: r1779700 - /httpd/httpd/trunk/modules/filters/mod_brotli.c

Re: mod_http2 and Frequent wake-ups for mpm_event

Re: mod_http2 and Frequent wake-ups for mpm_event

14 matches

Site Navigation

Mail list logo

Footer information