Re: [mp2] frequent segfaults in APR::Table

[Tupshin Harper]

Some comments inline, but the really useful stuff at the bottom.

Thank you very much for your help.

-Tupshin

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:
http://code.livejournal.org/trac/livejournal/browser/branches/modernize/cgi-bin/LJ/Request/Apache2.pm 
(comment line 76)
and
http://code.livejournal.org/trac/bml/browser/branches/modernize/lib/Apache/BML.pm 
(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.

Thanks.

-Tupshin



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