Mailing List Archive

steve johnson wrote:
> Update:
>
> By using the trunk version of apr I got lucene4c to
> build. By deleting the liblucene4c.la file I got
> mod_mbox to build using lucene4c. Now when I start
> the httpd it dumps core. Here is a stack trace. Any
> suggestions about next steps would be appreciated.

Well, it seems to be failing to dlopen mod_mbox.so, likely reasons for
this might be a failure to link in necessary libraries, maybe the C++
runtime (libstdc++) or the java runtime (i forget the name for this).
Running ldd on mod_mbox.so might be interesting, as would running it on
liblucene4c.so.

-garrett

steve johnson wrote:
> mod_mbox.so
> /myth/steve/mod_mbox_l/trunk/module-2.0/.libs/mod_mbox.so
> liblucene4c.so =>
> /usr/local/lucene4c/lib/liblucene4c.so (0xb7e4f000)
> libapr-0.so.0 =>
> /usr/local/apache2/lib/libapr-0.so.0 (0xb7e2d000)
> librt.so.1 => /lib/tls/librt.so.1 (0xb7e1a000)
> libm.so.6 => /lib/tls/libm.so.6 (0xb7df8000)
> libcrypt.so.1 => /lib/tls/libcrypt.so.1
> (0xb7dcb000)
> libnsl.so.1 => /lib/tls/libnsl.so.1
> (0xb7db7000)
> libpthread.so.0 => /lib/tls/libpthread.so.0
> (0xb7da8000)
> libdl.so.2 => /lib/tls/libdl.so.2 (0xb7da4000)
> libaprutil-0.so.0 =>
> /usr/local/apache2/lib/libaprutil-0.so.0 (0xb7d90000)
> libexpat.so.1 => /usr/lib/libexpat.so.1
> (0xb7d70000)
> libc.so.6 => /lib/tls/libc.so.6 (0xb7c3b000)
> libgcj.so.6 => /usr/lib/libgcj.so.6
> (0xb6b70000)
> libapr-1.so => /usr/local/apr/lib/libapr-1.so
> (0xb6b4c000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1
> (0xb6b41000)
> libz.so.1 => /usr/lib/libz.so.1 (0xb6b2f000)
>
>
> liblucene.so
>
> libgcj.so.6 => /usr/lib/libgcj.so.6 (0xb6d82000)
> libapr-1.so => /usr/local/apr/lib/libapr-1.so
> (0xb6d5e000)
> librt.so.1 => /lib/tls/librt.so.1 (0xb6d58000)
> libcrypt.so.1 => /lib/tls/libcrypt.so.1
> (0xb6d2b000)
> libpthread.so.0 => /lib/tls/libpthread.so.0
> (0xb6d1c000)
> libdl.so.2 => /lib/tls/libdl.so.2 (0xb6d19000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1
> (0xb6d0e000)
> libm.so.6 => /lib/tls/libm.so.6 (0xb6ceb000)
> libz.so.1 => /usr/lib/libz.so.1 (0xb6cd9000)
> libc.so.6 => /lib/tls/libc.so.6 (0xb6ba4000)
> libexpat.so.1 => /usr/lib/libexpat.so.1
> (0xb6b84000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2
> (0x80000000)

Well, first off, one is linked against libapr-0.so and one is linked
with libapr-1.so, that's probably a bad thing... I'd suggest making
sure everything is linked against one or the other, and trying again.

-garrett

mod_mbox.so
/myth/steve/mod_mbox_l/trunk/module-2.0/.libs/mod_mbox.so
liblucene4c.so =>
/usr/local/lucene4c/lib/liblucene4c.so (0xb7e4f000)
libapr-0.so.0 =>
/usr/local/apache2/lib/libapr-0.so.0 (0xb7e2d000)
librt.so.1 => /lib/tls/librt.so.1 (0xb7e1a000)
libm.so.6 => /lib/tls/libm.so.6 (0xb7df8000)
libcrypt.so.1 => /lib/tls/libcrypt.so.1
(0xb7dcb000)
libnsl.so.1 => /lib/tls/libnsl.so.1
(0xb7db7000)
libpthread.so.0 => /lib/tls/libpthread.so.0
(0xb7da8000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb7da4000)
libaprutil-0.so.0 =>
/usr/local/apache2/lib/libaprutil-0.so.0 (0xb7d90000)
libexpat.so.1 => /usr/lib/libexpat.so.1
(0xb7d70000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7c3b000)
libgcj.so.6 => /usr/lib/libgcj.so.6
(0xb6b70000)
libapr-1.so => /usr/local/apr/lib/libapr-1.so
(0xb6b4c000)
libgcc_s.so.1 => /lib/libgcc_s.so.1
(0xb6b41000)
libz.so.1 => /usr/lib/libz.so.1 (0xb6b2f000)


liblucene.so

libgcj.so.6 => /usr/lib/libgcj.so.6 (0xb6d82000)
libapr-1.so => /usr/local/apr/lib/libapr-1.so
(0xb6d5e000)
librt.so.1 => /lib/tls/librt.so.1 (0xb6d58000)
libcrypt.so.1 => /lib/tls/libcrypt.so.1
(0xb6d2b000)
libpthread.so.0 => /lib/tls/libpthread.so.0
(0xb6d1c000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb6d19000)
libgcc_s.so.1 => /lib/libgcc_s.so.1
(0xb6d0e000)
libm.so.6 => /lib/tls/libm.so.6 (0xb6ceb000)
libz.so.1 => /usr/lib/libz.so.1 (0xb6cd9000)
libc.so.6 => /lib/tls/libc.so.6 (0xb6ba4000)
libexpat.so.1 => /usr/lib/libexpat.so.1
(0xb6b84000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
(0x80000000)



--- Garrett Rooney <rooneg@electricjellyfish.net>
wrote:

> steve johnson wrote:
> > Update:
> >
> > By using the trunk version of apr I got lucene4c
> to
> > build. By deleting the liblucene4c.la file I got
> > mod_mbox to build using lucene4c. Now when I
> start
> > the httpd it dumps core. Here is a stack trace.
> Any
> > suggestions about next steps would be appreciated.
>
> Well, it seems to be failing to dlopen mod_mbox.so,
> likely reasons for
> this might be a failure to link in necessary
> libraries, maybe the C++
> runtime (libstdc++) or the java runtime (i forget
> the name for this).
> Running ldd on mod_mbox.so might be interesting, as
> would running it on
> liblucene4c.so.
>
> -garrett
>

>
> Well, first off, one is linked against libapr-0.so
> and one is linked
> with libapr-1.so, that's probably a bad thing...
> I'd suggest making
> sure everything is linked against one or the other,
> and trying again.
>
> -garrett
>
Ok, seems reasonable but I'm not sure how it can be
done. httpd won't build with the version of apr that
lucene4c requires. And mod_mbox builds with apxs which
uses the same libraries as httpd. Even if I could
rebuild mod_mbox with the version lucene4c wants I
would probably end up in the same situation because of
the version difference between the httpd and mod_mbox.

steve johnson wrote:
>
>>Well, first off, one is linked against libapr-0.so
>>and one is linked
>>with libapr-1.so, that's probably a bad thing...
>>I'd suggest making
>>sure everything is linked against one or the other,
>>and trying again.
>>
>>-garrett
>>
>
> Ok, seems reasonable but I'm not sure how it can be
> done. httpd won't build with the version of apr that
> lucene4c requires. And mod_mbox builds with apxs which
> uses the same libraries as httpd. Even if I could
> rebuild mod_mbox with the version lucene4c wants I
> would probably end up in the same situation because of
> the version difference between the httpd and mod_mbox.

Well, the only reason you need the trunk version of APR for Lucene4C is
that Paul fixed some problems with jlibtool in the trunk and those fixes
aren't available in a released version yet. You could try copying the
trunk's version of jlibtool.c over to the older APR, build that APR with
--enable-experimental-libtool, then build everything from scratch
using that version of APR. I can't recall if anything in Lucene4C
enforces the use of a current version of APR, but if it does it probably
isn't hard to work around.

-garrett

--- Garrett Rooney <rooneg@electricjellyfish.net>
wrote:

> Well, the only reason you need the trunk version of
> APR for Lucene4C is
> that Paul fixed some problems with jlibtool in the
> trunk and those fixes
> aren't available in a released version yet. You
> could try copying the
> trunk's version of jlibtool.c over to the older APR,
> build that APR with
> --enable-experimental-libtool, then build
> everything from scratch
> using that version of APR. I can't recall if
> anything in Lucene4C
> enforces the use of a current version of APR, but if
> it does it probably
> isn't hard to work around.
>
> -garrett
>

I built lucene4c with the apr that comes with the
httpd tarball (with the jlibtool.c from the trunk).
No change in symptoms. Stack trace looks very
similar. here is the data:

ldd mod_mbox.so
libexpat.so.1 =>
/usr/lib/libexpat.so.1 (0xb7fc7000)
liblucene4c.so =>
/usr/local/lucene4c/lib/liblucene4c.so (0xb7e21000)
libapr-0.so.0 =>
/usr/local/apache2/lib/libapr-0.so.0 (0xb7e00000)
librt.so.1 => /lib/tls/librt.so.1 (0xb7dfa000)
libm.so.6 => /lib/tls/libm.so.6 (0xb7dd8000)
libcrypt.so.1 => /lib/tls/libcrypt.so.1
(0xb7dab000)
libnsl.so.1 => /lib/tls/libnsl.so.1
(0xb7d97000)
libpthread.so.0 => /lib/tls/libpthread.so.0
(0xb7d87000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb7d84000)
libaprutil-0.so.0 =>
/usr/local/apache2/lib/libaprutil-0.so.0 (0xb7d70000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7c3b000)
libgcj.so.6 => /usr/lib/libgcj.so.6
(0xb6b70000)
libgcc_s.so.1 => /lib/libgcc_s.so.1
(0xb6b64000)
libz.so.1 => /usr/lib/libz.so.1 (0xb6b52000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
(0x80000000)


ldd liblucene4c.so
libgcj.so.6 => /usr/lib/libgcj.so.6
(0xb6d82000)
libapr-0.so =>
/usr/local/apr/.libs/libapr-0.so (0xb6d60000)
librt.so.1 => /lib/tls/librt.so.1 (0xb6d5a000)
libm.so.6 => /lib/tls/libm.so.6 (0xb6d38000)
libcrypt.so.1 => /lib/tls/libcrypt.so.1
(0xb6d0b000)
libnsl.so.1 => /lib/tls/libnsl.so.1
(0xb6cf7000)
libpthread.so.0 => /lib/tls/libpthread.so.0
(0xb6ce8000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb6ce4000)
libgcc_s.so.1 => /lib/libgcc_s.so.1
(0xb6cd9000)
libz.so.1 => /usr/lib/libz.so.1 (0xb6cc7000)
libc.so.6 => /lib/tls/libc.so.6 (0xb6b92000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
(0x80000000)


Stack trace

#0 0xb71a83b0 in _Jv_RegisterClassHookDefault () from
/usr/lib/libgcj.so.6
#1 0xb71a8958 in _Jv_RegisterClasses () from
/usr/lib/libgcj.so.6
#2 0xb7cac7a1 in frame_dummy () from
/usr/local/lucene4c/lib/liblucene4c.so
#3 0xb7cac428 in _init () from
/usr/local/lucene4c/lib/liblucene4c.so
#4 0xb7ff61ce in _dl_catch_error () from
/lib/ld-linux.so.2
#5 0xb7ff62ba in _dl_init () from /lib/ld-linux.so.2
#6 0xb7edd2b2 in _dl_open () from /lib/tls/libc.so.6
#7 0xb7ff6016 in _dl_catch_error () from
/lib/ld-linux.so.2
#8 0xb7edced6 in _dl_open () from /lib/tls/libc.so.6
#9 0xb7f0b038 in dlopen () from /lib/tls/libdl.so.2
#10 0xb7ff6016 in _dl_catch_error () from
/lib/ld-linux.so.2
#11 0xb7f0b4a6 in dlerror () from /lib/tls/libdl.so.2
#12 0xb7f0afe4 in dlopen () from /lib/tls/libdl.so.2
#13 0xb7fa32c3 in apr_dso_load (res_handle=0xbffff888,
path=0x8115da0
"/usr/local/apache2/modules/mod_mbox.so",
pool=0x80bc0a8)
at dso.c:138
#14 0x0807e010 in load_module (cmd=0xbffffa58,
dummy=0xbffff910,
modname=0x8115d78 "mbox_module",
filename=0x8115d88 "modules/mod_mbox.so")
at mod_so.c:240
#15 0x08080cb6 in invoke_cmd (cmd=0x80a77c0,
parms=0xbffffa58,
mconfig=0xbffff910, args=0x80ff1da "") at
config.c:797
#16 0x0808155e in ap_build_config_sub (p=Variable "p"
is not available.
) at config.c:1335
#17 0x080819ce in ap_build_config (parms=0xbffffa58,
p=0x80bc0a8,
---Type <return> to continue, or q <return> to quit---
temp_pool=0x80fd1a8, conftree=0x80b2c48) at
config.c:1127
#18 0x080820d0 in process_resource_config_nofnmatch
(s=0x80c0800, fname=Variable "fname" is not available.
)
at config.c:1513
#19 0x08082438 in ap_process_resource_config
(s=0x80c0800,
fname=0x80f8d00
"/usr/local/apache2/conf/httpd.conf",
conftree=0x80b2c48,
p=0x80bc0a8, ptemp=0x80fd1a8) at config.c:1549
#20 0x08082c1f in ap_read_config (process=0x80bc0a8,
ptemp=0x80fd1a8,
filename=0x80a8416 "conf/httpd.conf",
conftree=0x80b2c48) at config.c:1892
#21 0x08084beb in main (argc=2, argv=0xbffffcf4) at
main.c:589

