Don't want to be a pain in the back side... but (there is always at
least one of those :-), is anyone checking this one out?
I had a peek into the code and that NULL pointer is a variable called
'uwr->context'. Don't know much about mod_jk, but this one gets
initialised in the same file, function uri_worker_map_add. If that thing
gets blown away (or isn't redone) when Apache gracefully restarts...
Bojan
Bojan Smojver wrote:
>
> GOMEZ Henri wrote:
> >
> > >Just realised that the core I have was compiled without -g option. VERY
> > >useful. I also wanted to replicate the core dump with the
> > >httpd that was
> > >compiled with -g, but that didn't work. Now I'm starting to think that
> > >the core file I had was a result of a different crash (I was
> > >experimenting with a lot of stuff and Apache would sometimes spit the
> > >dummy).
> > >
> > >So, how do I get to you something you can use? I've seen the Apache
> > >debugging document (http://dev.apache.org/debugging.html) and forceful
> > >core dumping techniques, but I couldn't find truss for Linux.
> > >Or maybe I
> > >should use something else?
> > >
> > >What are your suggestions?
> >
> > Ask to Apache specialist in new-http list, may be JF Clere could
> > forward your question to them ?
>
> Here is the backtrace from gdb when the segfault happens (I'm starting
> to enjoy this debugging of Apache :-)
>
> -------------------------------------
> Program received signal SIGSEGV, Segmentation fault.
> 0x4021d26f in strncmp (s1=0x0, s2=0x82d2bb4 "/whatwedo/", n=137294736)
> at ../sysdeps/generic/strncmp.c:42
> 42 ../sysdeps/generic/strncmp.c: No such file or directory.
> (gdb) where
> #0 0x4021d26f in strncmp (s1=0x0, s2=0x82d2bb4 "/whatwedo/",
> n=137294736)
> at ../sysdeps/generic/strncmp.c:42
> #1 0x8076e91 in map_uri_to_worker (uw_map=0x82ef290,
> uri=0x82d2bb4 "/whatwedo/", l=0x82ef100) at jk_uri_worker_map.c:412
> #2 0x8072a4c in jk_translate (r=0x82d145c) at mod_jk.c:1177
> #3 0x8146a99 in run_method (r=0x82d145c, offset=0, run_all=0)
> at http_config.c:369
> #4 0x8146ae2 in ap_translate_name (r=0x82d145c) at http_config.c:381
> #5 0x81552b4 in process_request_internal (r=0x82d145c) at
> http_request.c:1198
> #6 0x8155682 in ap_process_request (r=0x82d145c) at http_request.c:1323
> #7 0x814f2d0 in child_main (child_num_arg=0) at http_main.c:4299
> #8 0x814f4eb in make_child (s=0x827c2e4, slot=0, now=996554230)
> at http_main.c:4467
> #9 0x814f560 in startup_children (number_to_start=1) at
> http_main.c:4494
> #10 0x814fbd1 in standalone_main (argc=1, argv=0xbffff854) at
> http_main.c:4854
> #11 0x8150138 in main (argc=1, argv=0xbffff854) at http_main.c:5124
> #12 0x401b9b5c in __libc_start_main (main=0x814fe2c <main>, argc=1,
> ubp_av=0xbffff854, init=0x806f500 <_init>, fini=0x81b7c70 <_fini>,
> rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xbffff84c)
> at ../sysdeps/generic/libc-start.c:129
> -------------------------------------
>
> Looks like strncmp received a NULL pointer at #0...
>
> Bojan