http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21719
Since my submitted bug hasn't been resolved in the 9 months since I
first reported it, I figure it's about time I try and resolve this
problem myself since I do have the source code. I've done a partial
debug on the failure but can't get everything figured out since I can't
get DDD/gdb to debug some of the code (coming from apr_ldap_url.c).
I'm currently using the 2.0.49 source tree for my testing. The problem
starts in mod_auth_ldap.c. When I load the source in ddd, I get an
error stating:
Line 1 of "mod_auth_ldap.c" is at address 0x2ebd4
<derive_codepage_from_lang> but contains no code.
This doesn't seem to be a fatal error since I can go in and set
breakpoints in the file. I set a breakpoint at line 702 and start the
program. At this point, url looks good since it contains the
AuthLDAPURL entry from my config file. I continue on to line 703 and
urld contains bogus data. The host and filter parameters are swapped,
the lud_attrs points off into oblivion (causing the segfault in the
apr_pstrdup call on line 755, which is the final death for the
process).
The problem comes in the fact that I can't seem to trace anything
inside apr_ldap_url.c, which is where the real problems seem to lie.
When I load this source file, gdb spits out the error:
Line number 1 is out of range for "apr_ldap_url.c".
The function ldap_url_parse_ext() is not processing URLs properly on
Solaris-SPARC, but does work fine on Linux-x86 (endian-ness error?).
When I try to set a breakpoint in apr_ldap_url.c, I get:
No line 255 in file "apr_ldap_url.c".
I believe this is due to the fact that this is coming in from a shared
library instead of statically linked libraries and have tried to get
around this by linking httpd statically, but that seems to be a royal
pain to accomplish. Even when I add the --enable-static-htpasswd
argument to configure, it comes up with a dynamically linked
executable. Is there any way to get httpd to be statically linked so I
can do source level debugging on ldap_url_parse_ext(). I could just
read through the ~300 lines of code, but it would be much easier to
find the problem by looking at all the variables as the function is
running to see where the problems are.
Steve
- Re: Need Help Debugging Shared Library (libaprutil-0.so) Steve Waltner