> Stack trace
>
> #0 0xb71a83b0 in _Jv_RegisterClassHookDefault () from
> /usr/lib/libgcj.so.6
> #1 0xb71a8958 in _Jv_RegisterClasses () from
> /usr/lib/libgcj.so.6
> #2 0xb7cac7a1 in frame_dummy () from
> /usr/local/lucene4c/lib/liblucene4c.so
> #3 0xb7cac428 in _init () from
> /usr/local/lucene4c/lib/liblucene4c.so
> #4 0xb7ff61ce in _dl_catch_error () from
> /lib/ld-linux.so.2
> #5 0xb7ff62ba in _dl_init () from /lib/ld-linux.so.2
> #6 0xb7edd2b2 in _dl_open () from /lib/tls/libc.so.6
> #7 0xb7ff6016 in _dl_catch_error () from
> /lib/ld-linux.so.2
> #8 0xb7edced6 in _dl_open () from /lib/tls/libc.so.6
> #9 0xb7f0b038 in dlopen () from /lib/tls/libdl.so.2
> #10 0xb7ff6016 in _dl_catch_error () from
> /lib/ld-linux.so.2
> #11 0xb7f0b4a6 in dlerror () from /lib/tls/libdl.so.2
> #12 0xb7f0afe4 in dlopen () from /lib/tls/libdl.so.2
> #13 0xb7fa32c3 in apr_dso_load (res_handle=0xbffff888,
> path=0x8115da0
> "/usr/local/apache2/modules/mod_mbox.so",
> pool=0x80bc0a8)
> at dso.c:138
> #14 0x0807e010 in load_module (cmd=0xbffffa58,
> dummy=0xbffff910,
> modname=0x8115d78 "mbox_module",
> filename=0x8115d88 "modules/mod_mbox.so")
> at mod_so.c:240
> #15 0x08080cb6 in invoke_cmd (cmd=0x80a77c0,
> parms=0xbffffa58,
> mconfig=0xbffff910, args=0x80ff1da "") at
> config.c:797
> #16 0x0808155e in ap_build_config_sub (p=Variable "p"
> is not available.
> ) at config.c:1335
> #17 0x080819ce in ap_build_config (parms=0xbffffa58,
> p=0x80bc0a8,
> ---Type <return> to continue, or q <return> to quit---
> temp_pool=0x80fd1a8, conftree=0x80b2c48) at
> config.c:1127
> #18 0x080820d0 in process_resource_config_nofnmatch
> (s=0x80c0800, fname=Variable "fname" is not available.
> )
> at config.c:1513
> #19 0x08082438 in ap_process_resource_config
> (s=0x80c0800,
> fname=0x80f8d00
> "/usr/local/apache2/conf/httpd.conf",
> conftree=0x80b2c48,
> p=0x80bc0a8, ptemp=0x80fd1a8) at config.c:1549
> #20 0x08082c1f in ap_read_config (process=0x80bc0a8,
> ptemp=0x80fd1a8,
> filename=0x80a8416 "conf/httpd.conf",
> conftree=0x80b2c48) at config.c:1892
> #21 0x08084beb in main (argc=2, argv=0xbffffcf4) at
> main.c:589
>

