Re: ap_auth_type() -question

[Eric Covener <co...@gmail.com>]

On Mon, Feb 23, 2009 at 2:46 AM, Jouni Mäkeläinen
<jo...@twinkle.fi> wrote:

>    if (!encrypted_sso_str || apr_strnatcmp(encrypted_sso_str, "false") == 0) {
>        if (apr_strnatcasecmp(ap_auth_type(r), "auth_xxx") == 0) {

NULL != ap_auth_type(r)?

> *** Segmentation fault *** (ap_auth_type)
>
> Here is the backtrace from the core dump:
> #0  0x00002af41b58b67f in apr_match_glob () from /usr/lib64/libapr-1.so.0
> #1  0x00002af4249ebb74 in authenticate_user (r=0x2af42ed75488) at mod_auth_xxx.c:159

Are you sure this debuger was looking at the runtime binaries?   Do
you call apr_match_glob elsewhere?

You might try building with --enable-maintainer-mode


-- 
Eric Covener
covener@gmail.com

Re: Re: Re: ap_auth_type() -question

[Jouni Mäkeläinen <jo...@twinkle.fi>]

I installed locally Apache 2.2.11 for testing and module worked without problems. I used following configuration options as suggested: 
./configure --prefix=/home/twinkle/apache_test/apache-2.2.11 --with-mpm=worker --enable-maintainer-mode --enable-modules=most --enable-bucketeer

So it seems, that there has been a bug in some earlier Apache-versions (or could the reason for segmentation fault lie somewhere else e.g. the way Red Hat(/CentOS) builds Apache ?). 

Thanks for the valuable hints.

Jouni

Re: VS: ap_auth_type() -question

[Eric Covener <co...@gmail.com>]

On Mon, Feb 23, 2009 at 7:41 AM, Jouni Mäkeläinen
<jo...@twinkle.fi> wrote:
>>>    if (!encrypted_sso_str || apr_strnatcmp(encrypted_sso_str, "false") ==
>>> 0) {
>>>        if (apr_strnatcasecmp(ap_auth_type(r), "auth_xxx") == 0) {
>> NULL != ap_auth_type(r)?
> Code is supposed to test, if the required auth type matches (set with AuthType directive) with the auth type ("auth_xxx") that module handles. Now ap_auth_type(r) seems to return pointer to memory location, that causes segmentation fault when accessed (for example in sprintf("Auth type: %s", ap_auth_type(r)).
>

I'm suggesting that you need to make sure you don't follow a null pointer,

> I don't call apr_match_glob() directly, but assumed that ap_auth_type(r) call caused the execution of the glob function.

I don't think so --  it's a very simple getter (and ap_auth_type would
still be in the stack in that case)

-- 
Eric Covener
covener@gmail.com

VS: ap_auth_type() -question

[Jouni Mäkeläinen <jo...@twinkle.fi>]

>>    if (!encrypted_sso_str || apr_strnatcmp(encrypted_sso_str, "false") == 
>> 0) {
>>        if (apr_strnatcasecmp(ap_auth_type(r), "auth_xxx") == 0) {
> NULL != ap_auth_type(r)?
Code is supposed to test, if the required auth type matches (set with AuthType directive) with the auth type ("auth_xxx") that module handles. Now ap_auth_type(r) seems to return pointer to memory location, that causes segmentation fault when accessed (for example in sprintf("Auth type: %s", ap_auth_type(r)).

>> *** Segmentation fault *** (ap_auth_type)
>>
>> Here is the backtrace from the core dump:
>> #0  0x00002af41b58b67f in apr_match_glob () from /usr/lib64/libapr-1.so.0
>> #1  0x00002af4249ebb74 in authenticate_user (r=0x2af42ed75488) at 
>> mod_auth_xxx.c:159

> Are you sure this debuger was looking at the runtime binaries?   Do
> you call apr_match_glob elsewhere?
I compiled module with following command:
/usr/sbin/apxs -Wcg -lmcrypt -c mod_auth_tek.c

After that I produced backtrace with following commands (did it couple of times because of the apr_match_glob at the bottom):
gdb /usr/sbin/httpd -c /tmp/core.12451
(gdb) bt

I don't call apr_match_glob() directly, but assumed that ap_auth_type(r) call caused the execution of the glob function. 

> You might try building with --enable-maintainer-mode
Thanks for the hint. I'll try it next, if nothing else turns up. 

Jouni