Bug 23238 - non-async-signal-safe operations from signal handlers
Summary: non-async-signal-safe operations from signal handlers
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mpm_prefork (show other bugs)
Version: 2.0-HEAD
Hardware: All All
: P3 critical (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: MassUpdate
: 50702 (view as bug list)
Depends on:
Reported: 2003-09-18 08:43 UTC by Stas Bekman
Modified: 2018-11-07 21:08 UTC (History)
2 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Stas Bekman 2003-09-18 08:43:37 UTC
Apache::Test kills httpd when all the tests were completed with 'kill TERM
$pid'. Everything is fine unless one of the cleanup handlers is still running.
If that's the case apr_pool_clear segfaults with the following trace:

#0  allocator_free (allocator=0x885c110, node=0x0) at apr_pools.c:361
361             next = node->next;
(gdb) where
#0  allocator_free (allocator=0x885c110, node=0x0) at apr_pools.c:361
#1  0x402675f4 in apr_pool_clear (pool=0x8aa86a0) at apr_pools.c:738
#2  0x080c1549 in child_main (child_num_arg=142983440) at prefork.c:613
#3  0x080c1821 in make_child (s=0x811ca60, slot=0) at prefork.c:788
#4  0x080c189e in startup_children (number_to_start=1) at prefork.c:806
#5  0x080c1f0d in ap_mpm_run (_pconf=0x8117a78, plog=0x815db90, s=0x0)
    at prefork.c:1022
#6  0x080c712a in main (argc=7, argv=0xbffff3a4) at main.c:660
#7  0x4034dc57 in __libc_start_main () from /lib/i686/libc.so.6

first of all it shouldn't segfault. 

second, shouldn't it wait for the cleanup handler to finish? Consider that the
cleanup handler is doing some critical job? I've noticed this problem with
Apache::Test but it doesn't go away if you run the normal server...
Comment 1 Joe Orton 2004-01-25 17:56:15 UTC
The problem is simply that the SIGTERM handler invokes apr_pool_clear via
child_main_exit, and apr_pool_clear is not async-signal-safe by any means.  So
if the child was already doing some pool operation when the signal handler was
invoked, all bets are off.

(1.3 ignored alarms during pool operations to avoid this)
Comment 2 Thomas Jarosch 2004-04-05 17:40:30 UTC
I see the same problem running a 2.0.49 server + openssl-0.9.6m. 
Here is a complete backtrace of the segfault after sending the http process a 
HUP signal (after serving a SSL page): 
#0  0x401dde81 in allocator_free (allocator=0x81aee20, node=0x0) 
at /usr/src/redhat/BUILD/httpd-2.0.49/srclib/apr/memory/unix/apr_pools.c:323 
#1  0x401dcd3d in apr_pool_clear (pool=0x81fbae0) 
at /usr/src/redhat/BUILD/httpd-2.0.49/srclib/apr/memory/unix/apr_pools.c:713 
#2  0x0807e8e4 in core_output_filter (f=0x81b9dc0, b=0x81fbb18) 
at /usr/src/redhat/BUILD/httpd-2.0.49/server/core.c:4163 
#3  0x0807474e in ap_pass_brigade (next=0x81b9dc0, bb=0x81bcd40) 
at /usr/src/redhat/BUILD/httpd-2.0.49/server/util_filter.c:511 
#4  0x4095c358 in bio_filter_out_flush (bio=0x815f6c0) 
at /usr/src/redhat/BUILD/httpd-2.0.49/modules/ssl/ssl_engine_io.c:154 
#5  0x4095c4f4 in bio_filter_out_write (bio=0x815f6c0, in=0x81c8cd0 
"\025\003", inl=23) 
    at /usr/src/redhat/BUILD/httpd-2.0.49/modules/ssl/ssl_engine_io.c:220 