Well, if it's crashing inside _Jv_RegisterClassHookDefault, then perhaps
looking at that function in the GCC source would give us a clue what is
going wrong. I don't actually have time to look myself, at least not
right now, but if you find anything interesting there please let me
know. Other than that I'm running out of ideas, this may not be a
problem that can be solved without me actually poking around at it
myself, and if so I probably won't get to spend much time with it until
this weekend.

-garrett

steve johnson wrote:

> Not to sound more like a moron than I have to, but I'm
> not a developer, I'm a sysadmin. I'm trying to set up
> a development environment for someone new to
> linux/opensource to do some work this summer. While
> I'm up to building packages and hacking configurations
> (and maybe the odd header file or two) , pawing thru
> gcj source is outside my area of competence.
> It pains me to see a great opportunity like the google
> SoC go down the toilet because I can't build a working
> copy of mod_mbox with lucene4c.

I hate to break it to you, but if the person who's actually doing the
SoC work can't get the stuff he's supposed to be working on to compile
and run, then how can he possibly be expected to do the work? And even
if he can't get it to run, why isn't he the one asking these questions?

I'm sorry this isn't easier for you to get running, but if someone is
getting paid to work on this stuff, then perhaps they should be the one
working on it, and not you.

-garrett

--- Garrett Rooney <roonroonegcelectricjellyfish>
wrote:

