httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 29690] New: - allocator_free() crashes because of NULL-Pointer inside SSL_smart_shutdown()
Date Sat, 19 Jun 2004 20:41:12 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29690>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29690

allocator_free() crashes because of NULL-Pointer inside SSL_smart_shutdown()

           Summary: allocator_free() crashes because of NULL-Pointer inside
                    SSL_smart_shutdown()
           Product: Apache httpd-2.0
           Version: 2.0.49
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: mod_ssl
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: cra@gedas.de


Remark: This *may* be a duplicate of various reported bugs having to do with 
crashing worker processes under Win2K/XP with log entry "Parent: child process 
exited with status 3221225477 -- Restarting."

Description: Sometimes the winnt/child.c worker thread/process crashes in 
memory/unix/apr_pools.c, line 323 (next = node->next;) when accessing the 
server via SSL using mod_ssl with OpenSSL 0.9.7d. The worker is then restarted 
by the main process (with the error log entry above).

The error location in detail (all infos obtained using MS VC++ 6.0 debugger):

static APR_INLINE
void allocator_free(apr_allocator_t *allocator, apr_memnode_t *node)
{
/* *** (code deleted) *** */
    /* Walk the list of submitted nodes and free them one by one,
     * shoving them in the right 'size' buckets as we go.
     */
    do {
        next = node->next;     <<==== CRASHES *HERE*
        index = node->index;

The crash happens because 'node' (the second parameter) equals NULL. 
allocator_free() is called by apr_pool_clear() (same file, line 713). 
Obviously, the pool specified as the function parameter has 
   pool->active->next == NULL.

The complete stack trace is as follows:

allocator_free(apr_allocator_t * 0x0087ff88, apr_memnode_t * 0x00000000) line 
323 + 3 bytes
apr_pool_clear(apr_pool_t * 0x00ce8b80) line 713 + 18 bytes
core_output_filter(ap_filter_t * 0x00cc0d28, apr_bucket_brigade * 0x00cbdc68) 
line 4166
ap_pass_brigade(ap_filter_t * 0x00cc0d28, apr_bucket_brigade * 0x00cbdc68) line 
511 + 16 bytes
bio_filter_out_flush(bio_st * 0x00cbbbc0) line 155 + 25 bytes
bio_filter_out_write(bio_st * 0x00cbbbc0, const char * 0x00cd1e30, int 23) line 
220 + 9 bytes
BIO_write(bio_st * 0x00cbbbc0, const void * 0x00cd1e30, int 23) line 201 + 20 
bytes
ssl3_write_pending(ssl_st * 0x00cbb6c8, int 21, const unsigned char * 
0x00cbb9c4, unsigned int 2) line 742 + 50 bytes
do_ssl3_write(ssl_st * 0x00cbb6c8, int 21, const unsigned char * 0x00cbb9c4, 
unsigned int 2, int 0) line 713 + 21 bytes
ssl3_dispatch_alert(ssl_st * 0x00cbb6c8) line 1282 + 27 bytes
ssl3_send_alert(ssl_st * 0x00cbb6c8, int 1, int 0) line 1271 + 9 bytes
ssl3_shutdown(ssl_st * 0x00cbb6c8) line 1650 + 13 bytes
SSL_shutdown(ssl_st * 0x00cbb6c8) line 895 + 13 bytes
SSL_smart_shutdown(ssl_st * 0x00cbb6c8) line 188 + 9 bytes
ssl_filter_io_shutdown(ssl_filter_ctx_t * 0x00caf8e8, conn_rec * 0x00caf568, 
int 0) line 955 + 9 bytes
ssl_io_filter_cleanup(void * 0x00caf8e8) line 996 + 15 bytes
run_cleanups(cleanup_t * * 0x00caf470) line 1951 + 13 bytes
apr_pool_clear(apr_pool_t * 0x00caf460) line 693 + 12 bytes
mpm_recycle_completion_context(CompContext * 0x00ca70a8) line 81
winnt_get_connection(CompContext * 0x00ca70a8) line 637
worker_main(long 499) line 692 + 9 bytes

This error happens from "inside" mod_ssl, which corresponds to the fact that it 
does *not* occur when accessing the server through normal HTTP.

Now my question is: Is is possible or "legal" that pools exist whose 
'active->next' is set to NULL? If this is the case, the allocator_free() 
function would have to check for this. If simply tried the following: CHanged 
the beginning of the loop in allocator_free() to:

   /* Walk the list of submitted nodes and free them one by one,
     * shoving them in the right 'size' buckets as we go.
     */
    do {
        /* *** NEW *** */
        if (node == NULL)
            break;

        next = node->next;
        index = node->index;

However, after this change, the server now crashes in apr_buckets_alloc.c, line 
91 because its 'list' parameter equals NULL. Here is the full stack trace:

apr_bucket_alloc(unsigned int 40, apr_bucket_alloc_t * 0x00000000) line 91 + 3 
bytes
apr_bucket_flush_create(apr_bucket_alloc_t * 0x00000000) line 38 + 11 bytes
check_pipeline_flush(request_rec * 0x00d32260) line 211 + 13 bytes
ap_process_request(request_rec * 0x00d32260) line 269 + 9 bytes
ap_process_http_connection(conn_rec * 0x00ceed20) line 250 + 9 bytes
ap_run_process_connection(conn_rec * 0x00ceed20) line 42 + 78 bytes
ap_process_connection(conn_rec * 0x00ceed20, void * 0x00ceec50) line 177
worker_main(long 497) line 718

Apparently, I was wrong with my first assumption :-(

However, I still believe that it must have something to do with how mod_ssl 
handles memory. But I really don't understand why this kind of error is only 
observed under Windows. Hmmm.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message