#6  0x400c59e5 in BIO_write (b=0x0, in=0x0, inl=1074122364) at bio_lib.c:200 
#7  0x40040918 in ssl3_write_pending (s=0x81d7a20, type=136052968, 
buf=0x4005ce7c "\210m\003", len=1074006047) at s3_pkt.c:740 
#8  0x4004081f in do_ssl3_write (s=0x81c8cd5, type=136088789, buf=0x4005ce7c 
"\210m\003", len=1074010422, create_empty_fragment=136052424) at s3_pkt.c:713 
#9  0x40041936 in ssl3_dispatch_alert (s=0xbfffee8c) at s3_pkt.c:1272 
#10 0x400418e6 in ssl3_send_alert (s=0x403485a4, level=1077178560, 
desc=1074122364) at s3_pkt.c:1261 
#11 0x4003dd23 in ssl3_shutdown (s=0x10000) at s3_lib.c:1240 
#12 0x40048053 in SSL_shutdown (s=0x81d6e60) at ssl_lib.c:789 
#13 0x4096caa9 in SSL_smart_shutdown (ssl=0x81bfec8) 
at /usr/src/redhat/BUILD/httpd-2.0.49/modules/ssl/ssl_util_ssl.c:188 
#14 0x4095d3f4 in ssl_filter_io_shutdown (filter_ctx=0x81b1378, c=0x81b0f98, 
    at /usr/src/redhat/BUILD/httpd-2.0.49/modules/ssl/ssl_engine_io.c:955 
#15 0x4095d513 in ssl_io_filter_cleanup (data=0x81b1378) 
at /usr/src/redhat/BUILD/httpd-2.0.49/modules/ssl/ssl_engine_io.c:996 
#16 0x401dd779 in run_cleanups (cref=0x81b0eb8) 
at /usr/src/redhat/BUILD/httpd-2.0.49/srclib/apr/memory/unix/apr_pools.c:1951 
#17 0x401dcd97 in apr_pool_destroy (pool=0x81b0ea8) 
at /usr/src/redhat/BUILD/httpd-2.0.49/srclib/apr/memory/unix/apr_pools.c:730 
#18 0x401dcd83 in apr_pool_destroy (pool=0x81aeea0) 
at /usr/src/redhat/BUILD/httpd-2.0.49/srclib/apr/memory/unix/apr_pools.c:727 
#19 0x08064b13 in clean_child_exit (code=0) 
at /usr/src/redhat/BUILD/httpd-2.0.49/server/mpm/prefork/prefork.c:192 
#20 0x08064d7f in just_die (sig=1) 
at /usr/src/redhat/BUILD/httpd-2.0.49/server/mpm/prefork/prefork.c:324 
#21 <signal handler called> 
#22 0x40303f40 in __poll (fds=0xbffff260, nfds=1, timeout=15000) 
at ../sysdeps/unix/sysv/linux/poll.c:45 
#23 0x401de566 in apr_poll (aprset=0xbffff2f0, num=1, nsds=0xbffff2e8, 
at /usr/src/redhat/BUILD/httpd-2.0.49/srclib/apr/poll/unix/poll.c:129 
#24 0x401deade in apr_wait_for_io_or_timeout (f=0x0, s=0x81b0ee0, for_read=1) 
at /usr/src/redhat/BUILD/httpd-2.0.49/srclib/apr/support/unix/waitio.c:53 
#25 0x401d4802 in apr_socket_recv (sock=0x81b0ee0, 
    buf=0x81bdd88 "HTTP/1.1 304 Not Modified\r\nDate: Mon, 05 Apr 2004 
17:29:19 GMT\r\nServer: Apache/2.0.49 (Unix) PHP/4.3.4 mod_ssl/2.0.49 
OpenSSL/0.9.6m\r\nConnection: Keep-Alive\r\nKeep-Alive: timeout=15, 
max=99\r\nETag: \"5ee"..., len=0xbffff3dc) 
    at /usr/src/redhat/BUILD/httpd-2.0.49/srclib/apr/network_io/unix/sendrecv.c:86 