>
> Well, if it's crashing inside
> _Jv_RJviRegisterClassHookDefaulten perhaps
> looking at that function in the GCC GCCrce would
> give us a clue what is
> going wrong. I don't actually have time to look
> myself, at least not
> right now, but if you find anything interesting
> there please let me
> know. Other than that I'm running out of ideas,
> this may not be a
> problem that can be solved without me actually
> poking around at it
> myself, and if so I probably won't get to spend much
> time with it until
> this weekend.
>
> -garrgarrett

Not to sound more like a moron than I have to, but I'm
not a developer, I'm a sysadmin. I'm trying to set up
a development environment for someone new to
linux/opensource to do some work this summer. While
I'm up to building packages and hacking configurations
(and maybe the odd header file or two) , pawing thru
gcj source is outside my area of competence.
It pains me to see a great opportunity like the google
SoC go down the toilet because I can't build a working
copy of mod_mbox with lucene4c.

Well, given the issues I've had so far (and I've got
20+ years and as first a C developer then a UNIX
sysadmin) a college kid with minimal linux experience
has got 0.0000 chance of ever making this stuff work.
While I would love to wash my hands of this I have a
vested interest in seeing the student finish this
work. And while the odds seem slim at this point they
would be zero if I wasn't doing what I'm tring to do.

