perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tupshin Harper <>
Subject Re: [mp2] frequent segfaults in APR::Table
Date Wed, 31 Dec 2008 10:39:56 GMT
Some comments inline, but the really useful stuff at the bottom.

Thank you very much for your help.


Philippe M. Chiasson wrote:
> On 29/12/08 18:56, Tupshin Harper wrote:
>> 1. Problem Description:
>> I'm attempting to upgrade one of the largest (measured both by users and
>> lines of code, I suspect) mod_perl sites from mod_perl 1 to mod_perl 2,
>> and also from 32 bit OS to 64 bit at the same time. I converted our
>> calls to use the new API, and basic functionality started working.
>> However, I am experiencing frequent segfaults in APR::Table (stack trace
>> below) when loading pages.
> Just out of curiosity, are you handling APR::Table objects directly ?
The only places where APR is ever mentioned are:

(comment line 76)
(the two "use" statements, but those appear to actually be unused.

So no.
>> Somewhere betwen 1 out of every 2-4 page
>> loads will cause it. Identical problem occurs on:
>> 64 bit Debian Lenny with stock mod_perl 2.0.4
>> 64 bit Debian Lenny with hand-built mod_perl 2.0.5-dev from latest 
>> source.
>> 64 bit Centos 5.2 with stock mod_perl 2.0.2.
>> Let me know if there is any other information you need.
> See below. Of course, a shorter, reproducible test case would be the 
> ideal.
Agreed, but given the complexity of the entire system and the fact that 
we are using a home-brewed templating system (bml), makes it quite 
difficult. I'll work on that if nothing else proves fruitful.
>> I have not yet
>> tried it with mod_perl 2 on a 32-bit OS.
>> [...]
>> Method it crashes in:
>> /* Try to shortcut apr_table_get by fetching the key using the current
>>   * iterator (unless it's inactive or points at different key).
>>   */
>> static MP_INLINE const char *mpxs_APR__Table_FETCH(pTHX_ SV *tsv,
>>                                                     const char *key)
>> {
>>      SV* rv = modperl_hash_tied_object_rv(aTHX_ "APR::Table", tsv);
>>      const int i = mpxs_apr_table_iterix(rv);
>>      apr_table_t *t = INT2PTR(apr_table_t *, SvIVX(SvRV(rv)));
> Possibly smells like a 64 bit issue to me.
My next step will be to confirm this theory by bringing it up on a 32 
bit instance.
>>      const apr_array_header_t *arr = apr_table_elts(t);
>>      apr_table_entry_t *elts = (apr_table_entry_t 
>> *)arr->elts;<---crashing line 186
> Can you get a little more information out of the current local variables.
> i.e. I'd be interested in seeing the value of:
> i
> *t
> *arr
> Which you can easily do from withing gdb with
> (gdb) display *t
> (gdb) display *arr
"i" is never anything but zero in the cases I'm looking at
a typical value for "t" is "(apr_table_t *) 0x956bfa0"
but printing *t always generates <incomplete type>
however, there is useful wrongness in "arr" and "elts".

A quick adendum to my previous report:

Sometimes it crashes directly on line 186, and in those cases, arr = 
0x4f5349203a746573 (or something similar), and printing *arr reasonably 
says "Cannot access memory at address 0x4f5349203a746573"

In other cases, it crashes within the apr_table_get(t, key) call on line 
192. In those cases, "arr" is more reasonable, e.g. 
(const apr_array_header_t *) 0x956bfa0
but *arr is:
 {pool = 0x636f6c2f7273752f, elt_size = 1932487777, nelts = 980314466, 
nalloc = 1920169263,
  elts = 0x2f3a6e69622f6c61 <Address 0x2f3a6e69622f6c61 out of bounds>}
elts is:
(apr_table_entry_t *) 0x2f3a6e69622f6c61
and *elts is:
Cannot access memory at address 0x2f3a6e69622f6c61

So, to summarize, when it crashes on line 186, *arr is a bad pointer, 
and when it crashes when calling apr_table_get from line 192, *elts is a 
bad pointer.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message