#26 0x40153546 in socket_bucket_read (a=0x81b57d0, str=0xbffff3e0, 
len=0xbffff3dc, block=APR_BLOCK_READ) 
    at /usr/src/redhat/BUILD/httpd-2.0.49/srclib/apr-util/buckets/apr_buckets_socket.c:35 
#27 0x0807daf2 in core_input_filter (f=0x81b9da8, b=0x81b9d68, 
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=5) 
    at /usr/src/redhat/BUILD/httpd-2.0.49/server/core.c:3729 
#28 0x080746aa in ap_get_brigade (next=0x81b9da8, bb=0x81b9d68, 
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=5) 
    at /usr/src/redhat/BUILD/httpd-2.0.49/server/util_filter.c:474 
#29 0x4095ca42 in bio_filter_in_read (bio=0x81bdd18, in=0x81c04c0 "\027\003", 
    at /usr/src/redhat/BUILD/httpd-2.0.49/modules/ssl/ssl_engine_io.c:485 
#30 0x400c588f in BIO_read (b=0x0, out=0x40978d1c, outl=1074122364) at 
#31 0x4003fa8e in ssl3_read_n (s=0x0, n=136311980, max=1074122364, 
extend=1074003031) at s3_pkt.c:196 
#32 0x4003fc57 in ssl3_get_record (s=0x0) at s3_pkt.c:264 
#33 0x40040c30 in ssl3_read_bytes (s=0x4005ce7c, type=1073786496, 
buf=0xbffffb34 "2üÿ¿", len=1073995636, peek=136052424) at s3_pkt.c:853 
#34 0x4003df74 in ssl3_read_internal (s=0x0, buf=0x4005ce7c, len=-1073744232, 
peek=1073995556) at s3_lib.c:1325 
#35 0x4003dff3 in ssl3_read (s=0x81bffa0, buf=0x0, len=135991192) at 
#36 0x40047e88 in SSL_read (s=0x0, buf=0x40978d1c, num=1083673884) at 
#37 0x4095cc79 in ssl_io_input_read (inctx=0x81b7d20, 
    buf=0x81b7d48 "\r\nst: intratest.net.local\r\n\r\n: 
intratest.net.local\r\n\r\npt-Language: en, de\r\nHost: 
intratest.net.local\r\n\r\nept-Language: en, de\r\nHost: 
intratest.net.local\r\n\r\n *;q=0.5\r\nAccept-Language: en, de\r\nHost: 
intr"..., len=0xbffff6c8) 
    at /usr/src/redhat/BUILD/httpd-2.0.49/modules/ssl/ssl_engine_io.c:597 
#38 0x4095ced2 in ssl_io_input_getline (inctx=0x81b7d20, 
    buf=0x81b7d48 "\r\nst: intratest.net.local\r\n\r\n: 
intratest.net.local\r\n\r\npt-Language: en, de\r\nHost: 
intratest.net.local\r\n\r\nept-Language: en, de\r\nHost: 
intratest.net.local\r\n\r\n *;q=0.5\r\nAccept-Language: en, de\r\nHost: 
intr"..., len=0xbffff708) 
    at /usr/src/redhat/BUILD/httpd-2.0.49/modules/ssl/ssl_engine_io.c:712 
#39 0x4095dbc5 in ssl_io_filter_input (f=0x81b9d50, bb=0x81fe7b0, 
mode=AP_MODE_GETLINE, block=APR_BLOCK_READ, readbytes=0) 
    at /usr/src/redhat/BUILD/httpd-2.0.49/modules/ssl/ssl_engine_io.c:1228 
#40 0x080746aa in ap_get_brigade (next=0x81b9d50, bb=0x81fe7b0, 
mode=AP_MODE_GETLINE, block=APR_BLOCK_READ, readbytes=0) 
---Type <return> to continue, or q <return> to quit--- 
    at /usr/src/redhat/BUILD/httpd-2.0.49/server/util_filter.c:474 
