Re: Need Help Debugging Shared Library (libaprutil-0.so)
Steve Waltner wrote: You may find some useful notes here: http://perl.apache.org/docs/2.0/devel/debug/c.html There are for debugging mod_perl 2.0, but most of it applies to any other shared C library. Thanks for the information but it still doesn't seem to be working correctly. If this is a topic that I should take over to a gdb mailing list, let me know. I started with a clean unpack of the Apache 2.0.49 source tarball and configure it with the following command: ./configure --enable-maintainer-mode --with-ldap --enable-ldap --enable-auth-ldap --prefix=/tmp/apache-test make make install cp /tmp/httpd.conf /tmp/apache-test/conf/httpd.conf [...] (gdb) run -k start Starting program: /tmp/apache-test/bin/httpd -k start Breakpoint 1, mod_auth_ldap_parse_url (cmd=0xffbffb78, config=0xea998, url=0xeaa80 "ldap://ldap.lsil.com/ou=lsil.com,o=LSI%20Logic?uid";) at mod_auth_ldap.c:702 702 result = apr_ldap_url_parse(url, &(urld)); (gdb) info shared FromTo Syms Read Shared Object Library 0xff3847f4 0xff3929d0 Yes /tmp/apache-test/lib/libaprutil-0.so.0 0xff20d5a0 0xff2cb564 Yes /usr/lib/libldap.so.5 0xff342638 0xff35aa48 Yes /tmp/apache-test/lib/libexpat.so.0 0xff1c8064 0xff1dd4e4 Yes /tmp/apache-test/lib/libapr-0.so.0 0xff3104bc 0xff310634 Yes /usr/lib/libsendfile.so.1 0xff1a2494 0xff1a51b8 Yes /usr/lib/librt.so.1 0xff171a40 0xff180f24 Yes /usr/lib/libm.so.1 0xff1535e0 0xff1595a4 Yes /usr/lib/libsocket.so.1 0xff0940f8 0xff10098c Yes /usr/lib/libnsl.so.1 0xff028ab8 0xff057134 Yes /usr/lib/libresolv.so.2 0xff0039f4 0xff003ffc Yes /usr/lib/libpthread.so.1 0xff3b0704 0xff3b075c Yes /usr/lib/libdl.so.1 0xfef1ca08 0xfef9f038 Yes /usr/lib/libc.so.1 0xfefd04f4 0xfefd1510 Yes /usr/lib/libmd5.so.1 0xfeee1a8c 0xfeee7dd4 Yes /usr/lib/libaio.so.1 0xfeec09a0 0xfeec2950 Yes /usr/lib/libmp.so.2 0xfeeb0420 0xfeeb34e8 Yes /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1 0xfee873b0 0xfee96100 Yes /usr/lib/libthread.so.1 (gdb) b apr_ldap_url.c:255 No line 255 in file "apr_ldap_url.c". (gdb) b ldap_url_parse_ext Function "ldap_url_parse_ext" not defined. Make breakpoint pending on future shared library load? (y or [n]) (gdb) quit The program is running. Exit anyway? (y or n) y dumbo:/tmp/apache-test> = I haven't turned off the autoload shared libraries, so gdb does try to load debug symbols from the libaprutil file, but it still appears as though it's not working properly since I can't set a breakpoint in apr_ldap_url.c or step into the function. Looking at the output of make, it appears as though the build process does the needed debugging flags... right make[3]: Entering directory `/tmp/httpd-2.0.49/srclib/apr-util' /bin/bash /tmp/httpd-2.0.49/srclib/apr/libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes [...] encoding/apr_base64.lo hooks/apr_hooks.lo ldap/apr_ldap_compat.lo ldap/apr_ldap_url.lo .lo gets linked alright, but it doesn't have any symbols: httpd-2.0/srclib> nm apr-util/ldap/apr_ldap*o The explanation comes from: #if APR_HAS_LDAP #if !APR_HAS_LDAP_URL_PARSE in apr_ldap_url.c and the header file apr_ldap_url.h: #if APR_HAS_LDAP #if APR_HAS_LDAP_URL_PARSE #define apr_ldap_url_desc_t LDAPURLDesc #define apr_ldap_is_ldap_url(url) ldap_is_ldap_url(url) #define apr_ldap_is_ldaps_url(url) ldap_is_ldaps_url(url) #define apr_ldap_is_ldapi_url(url) ldap_is_ldapi_url(url) #define apr_ldap_url_parse(url, ludpp) ldap_url_parse(url, ludpp) #define apr_ldap_free_urldesc(ludp) ldap_free_urldesc(ludp) #else /* ! APR_HAS_LDAP_URL_PARSE */ So you have the implementation elsewhere. ldap_url_parse_ext doesn't exist at all. You need to break at: ldap_url_parse or similar, I can't see ldap_url_parse_ext there. Though I'm not sure who links against libldap (neither libaprutil nor httpd are linked against it on my machine), I will leave it here for you to discover that. ldd and nm, should help you to discover that. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Need Help Debugging Shared Library (libaprutil-0.so)
On May 5, 2004, at 6:50 PM, Stas Bekman wrote: Steve Waltner wrote: 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 but contains no code. You need two things: 1) compile with debug symbols retained which you get when building apache with --enable-maintainer-mode 2) make sure to load the library from gdb (or DDD's gdb console): gdb> sharedlib apr or whichever lib it is. You may find some useful notes here: http://perl.apache.org/docs/2.0/devel/debug/c.html There are for debugging mod_perl 2.0, but most of it applies to any other shared C library. Thanks for the information but it still doesn't seem to be working correctly. If this is a topic that I should take over to a gdb mailing list, let me know. I started with a clean unpack of the Apache 2.0.49 source tarball and configure it with the following command: ./configure --enable-maintainer-mode --with-ldap --enable-ldap --enable-auth-ldap --prefix=/tmp/apache-test make make install cp /tmp/httpd.conf /tmp/apache-test/conf/httpd.conf I made the following changes to the httpd.conf file. This go into the cgi-bin Directory block since I'm trying to protect the cgi-bin directory: = dumbo:/tmp/apache-test> diff -c /tmp/apache-test/conf/httpd-std.conf /tmp/httpd.conf *** /tmp/apache-test/conf/httpd-std.confThu May 6 10:10:55 2004 --- /tmp/httpd.conf Wed May 5 09:15:22 2004 *** *** 609,614 --- 609,621 Options None Order allow,deny Allow from all + + AuthName "Admin Page" + AuthType Basic + AuthLDAPEnabled on + AuthLDAPAuthoritative on + AuthLDAPURL ldap://ldap.lsil.com/ou=lsil.com,o=LSI%20Logic?uid + require valid-user # dumbo:/tmp/apache-test> = Trying this with straight gdb instead of ddd/gdb, I get the following: = dumbo:/tmp/apache-test> gdb bin/httpd GNU gdb 6.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.9"... (gdb) info shared No shared libraries loaded at this time. (gdb) b mod_auth_ldap.c:702 Breakpoint 1 at 0x2fec8: file mod_auth_ldap.c, line 702. (gdb) run -k start Starting program: /tmp/apache-test/bin/httpd -k start Breakpoint 1, mod_auth_ldap_parse_url (cmd=0xffbffb78, config=0xea998, url=0xeaa80 "ldap://ldap.lsil.com/ou=lsil.com,o=LSI%20Logic?uid";) at mod_auth_ldap.c:702 702 result = apr_ldap_url_parse(url, &(urld)); (gdb) info shared FromTo Syms Read Shared Object Library 0xff3847f4 0xff3929d0 Yes /tmp/apache-test/lib/libaprutil-0.so.0 0xff20d5a0 0xff2cb564 Yes /usr/lib/libldap.so.5 0xff342638 0xff35aa48 Yes /tmp/apache-test/lib/libexpat.so.0 0xff1c8064 0xff1dd4e4 Yes /tmp/apache-test/lib/libapr-0.so.0 0xff3104bc 0xff310634 Yes /usr/lib/libsendfile.so.1 0xff1a2494 0xff1a51b8 Yes /usr/lib/librt.so.1 0xff171a40 0xff180f24 Yes /usr/lib/libm.so.1 0xff1535e0 0xff1595a4 Yes /usr/lib/libsocket.so.1 0xff0940f8 0xff10098c Yes /usr/lib/libnsl.so.1 0xff028ab8 0xff057134 Yes /usr/lib/libresolv.so.2 0xff0039f4 0xff003ffc Yes /usr/lib/libpthread.so.1 0xff3b0704 0xff3b075c Yes /usr/lib/libdl.so.1 0xfef1ca08 0xfef9f038 Yes /usr/lib/libc.so.1 0xfefd04f4 0xfefd1510 Yes /usr/lib/libmd5.so.1 0xfeee1a8c 0xfeee7dd4 Yes /usr/lib/libaio.so.1 0xfeec09a0 0xfeec2950 Yes /usr/lib/libmp.so.2 0xfeeb0420 0xfeeb34e8 Yes /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1 0xfee873b0 0xfee96100 Yes /usr/lib/libthread.so.1 (gdb) b apr_ldap_url.c:255 No line 255 in file "apr_ldap_url.c". (gdb) b ldap_url_parse_ext Function "ldap_url_parse_ext" not defined. Make breakpoint pending on future shared library load? (y or [n]) (gdb) quit The program is running. Exit anyway? (y or n) y dumbo:/tmp/apache-test> = I haven't turned off the autoload shared libraries, so gdb does try to load debug symbols from the libaprutil file, but it still appears as though it's not working properly since I can't set a breakpoint in apr_ldap_url
Re: Need Help Debugging Shared Library (libaprutil-0.so)
Steve Waltner wrote: 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 but contains no code. You need two things: 1) compile with debug symbols retained which you get when building apache with --enable-maintainer-mode 2) make sure to load the library from gdb (or DDD's gdb console): gdb> sharedlib apr or whichever lib it is. You may find some useful notes here: http://perl.apache.org/docs/2.0/devel/debug/c.html There are for debugging mod_perl 2.0, but most of it applies to any other shared C library. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Need Help Debugging Shared Library (libaprutil-0.so)
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 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