https://bz.apache.org/bugzilla/show_bug.cgi?id=66539
--- Comment #5 from Teodor Milkov <[email protected]> --- Hello, I see there's 2.4.57 incorporating this fix, so naturally I tried it and for my big surprise it crashed in the same way as 2.4.56 without the patch. I looked into httpd-2.4.57/modules/http2/h2_request.c and the apr_table_copy() -> apr_table_clone() fix seems to be there as expected. Here's a backtrace, which looks very much the same as in 2.4.56: #0 __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:199 #1 0x000072c28fc655f1 in apr_table_get () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0 #2 0x00001d2d6f31cafb in log_header_in (r=0x72c20813c0a0, a=0x72c28475fc08 "Referer") at mod_log_config.c:441 #3 0x00001d2d6f31e2ed in process_item (r=0x72c20813c0a0, orig=0x72c20813c0a0, item=0x72c28475fe80) at mod_log_config.c:1095 #4 0x00001d2d6f31e5b7 in config_log_transaction (r=0x72c20813c0a0, cls=0x72c28f838b00, default_format=0x72c28f8410c0) at mod_log_config.c:1168 #5 0x00001d2d6f31e7ed in multi_log_transaction (r=0x72c20813c0a0) at mod_log_config.c:1206 #6 0x00001d2d6f2a98ed in ap_run_log_transaction (r=0x72c20813c0a0) at protocol.c:2586 #7 0x00001d2d6f2bed3f in eor_bucket_cleanup (data=0x72c2081db390) at eor_bucket.c:40 #8 0x000072c28fc6d80e in apr_pool_destroy () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0 #9 0x000072c28fc6d82d in apr_pool_destroy () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0 #10 0x000072c28fc6d82d in apr_pool_destroy () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0 #11 0x000072c28fc6d82d in apr_pool_destroy () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0 #12 0x000072c28fc6d82d in apr_pool_destroy () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0 #13 0x000072c28f800605 in ?? () from /apache/modules/mod_http2.so #14 0x000072c28f7eae85 in ?? () from /apache/modules/mod_http2.so #15 0x00001d2d6f2d56ac in ap_run_pre_close_connection (c=0x72c26c11f360) at connection.c:44 #16 0x00001d2d6f2d5840 in ap_prep_lingering_close (c=0x72c26c11f360) at connection.c:101 #17 0x00001d2d6f2d58b5 in ap_start_lingering_close (c=0x72c26c11f360) at connection.c:127 #18 0x00001d2d6f37e56e in process_lingering_close (cs=0x72c26c11f2b0) at event.c:1500 #19 0x00001d2d6f37dbb7 in process_socket (thd=0x72c27f1387a8, p=0x72c26c11f028, sock=0x72c26c11f0b0, cs=0x72c26c11f2b0, my_child_num=0, my_thread_num=25) at event.c:1238 #20 0x00001d2d6f380920 in worker_thread (thd=0x72c27f1387a8, dummy=0x72c278002f50) at event.c:2179 #21 0x00001d2d6f299a78 in thread_start (thread=0x72c27f1387a8, data=0x72c27f138798) at util.c:3208 #22 0x000072c28fc30ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 #23 0x000072c28fb50a2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (gdb) dump_table r->headers_out [0] 'Last-Modified'='Wed, 28 Nov 2018 20:17:41 GMT' … (gdb) dump_table r->headers_in [0] 'Cannot access memory at address 0x72c26c0ea428 Please let me know if I can collect and provide any other useful information. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