#41 0x0807d6cc in net_time_filter (f=0x81fe750, b=0x81fe7b0, 
mode=AP_MODE_GETLINE, block=APR_BLOCK_READ, readbytes=0) 
    at /usr/src/redhat/BUILD/httpd-2.0.49/server/core.c:3564 
#42 0x080746aa in ap_get_brigade (next=0x81fe750, bb=0x81fe7b0, 
mode=AP_MODE_GETLINE, block=APR_BLOCK_READ, readbytes=0) 
    at /usr/src/redhat/BUILD/httpd-2.0.49/server/util_filter.c:474 
#43 0x080759e2 in ap_rgetline_core (s=0x81fdb38, n=8192, read=0xbffff87c, 
r=0x81fdb20, fold=0, bb=0x81fe7b0) 
    at /usr/src/redhat/BUILD/httpd-2.0.49/server/protocol.c:214 
#44 0x08076028 in read_request_line (r=0x81fdb20, bb=0x81fe7b0) 
at /usr/src/redhat/BUILD/httpd-2.0.49/server/protocol.c:581 
#45 0x08076841 in ap_read_request (conn=0x81b0f98) 
at /usr/src/redhat/BUILD/httpd-2.0.49/server/protocol.c:858 
#46 0x0805e2ff in ap_process_http_connection (c=0x81b0f98) 
at /usr/src/redhat/BUILD/httpd-2.0.49/modules/http/http_core.c:243 
#47 0x08071d12 in ap_run_process_connection (c=0x81b0f98) 
at /usr/src/redhat/BUILD/httpd-2.0.49/server/connection.c:42 
#48 0x08072100 in ap_process_connection (c=0x81b0f98, csd=0x81b0ee0) 
at /usr/src/redhat/BUILD/httpd-2.0.49/server/connection.c:175 
#49 0x08065534 in child_main (child_num_arg=1) 
at /usr/src/redhat/BUILD/httpd-2.0.49/server/mpm/prefork/prefork.c:609 
#50 0x080656be in make_child (s=0x80a5dc8, slot=1) 
at /usr/src/redhat/BUILD/httpd-2.0.49/server/mpm/prefork/prefork.c:703 
#51 0x08065733 in startup_children (number_to_start=4) 
at /usr/src/redhat/BUILD/httpd-2.0.49/server/mpm/prefork/prefork.c:721 
#52 0x08065b3c in ap_mpm_run (_pconf=0x80a4028, plog=0x80ce0d0, s=0x80a5dc8) 
at /usr/src/redhat/BUILD/httpd-2.0.49/server/mpm/prefork/prefork.c:940 
#53 0x0806c721 in main (argc=1, argv=0xbffffb34) 
at /usr/src/redhat/BUILD/httpd-2.0.49/server/main.c:617 
Comment 3 Joe Orton 2004-04-05 17:51:34 UTC
That's a different issue Thomas, bug 27945 has the fix.
Comment 4 Thomas Jarosch 2004-04-05 18:33:38 UTC
Thank you -very- much for the quick response :-) 
Comment 5 Joe Orton 2004-06-04 13:36:29 UTC
The bug here remains that the prefork MPM calls async-signal-unsafe pool 
functions from a signal handler; so really, the only place to solve this in the
MPM, maybe using Colm's "graceful shutdown" plan.  (applies to worker too, I guess)
Comment 6 Joe Orton 2006-11-28 06:21:43 UTC
Graceful stop doesn't solve this unfortunately, since it still uses
non-async-signal-safe operations from the signal handler :(
Comment 7 Joe Orton 2011-02-02 08:50:44 UTC
*** Bug 50702 has been marked as a duplicate of this bug. ***
Comment 8 William A. Rowe Jr. 2018-11-07 21:08:01 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.