perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [mp2] pools that go out of scope aren't a problem anymore?
Date Fri, 26 Nov 2004 00:19:33 GMT
Joe Schaefer wrote:

>>They don't quite segfault for me. How is your system different than mine?
> 
> 
> The major differences:
> 
> I'm testing 64bit debian on the trunk of all projects (httpd, apr, mp2)
> against a fresh perl-5.8.x snapshot, and I enabled every debugging option
> I could think of (--enable-pool-debug, CFLAGS="-g3 -gdwarf-2 -O2",
> CPPFLAGS="-DAPR_BUCKET_DEBUG"; MP_DEBUG=1; MP_MAINTAINER=1) when 
> compiling them.

>>   MP_USE_GTOP     => 1

> I don't have gtop enabled.

most likely irrelevant. it's only good for memory usage stats and tracing 
memory leaks.

>>*** (apr|apu)-config linking info
> 
> 
> Pretty much the same as mine, but with -lapr-1 and -laprutil-1.  This
> is a factor, because the segfaults are coming from libapr:
> 
> % bt
> #0  apr_table_set (t=0x5236b0, key=0x517960 "1", val=0x517960 "1")
>     at tables/apr_tables.c:531
> #1  0x0000002a96b6eb02 in XS_APR__Table_set (my_perl=0x504010, cv=0x517960)
>     at Table.c:243
> #2  0x0000002a95704a43 in Perl_pp_entersub (my_perl=0x504010) at pp_hot.c:2890
> #3  0x0000002a956ea40e in Perl_runops_debug (my_perl=0x504010) at dump.c:1449
> #4  0x0000002a956a40e0 in S_run_body (my_perl=0x504010, oldscope=1)
>     at perl.c:1934
> #5  0x0000002a956a3e45 in perl_run (my_perl=0x504010) at perl.c:1853
> #6  0x0000000000401aff in main (argc=6, argv=0x7fbffff8f8, env=0x2)
>     at perlmain.c:95
> 
> % p *t->a.pool
> $2 = {parent = 0x0, child = 0x0, sibling = 0x5236a0, ref = 0x5236a0,
>   cleanups = 0x2a961ed288, free_cleanups = 0x2a961ed288,
>   allocator = 0x2a961ed298, subprocesses = 0x2a961ed298, abort_fn = 0x5b10b0,
>   user_data = 0x5094c0, tag = 0x2a961ed2b8 "°\020[", nodes = 0x2a961ed2b8,
>   file_line = 0x599ad0 "\220FR", creation_flags = 5338784, stat_alloc = 0,
>   stat_total_alloc = 2518602456, stat_clear = 42, owner = 182907228888,
>   mutex = 0x568b40}

May be if I try to build with --enable-pool-debug 
CPPFLAGS="-DAPR_BUCKET_DEBUG" I'll trigger those with apr-0 as well.

I doubt that CFLAGS="-g3 -gdwarf-2 -O2" has anything do with this. It 
creates a way too big libs, which makes things slow, even for debug. You 
want those flags only if you want to be able to expand macros in gdb. I'm 
not sure what else are those good for.

thanks for the info, Joe.

In any case I'm pretty sure that you've already thought about a great 
solution and you have an almost working patch. Don't say that you don't 
have one :)

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message