The real problem here is that this project was allowed
to be considered as a SoC project as it really isn't
ready to be worked on by the SoC target audience. As
this is the first attempt to do anything like this
(SoC not mod_mbox/lucene4c) It isn't surprising that
there are a few bumps in the process. The timing for
this couldn't have been worse either with the SoC
timeframe intersecting with the move from a straight C
to a java wrapper implementation for lucene4c.
Probably if either one had been 2 months earlier or
later most of this trouble would have been avoided.
The final solution may be a request to google to
extend the SoC timeline to allow the lucene4c/mod_mbox
combination to get mature enough to do some
development on it.

I ain't bitching(much) just frustrated
Steve


--- Garrett Rooney <rooneg@electricjellyfish.net>
wrote:

> steve johnson wrote:
>
> > Not to sound more like a moron than I have to, but
> I'm
> > not a developer, I'm a sysadmin. I'm trying to
> set up
> > a development environment for someone new to
> > linux/opensource to do some work this summer.
> While
> > I'm up to building packages and hacking
> configurations
> > (and maybe the odd header file or two) , pawing
> thru
> > gcj source is outside my area of competence.
> > It pains me to see a great opportunity like the
> google
> > SoC go down the toilet because I can't build a
> working
> > copy of mod_mbox with lucene4c.
>
> I hate to break it to you, but if the person who's
> actually doing the
> SoC work can't get the stuff he's supposed to be
> working on to compile
> and run, then how can he possibly be expected to do
> the work? And even
> if he can't get it to run, why isn't he the one
> asking these questions?
>
> I'm sorry this isn't easier for you to get running,
> but if someone is
> getting paid to work on this stuff, then perhaps
> they should be the one
> working on it, and not you.
>
> -garrett
>

Any chance the core dump is being caused by me linking
directly to the liblucene4c.so instead of the .la
file?

Anyone building lucene4c into a module using the .so
file?

Anyone have a good liblucene4c.la file I can try to
hack up to make work on my systems?

Steve