On 6/21/12 7:32 PM, oh...@cox.net wrote:
---- oh...@cox.net wrote:
---- Joe Lewis<j...@joe-lewis.com> wrote:
On 6/21/12 6:46 PM, oh...@cox.net wrote:
---- Joe Lewis<j...@joe-lewis.com> wrote:
On 6/21/12 5:49 PM, oh...@cox.net wrote:
---- oh...@cox.net wrote:
---- Sorin Manolache<sor...@gmail.com> wrote:
And I forgot to say: run gdb in some sort of environment where you see
your current source code line and a couple of surrounding lines. You
could achieve this with the "list" command, but I prefer running gdb in
emacs and let emacs do the nice listing of source code in a different panel.
S
Here's the function from my source. It's the original from mod_headers.c, plus
my printf:
static int header_post_config(apr_pool_t *pconf, apr_pool_t *plog,
apr_pool_t *ptemp, server_rec *s)
{
printf("In header_post_config\n");
header_ssl_lookup = APR_RETRIEVE_OPTIONAL_FN(ssl_var_lookup);
return OK;
}
Jim
Hi,
I was able to get the segfault to go away. Here's what I had to do:
- Created /etc/ld.so.conf.d/my.conf, and added the directory where my
libobaccess.so was
- Run 'ldconfig' to activate.
- In the apxs command, DON'T include the -L and -l arguments
After that, Apache appears to start ok, without segfault :)!!
Thanks for all of the great help, esp. the suggestion about checking "ldconfig
-p". I still don't understand why, but I'm just glad that I can get past this piece
so now I can debug my module :)...
Later,
Jim
I'm just glad this list is as good as it is!
FYI, the ldconfig is the dynamic linker control, and those
/etc/ld.so.conf.d files provide additional search directories for the
linker to check in when loading a library.
Joe
--
http://www.silverhawk.net/
Hi,
Sorry to report, but my earlier report was a "false positive" :)...
I forgot that the mod_headers.c that I was doing the earlier testing with had
all references to the libobaccess.so removed :(!!
So, I'm still stuck with basically the same problem, now, working with my
"full" code, with the calls in it:
- If I compile with -L and -l, Apache segfaults when it starts
- If I compile without -L and -l, then I get "undefined symbol" errors when I
try to start Apache, e.g.:
[root@apachemodule build-mod_headers]# /apps/httpd2222/bin/apachectl -k start -X
httpd: Syntax error on line 84 of /apps/httpd2222/conf/httpd.conf: Cannot load
/apps/httpd2222/modules/mod_headers.so into server:
/apps/httpd2222/modules/mod_headers.so: undefined symbol: ObResource_isProtected
That "ObResource_isProtected" should be a symbol in libobaccess.so, and in fact, if I do
"nm --dynamic", I get:
[root@apachemodule build-mod_headers]# nm --dynamic /apps/netpoint/lib64/libobaccess.so |
grep "ObResource_isProtected"
00000000000a6d80 T ObResource_isProtected
[root@apachemodule build-mod_headers]#
I'm *assuming* that the reason for the "undefined symbol" error is that
libobaccess.so is actually not being loaded, but then when I try to load libobaccess.so,
either via -L and -l in the apxs, or using LoadFile in httpd.conf, I get the segfault
(same gdb info, BTW).
Catch-22?
Sorry for the false alarm :(!!
Jim
Not a catch-22. The -L and -l specify linker options when assembling
the code. The ldconfig is a run-time thing. If you are getting the
stderr messages, you are making it all the way into your library. I'd
suggest commenting out the following line and see if you get farther :
header_ssl_lookup = APR_RETRIEVE_OPTIONAL_FN(ssl_var_lookup);
That should tell you if the problem is the ssl_var_lookup.
Joe
--
http://www.silverhawk.net/
Hi,
Thanks for the suggestion. I just tried what you suggested, and got a segfault
when I started Apache with the modified module.
Jim
Hi,
As a reminder, here's the gdb with the library loaded:
(gdb) b header_post_config
Function "header_post_config" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (header_post_config) pending.
(gdb) run -d /apps/httpd2222/ -f /apps/httpd2222/conf/httpd.conf
Starting program: /apps/httpd2222/bin/httpd -d /apps/httpd2222/ -f
/apps/httpd2222/conf/httpd.conf
[Thread debugging using libthread_db enabled]
[New Thread 182897610272 (LWP 11317)]
Breakpoint 2 at 0x2a9751ea90: file mod_headers.c, line 1121.
Pending breakpoint "header_post_config" resolved
mod_headers-jl V0.09 - start calling OAM API
In register_hooks
In create_headers_dir_config
In create_headers_dir_config
In header_cmd
In header_inout_cmd
In parse_format_tag
In parse_misc_string
In create_headers_dir_config
In header_cmd
In header_inout_cmd
In parse_format_tag
In parse_misc_string
[Switching to Thread 182897610272 (LWP 11317)]
Breakpoint 2, header_post_config (pconf=0x573138, plog=0x5a52c8,
ptemp=0x5a72d8, s=0x59d3a8) at mod_headers.c:1121
1121 printf("In header_post_config\n");
(gdb) n
1120 {
(gdb) n
1121 printf("In header_post_config\n");
(gdb) n
In header_post_config
1122 header_ssl_lookup = APR_RETRIEVE_OPTIONAL_FN(ssl_var_lookup);
(gdb) n
1124 }
(gdb) n
0x00000000004360c7 in ap_run_post_config (pconf=0x573138, plog=0x5a52c8,
ptemp=0x5a72d8, s=0x59d3a8) at config.c:91
91 AP_IMPLEMENT_HOOK_RUN_ALL(int, post_config,
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0x0000003518d6c1e1 in BN_num_bits () from /lib64/libcrypto.so.4
So, it's actually blowing up in "BN_num_bits()" in /lib64/libcrypto.so.4?
Jim
When you see the :
Program received signal SIGSEGV, Segmentation fault.
0x0000003518d6c1e1 in BN_num_bits () from /lib64/libcrypto.so.4
in gdb, type "bt" and hit enter. It should show the back trace and how
you got to the BN_num_bits() function.
Joe
--
http://www.silverhawk.net/
