Re: [mp1] Still can not get working DSO configuration on Tru64
Marcin Kasperski <[EMAIL PROTECTED]> writes: > > The results are exactly the same: link succeeded, > > PL_perl_destruct_level is unresolved while running apache. > > I found the workaround to avoid this effect: slightly patching apache > build procedure so that the httpd binary is linked with perl > libperl.so helped. The error disappears... now I get the coredump > during the application startup. In case I manage to diagnose this core > somehow, I will mention it here. After recompiling perl, apache and modperl with debugging enabled I got the following backtrace. Does it reminds anything to anyone? I suspect something wrong in the fact, that perl_startup is called so late (during processing some PerlModule...) (Carp module mentioned there just happened to be the first PerlModule mentioned in my apache config) /apache-1.3.27, modperl-1.27/ Core file produced from executable 'httpd' Thread terminated at PC 0x3ffbff67de8 by signal SEGV (ladebug) where >0 0x3ffbff67de8 in S_new_he() "hv.c":26 #1 0x3ffbff6b194 in Perl_share_hek(str=0x3feed70="@", len=1, hash=66) "hv.c":1484 #2 0x3ffbff688c8 in Perl_hv_store(hv=0x140048cb0, key=0x3feed70="@", klen=1, val=0x140048d80, hash=66) "hv.c":413 #3 0x3ffbff681f0 in Perl_hv_fetch(hv=0x140048cb0, key=0x3feed70="@", klen=1, lval=1) "hv.c":210 #4 0x3ffbff03b7c in Perl_gv_fetchpv(nambeg=0x3feed70="@", add=1, sv_type=4) "gv.c":669 #5 0x3ffbfefe56c in S_init_main_stash() "perl.c":2523 #6 0x3ffbfef9c18 in S_parse_body(env=0x0, xsinit=0x3000180ecd8) "perl.c":951 #7 0x3ffbfef9b0c in perl_parse(my_perl=0x140034040, xsinit=0x3000180ecd8, argc=3, argv=0x11fff9c48, env=0x0) "perl.c":895 #8 0x3000180f58c in perl_startup(s=0x14001e860, p=0x14001e818) "mod_perl.c":702 #9 0x30001817070 in perl_cmd_module(parms=0x11fffbe10, dummy=0x14001fdd8, arg=0x140020260="Carp") "perl_config.c":582 #10 0x12001cee8 in invoke_cmd(cmd=0x30041842828, parms=0x11fffbe10, mconfig=0x14001fdd8, args=0x11fff9daf="") "http_config.c":918 #11 0x12001d3ec in ap_handle_command(parms=0x11fffbe10, config=0x14001f250, l=0x11fff9da0="PerlModule Carp") "http_config.c":1030 #12 0x12001d4f8 in ap_srm_command_loop(parms=0x11fffbe10, config=0x14001f250) "http_config.c":1044 #13 0x12001db48 in ap_process_resource_config(s=0x14001e860, fname=0x1400112f0="/home/marcink/GAUSS/igoweb/src/tests/imf_efficiency/apache.conf", p=0x14001e818, ptemp=0x140338818) "http_config.c":1332 #14 0x12001ea30 in ap_read_config(p=0x14001e818, ptemp=0x140338818, confname=0x1400112f0="/home/marcink/GAUSS/igoweb/src/tests/imf_efficiency/apache.conf") "http_config.c":1616 #15 0x120010208 in standalone_main(argc=4, argv=0x11fffc018) "http_main.c":5071 #16 0x120010ce8 in main(argc=4, argv=0x11fffc018) "http_main.c":5456 #17 0x12000aad8 in __start(...) in /home/marcink/tools/apache/bin/httpd When I removed PerlModule directives and sticked only with PerlRequire, it occured that I must add 'use Apache;' on the beginning to use things like Apache->push_handlers (on normal installations it was not necessary, here I got ). And then I got similar coredump: Core file produced from executable 'httpd' Thread terminated at PC 0x3ffbff67de8 by signal SEGV (ladebug) where >0 0x3ffbff67de8 in S_new_he() "hv.c":26 #1 0x3ffbff6b194 in Perl_share_hek(str=0x3feed70="@", len=1, hash=66) "hv.c":1484 #2 0x3ffbff688c8 in Perl_hv_store(hv=0x140048cb0, key=0x3feed70="@", klen=1, val=0x140048d80, hash=66) "hv.c":413 #3 0x3ffbff681f0 in Perl_hv_fetch(hv=0x140048cb0, key=0x3feed70="@", klen=1, lval=1) "hv.c":210 #4 0x3ffbff03b7c in Perl_gv_fetchpv(nambeg=0x3feed70="@", add=1, sv_type=4) "gv.c":669 #5 0x3ffbfefe56c in S_init_main_stash() "perl.c":2523 #6 0x3ffbfef9c18 in S_parse_body(env=0x0, xsinit=0x3000180ecd8) "perl.c":951 #7 0x3ffbfef9b0c in perl_parse(my_perl=0x140034040, xsinit=0x3000180ecd8, argc=3, argv=0x11fff9c48, env=0x0) "perl.c":895 #8 0x3000180f58c in perl_startup(s=0x14001e860, p=0x14001e818) "mod_perl.c":702 #9 0x30001817274 in perl_cmd_require(parms=0x11fffbe10, dummy=0x14001fdd8, arg=0x140020260="/home/marcink/src/tests/startup.pl") "perl_config.c":613 #10 0x12001cee8 in invoke_cmd(cmd=0x30041842800, parms=0x11fffbe10, mconfig=0x14001fdd8, args=0x11fff9deb="") "http_config.c":918 #11 0x12001d3ec in ap_handle_command(parms=0x11fffbe10, config=0x14001f250, l=0x11fff9da0="PerlRequire /home/marcink/src/tests/startup.pl") "http_config.c":1030 #12 0x12001d4f8 in ap_srm_command_loop(parms=0x11fffbe10, config=0x14001f250) "http_config.c":1044 #13 0x12001db48 in ap_process_resource_config(s=0x14001e860, fname=0x1400112f0="/home/marcink/src/tests/apache.conf", p=0x14001e818, ptemp=0x140235818) "http_config.c":1332 #14 0x12001ea30 in ap_read_config(p=0x14001e818, ptemp=0x140235818, confname=0x1400112f0="/home/marcink/src/tests/efficiency/apache.conf") "http_config.c":1616 #15 0x120010208 in standalone_main(argc=4, argv=0x11fffc018) "http_main.c":5071 #16 0x120010ce8 in main(argc=4, argv=
Re: [mp1] Still can not get working DSO configuration on Tru64
> The results are exactly the same: link succeeded, > PL_perl_destruct_level is unresolved while running apache. I found the workaround to avoid this effect: slightly patching apache build procedure so that the httpd binary is linked with perl libperl.so helped. The error disappears... now I get the coredump during the application startup. In case I manage to diagnose this core somehow, I will mention it here. -- ( Marcin Kasperski | A complex system designed from scratch never works) ( http://www.mk.w.pl |and cannot be patched to make it work. (Booch) ) () ( Porady dla programisty Oracle: http://www.mk.w.pl/porady/porady_oracle )
Re: [mp1] Still can not get working DSO configuration on Tru64
> The problem is that the > -Wl,-rpath,/tools/perl/lib/5.6.1/alpha-dec_osf/CORE > option (which, by the way, is returned by > perl -V:ccdlflags > when perl is compiled with -Duseshrplib) is not an option for 'ld' but > for 'cc'. In fact it means 'dear cc, be so kind and pass to ld > the option -rpath /tools/perl/lib/5.6.1/alpha-dec_osf/CORE). ld does > not know '-Wl' and complains. As > perl -V:ld > returns 'ld', maybe this is the problem in perl, not in modperl, but I > am not sure. > > I patched it just by replacing 'ld' with 'cc' in the Makefile > generated by configure script - such correction caused link step to > succeed (and 'unresolved PL_perl_destruct_level to be reported while > apache startup' :-( ) > > Currently I plan to check the opposite correction (using -rpath > .. and ld as link command), maybe this will change something. I tried it - I left ld as link command but replaced in Makefile -Wl,-rpath,/tools/... with -rpath /tools/... The results are exactly the same: link succeeded, PL_perl_destruct_level is unresolved while running apache. -- ( Marcin Kasperski | Communication takes place between people, documents ) ( http://www.mk.w.pl |are secondary. (Booch) ) () ( Sztuczki i kruczki w C++: http://www.mk.w.pl/porady/porady_cplusplus )
Re: [mp1] Still can not get working DSO configuration on Tru64
Stas Bekman <[EMAIL PROTECTED]> writes: > >>Marcin Kasperski wrote: > [...] > > It seems to me, they had problem with the '-Wl,-rpath' issue which I > > found to be minor and easily patched (by the way: maybe someone would > > want to correct it in distribution?). > > I wasn't following that thread, but if you send a patch that solves > that problem, I'd be more than happy to commit it to the main distro. Hmm, so far I can only offer 'half-patch' and the problem explanation (I do not understand configure scripts well enough to guess how to correct them). The problem is that the -Wl,-rpath,/tools/perl/lib/5.6.1/alpha-dec_osf/CORE option (which, by the way, is returned by perl -V:ccdlflags when perl is compiled with -Duseshrplib) is not an option for 'ld' but for 'cc'. In fact it means 'dear cc, be so kind and pass to ld the option -rpath /tools/perl/lib/5.6.1/alpha-dec_osf/CORE). ld does not know '-Wl' and complains. As perl -V:ld returns 'ld', maybe this is the problem in perl, not in modperl, but I am not sure. I patched it just by replacing 'ld' with 'cc' in the Makefile generated by configure script - such correction caused link step to succeed (and 'unresolved PL_perl_destruct_level to be reported while apache startup' :-( ) Currently I plan to check the opposite correction (using -rpath ... and ld as link command), maybe this will change something. -- ( Marcin Kasperski | Working overtime sucks the spirit and motivation ) ( http://www.mk.w.pl | out of a team. (Wells) ) () ( Porady dla twórców serwisów WWW: http://www.mk.w.pl/porady/porady_www )
Re: [mp1] Still can not get working DSO configuration on Tru64
Stas Bekman <[EMAIL PROTECTED]> writes: > Marcin Kasperski wrote: > >>In short: I tried different compilation methods with two possible > >>outcomes: > >>a) apache and modperl compile succesfully but I get coredump while the > >> application is starting (in all cases SEGVs, in some cases core's > >> confused the debugger, in other I managed to notice __at_fork in > >> backtrace) > >> b) everything seem to compile succesfully but I get dlopen: > >>/tools/apache/libexec/mod_perl.so: symbol > >>"PL_perl_destruct_level" unresolved > > >> while the application is starting > > Maybe it is worth noting, that I happened to get b) also when I > > > compiled perl with shared perl library (in contrary to suggestion > > found in modperl docs that building perl with shared library should > > help). > > 2 years ago, there was a similar struggle as you can see from this > thread: http://marc.theaimsgroup.com/?t=9744223061&r=1&w=2 May > be those participants are still using True64 and can give you some > hints? It seems to me, they had problem with the '-Wl,-rpath' issue which I found to be minor and easily patched (by the way: maybe someone would want to correct it in distribution?). And all they wanted was to get statically linked modperl. This is the thing I already have. Maybe I will post a question to tru64-managers... -- ( Marcin Kasperski | (...) the only completion criterion for the Analysis ) ( http://www.mk.w.pl | and Design phases is - the date. (Martin) ) () ( Nie gub zgłoszeń błędów: http://www.mk.w.pl/narzedzia/narzedzia_bugewid)
Re: [mp1] Still can not get working DSO configuration on Tru64
Marcin Kasperski wrote: In short: I tried different compilation methods with two possible outcomes: a) apache and modperl compile succesfully but I get coredump while the application is starting (in all cases SEGVs, in some cases core's confused the debugger, in other I managed to notice __at_fork in backtrace) b) everything seem to compile succesfully but I get dlopen: /tools/apache/libexec/mod_perl.so: symbol "PL_perl_destruct_level" unresolved while the application is starting Maybe it is worth noting, that I happened to get b) also when I compiled perl with shared perl library (in contrary to suggestion found in modperl docs that building perl with shared library should help). 2 years ago, there was a similar struggle as you can see from this thread: http://marc.theaimsgroup.com/?t=9744223061&r=1&w=2 May be those participants are still using True64 and can give you some hints? __ 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: [mp1] Still can not get working DSO configuration on Tru64
> In short: I tried different compilation methods with two possible > outcomes: > a) apache and modperl compile succesfully but I get coredump while the >application is starting (in all cases SEGVs, in some cases core's >confused the debugger, in other I managed to notice __at_fork in >backtrace) > b) everything seem to compile succesfully but I get >dlopen: /tools/apache/libexec/mod_perl.so: symbol "PL_perl_destruct_level" >unresolved >while the application is starting Maybe it is worth noting, that I happened to get b) also when I compiled perl with shared perl library (in contrary to suggestion found in modperl docs that building perl with shared library should help).