Re: t/apr/bucket is dumping core on me

Thu, 07 Oct 2004 15:04:08 -0700



Joe Schaefer wrote: 
"Philippe M. Chiasson" <[EMAIL PROTECTED]> writes:

[...]


#2  0x0021b45c in apr_bucket_alloc_create_ex (allocator=0x0) at
apr_buckets_alloc.c:67
#3  0x0021b405 in apr_bucket_alloc_create (p=0x9353f70) at



APU_DECLARE_NONSTD(apr_bucket_alloc_t *) apr_bucket_alloc_create(apr_pool_t *p)
{
    apr_allocator_t *allocator = apr_pool_allocator_get(p);
    apr_bucket_alloc_t *list;

#if APR_POOL_DEBUG
    /* may be NULL for debug mode. */
    if (allocator == NULL) {
        if (apr_allocator_create(&allocator) != APR_SUCCESS) {
            abort();
        }
    }
#endif

    list = apr_bucket_alloc_create_ex(allocator);
    list->pool = p;
    apr_pool_cleanup_register(list->pool, list, alloc_cleanup,
                              apr_pool_cleanup_null);

    return list;
}

Is it somehow possible that apr was compiled with APR_POOL_DEBUG defined, but apr-util was not? 

I thought it might be something like that, so I rebuilt a clean httpd-2.0-HEAD 
worker as
of a few minutes ago and rebuilt.

#0  0x008bf65c in allocator_alloc (allocator=0x0, size=8192) at apr_pools.c:188
#1  0x008bf617 in apr_allocator_alloc (allocator=0x0, size=8168) at apr_pools.c:370
#2  0x0053745c in apr_bucket_alloc_create_ex (allocator=0x0) at apr_buckets_alloc.c:67
#3  0x00537405 in apr_bucket_alloc_create (p=0x96d8448) at apr_buckets_alloc.c:52
#4  0x004fa6fd in XS_APR__Bucket_alloc_create (my_perl=0xa2a1aa8, cv=0x9db8f0c) at 
Bucket.c:66
#5  0x00373709 in Perl_pp_entersub (my_perl=0xa2a1aa8) at pp_hot.c:2857
#6  0x0034f24f in Perl_runops_debug (my_perl=0xa2a1aa8) at dump.c:1442
#7  0x002f59b4 in S_call_body (my_perl=0xa2a1aa8, myop=0xf598e720, is_eval=0) at 
perl.c:2288
#8  0x002f54e8 in Perl_call_sv (my_perl=0xa2a1aa8, sv=0xad45170, flags=4) at 
perl.c:2206
#9  0x00fa4852 in modperl_callback (my_perl=0xa2a1aa8, handler=0xa2e05b0, p=0x9d3b2b0, 
r=0x97d5ca8, s=0xaca44f0, args=0x96929f8)
    at modperl_callback.c:115
#10 0x00fa511f in modperl_callback_run_handlers (idx=6, type=4, r=0x97d5ca8, c=0x0, 
s=0xaca44f0, pconf=0x0, plog=0x0, ptemp=0x0,
    run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:276
#11 0x00fa5368 in modperl_callback_per_dir (idx=6, r=0x97d5ca8, 
run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:364
#12 0x00f9dfec in modperl_response_handler_run (r=0x97d5ca8, finish=1) at 
mod_perl.c:909
#13 0x00f9e102 in modperl_response_handler (r=0x97d5ca8) at mod_perl.c:949
#14 0x0806c394 in ap_run_handler (r=0x97d5ca8) at config.c:151
#15 0x0806cab1 in ap_invoke_handler (r=0x97d5ca8) at config.c:358
#16 0x0806777f in ap_process_request (r=0x97d5ca8) at http_request.c:246
#17 0x080611fc in ap_process_http_connection (c=0x9ef61b0) at http_core.c:250
#18 0x080773f4 in ap_run_process_connection (c=0x9ef61b0) at connection.c:42
#19 0x080778ae in ap_process_connection (c=0x9ef61b0, csd=0x9dce0f8) at 
connection.c:175
#20 0x08068bbf in process_socket (p=0xa3446b0, sock=0x9dce0f8, my_child_num=0, 
my_thread_num=1, bucket_alloc=0xa79cff8)
    at worker.c:520
#21 0x0806935d in worker_thread (thd=0x9782c08, dummy=0x9a22cf8) at worker.c:834
#22 0x008b9cab in dummy_worker (opaque=0x9782c08) at thread.c:88
#23 0x00d5e98c in start_thread () from /lib/tls/libpthread.so.0

Funny thing is that when I look at apr_buckets_alloc.c:67, seems you are looking at 
apr-util HEAD,
and not at the APU_0_9_BRANCH.

--
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/     F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to