[mp2] unable to compile 1.99_14 on solaris 9 + workaround
m to #9676: some missing changes from OpenBSD glob.c
9679 Up $File::Glob::VERSION, add OpenBSD glob version note
9693 $VERSION and Version() on same line provokes CPAN.pm warning
9706 #7210 broke .packlist generation
9707 ExtUtils::Installed doesn't quote regex metacharacters in paths
9775 Typo in utf8.h
9950 Revert integration of #8254,#8255 in #8620 (causes coredump)
10021 Insecure regexes
10091 $ref1 == $ref2 behaves unpredictably if not NV_PRESERVES_UV
10093 Incorrect line numbers in AutoSplit
10100 [20010514.027] PL_last_in_gv may not be GV if stale filehandle
10145 [20010515.004] Segfaults from premature GC
10203 Don't think about UTF8
10250 [20010422.005] perl -e '{s//${}/; //}' segfaults
10394 Leakage of file scope lexicals into predeclared subroutines
10404 eval.t was relying on pre-#10394 buggy behavior
10412 Rationalize locale handling to fix bugs uncovered by #10394
10422 Potential buffer overrun if the radix separator > 1 byte
10448 Lexicals outside eval weren't resolved correctly pre-#10394
10450 Optimize #10448 slightly
10543 Add LC_MESSAGES constant to POSIX module
10667 #10449 broke visibility of lexicals inside DB::DB()
10739 C fails to compile correctly
10939 Proposed fix for Pod::Man
11169 Doc patch for Tie::Hash
11374 Make h2ph grok ccsymbols fo the form 1234L, 1234ULL etc
11427 t/harness wasn't picking up all the tests
11428 run/runenv.t needs fflushNULL sanity
11431 pod/*.t tests not picked up by t/TEST either
11510 eval 'format foo=' would loop indefinitely
11713 UTF8 wasn't printing for PVMGs
11716 UTF8 flag should be meaningful only when POK
11808 [20010831.002] Bug in Term::Cap on Solaris ansi terminal
11847 Typo in perl_clone() code causes local(*foo) breakage
12005 [20010912.007] substr reference core dump
12024 Fix local() precedence bug in #8311
12303 Fix 'local $!=0;undef*STDOUT;' segfault
12304 Pod::Html makes a poor guess at author
12350 Typo in IO::Seekable doc
12496 Carp::shortmess_heavy() doesn't notice trailing newline
12549 readline() doesn't work with 'our' variables
12550 #12549 wasn't aware of strictures
12752 croak(Nullch) wasn't printing the contents of ERRSV
12811 [20011101.069] \stat('.') gives 'free unref scalar' error
12812 Slight modification of #12811
13149 Integrate #13147 from mainline (fixes nit in #10091)
13261 Integrate #8340,#13260 from mainline
Built under solaris
Compiled at Nov 4 2002 01:56:55
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
/usr/perl5/5.6.1/lib/i86pc-solaris-64int
/usr/perl5/5.6.1/lib
/usr/perl5/site_perl/5.6.1/i86pc-solaris-64int
/usr/perl5/site_perl/5.6.1
/usr/perl5/site_perl
/usr/perl5/vendor_perl/5.6.1/i86pc-solaris-64int
/usr/perl5/vendor_perl/5.6.1
/usr/perl5/vendor_perl
.
Thanks,
Marc Slagle
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] unable to compile 1.99_14 on solaris 9 + workaround
Why doesn't it use the sun compiler when compilinig mod_perl? where does cc point? How come that it has picked gcc? Compiler: cc='cc', ccflags ='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', mod_perl simply tries to use the same compiler perl was compiled with, so if perl reports cc and it's not the same compiler it was compiled with it's the problem of your installation. Theres a link at /usr/local/bin/cc pointing to /usr/local/bin/gcc. I think this can and should be fixed on the Makefile.PL level, w/o having any special-case documentation for solaris9 users :) Just help us to figure out what went wrong... The problem I've had with solaris over the years is that theres a fake cc living in /usr/ucb. Any time you run it (unless you buy the sun compiler, I assume) you get an error like "language optional software package not installed". And some software that we have had to compile just wants "cc" instead of "gcc". Instead of hacking up makefiles and such, we just make the link to let those programs compile. Many solaris admins don't have access to the sun compiler, and use the same trickery to get thier packages to compile. So what happened is that while the makefile was being built, it saw the sun-compiled perl and got the information above (compiler, etc.) During make the cc command was called, but was a link to gcc. The gcc compiler didn't like the -KPIC flag that the sun-compiled perl was built with and choked. This problem will probably pop up on any solaris 9 system with the default perl left installed (5.6.1) and 'cc' linked to 'gcc'. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[MP1] Apache segfault after serving request
#2 0x0810b6c9 in Perl_pp_entersub ()
#3 0x080ba314 in S_call_body ()
#4 0x080ba0ee in Perl_call_sv ()
#5 0x08112b2b in Perl_sv_clear ()
#6 0x08112d53 in Perl_sv_free ()
#7 0x08117995 in Perl_sv_clean_objs ()
#8 0x080b89f8 in perl_destruct ()
#9 0x0806bd6c in perl_shutdown (s=0x819e12c, p=0x8df749c) at
mod_perl.c:294
#10 0x0806ff43 in perl_child_exit_cleanup (data=0x8) at
mod_perl.c:926
#11 0x0808a8e4 in run_cleanups (c=0x8df7634) at alloc.c:1745
#12 0x08089183 in ap_clear_pool (a=0x8df749c) at alloc.c:541
#13 0x08089200 in ap_destroy_pool (a=0x8df749c) at alloc.c:571
#14 0x080965ce in clean_child_exit (code=0) at http_main.c:528
#15 0x0809942d in child_main (child_num_arg=0) at http_main.c:4367
#16 0x080999ba in make_child (s=0x819e12c, slot=0, now=1068483979) at
http_main.c:4768
#17 0x08099b20 in startup_children (number_to_start=5) at
http_main.c:4850
#18 0x0809a1bd in standalone_main (argc=4, argv=0xbfffead4) at
http_main.c:5169
#19 0x0809a9db in main (argc=4, argv=0xbfffead4) at http_main.c:5511
#20 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) list
5511STANDALONE_MAIN(argc, argv);
5512}
5513#else
5514if (!tpf_child) {
5515memcpy(tpf_server_name, input_parms.parent.servname,
5516 INETD_SERVNAME_LENGTH);
5517tpf_server_name[INETD_SERVNAME_LENGTH + 1] = '\0';
5518sprintf(tpf_mutex_key, "%.*x", TPF_MUTEX_KEY_SIZE - 1,
getpid());
5519tpf_parent_pid = getppid();
5520ap_open_logs(server_conf, plog);
(gdb)
Marc Slagle
Whapps, LLC
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [MP1] Apache segfault after serving request
> Please try this patch:
>
> Index: src/modules/perl/Table.xs
> ===
> RCS file: /home/cvs/modperl/src/modules/perl/Table.xs,v
> retrieving revision 1.10
> diff -u -r1.10 Table.xs
> --- src/modules/perl/Table.xs 23 May 2000 15:56:12 - 1.10
> +++ src/modules/perl/Table.xs 10 Nov 2003 19:46:55 -
> @@ -114,9 +114,10 @@
> Apache__Table tab;
>
> CODE:
> -tab = (Apache__Table)hvrv2table(self);
> -if(SvROK(self) && SvTYPE(SvRV(self)) == SVt_PVHV)
> +if(SvROK(self) && SvTYPE(SvRV(self)) == SVt_PVHV) {
> +tab = (Apache__Table)hvrv2table(self);
> safefree(tab);
> +}
>
> void
> FETCH(self, key)
Thanks for the reply. Unfortunately the patch didn't resolve the
problem. The backtrace does look somewhat different, its making some
new calls before the segfault that it wasn't before. Numbers 4-13 show
differently:
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
This GDB was configured as "i386-redhat-linux-gnu"...
(gdb) run -X -f /usr/skynet/conf/httpd.conf
Starting program: /usr/skynet/bin/httpd -X -f
/usr/skynet/conf/httpd.conf
Program received signal SIGSEGV, Segmentation fault.
0x0807698b in hvrv2table (rv=0x0) at perl_util.c:101
101 return (table *)SvIV((SV*)SvRV(rv));
(gdb) bt
#0 0x0807698b in hvrv2table (rv=0x0) at perl_util.c:101
#1 0x080889b6 in XS_Apache__Table_DESTROY (cv=0x81ad57c) at Table.c:150
#2 0x0810b6c5 in Perl_pp_entersub ()
#3 0x080ba310 in S_call_body ()
#4 0x080ba0ea in Perl_call_sv ()
#5 0x08112b27 in Perl_sv_clear ()
#6 0x08112d4f in Perl_sv_free ()
#7 0x081126af in Perl_sv_clear ()
#8 0x08112d4f in Perl_sv_free ()
#9 0x081031b1 in Perl_hv_free_ent ()
#10 0x081032f2 in S_hfreeentries ()
#11 0x08103c93 in Perl_hv_undef ()
#12 0x08112961 in Perl_sv_clear ()
#13 0x08112d4f in Perl_sv_free ()
#14 0x08117991 in Perl_sv_clean_objs ()
#15 0x080b89f4 in perl_destruct ()
#16 0x0806bd6c in perl_shutdown (s=0x819d0cc, p=0x8deca64) at
mod_perl.c:294
#17 0x0806ff43 in perl_child_exit_cleanup (data=0x8) at
mod_perl.c:926
#18 0x0808a8e0 in run_cleanups (c=0x8decbfc) at alloc.c:1745
#19 0x0808917f in ap_clear_pool (a=0x8deca64) at alloc.c:541
#20 0x080891fc in ap_destroy_pool (a=0x8deca64) at alloc.c:571
#21 0x080965ca in clean_child_exit (code=0) at http_main.c:528
#22 0x08099429 in child_main (child_num_arg=0) at http_main.c:4367
#23 0x080999b6 in make_child (s=0x819d0cc, slot=0, now=1068497097) at
http_main.c:4768
#24 0x08099b1c in startup_children (number_to_start=5) at
http_main.c:4850
#25 0x0809a1b9 in standalone_main (argc=4, argv=0xbfffe2c4) at
http_main.c:5169
#26 0x0809a9d7 in main (argc=4, argv=0xbfffe2c4) at http_main.c:5511
#27 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) list
5511STANDALONE_MAIN(argc, argv);
5512}
5513#else
5514if (!tpf_child) {
5515memcpy(tpf_server_name, input_parms.parent.servname,
5516 INETD_SERVNAME_LENGTH);
5517tpf_server_name[INETD_SERVNAME_LENGTH + 1] = '\0';
5518sprintf(tpf_mutex_key, "%.*x", TPF_MUTEX_KEY_SIZE - 1,
getpid());
5519tpf_parent_pid = getppid();
5520ap_open_logs(server_conf, plog);
We rebuilt the server using new clean tarballs of apache and mod_perl.
Thanks again for your help.
Marc Slagle
Whapps, LLC
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [MP1] Apache segfault after serving request
> I don't have a test to reproduce the segfault, so I'm just shooting in the > dark based on the core trace that you've kindly provided. Please revert the > previous patch and try the new one: We tried the new patch, but can still get the segfault. We wrote 3 modules that can reproduce the segfault on our system. We're using the same trickery in our production code. The segfault will occur when the server is under a bit of load, refreshing the browser repeatedly will make it die quickly. We have apache configured so the children only handle 10 requests before exiting. The transhandler will answer requests for any domain name, and strip the uri passed off of the request. It returns declined after that so our handler can step in and do its work. The handler is parsing an XML file and using XML::GDOME::XSLT to transform it into html. We used XML::LibXSLT for a while too, the segfaults were happening before we switched over. The Global Module is just a locker for storing the parts of the request we want to access from modules down the line. Some code we didn't include calls different objects based on the uri passed in. But we could reproduce the bomb without all of that. We compiled apache without expat, having read that this can cause segfaults when using some XML modules. The latest backtrace and the portion of httpd.conf that sets up the test environment are in the README for Server::Killer. We don't want to take too much of your time with this, if we knew what portion of our code was causing the bomb then we could just recode it. If you need any more information, please let us know. Thanks again, Marc Slagle Whapps, LLC Server-Killer-0.01.tar.gz Description: application/compressed-tar Server-KillerGlobal-0.01.tar.gz Description: application/compressed-tar Server-KillerTH-0.04b.tar.gz Description: application/compressed-tar -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [MP1] Apache segfault after serving request
> I don't have a test to reproduce the segfault, so I'm just shooting in the > dark based on the core trace that you've kindly provided. Please revert the > previous patch and try the new one: One more bit of information: we were using an older version of Apache::Request, but upgraded it to the newest version. All parts of the setup of the server (apache, modules, etc) were all make tested and passed. Marc Slagle Whapps, LLC -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [MP1] Apache segfault after serving request
> ALso, Marc, I'd suggest to rethink your coding techniques. Instead of using > globals you should probably encapsulate all the data that you want to pass > around into a single object and and pass it around, or using a Singleton > object. Globals are not the best way to go in majority of cases. Thanks for all the help. We'll be looking into the Singleton object today. I agree that globals are not the best way to go. We will attempt to get our examples as small as possible if we need to post in the future. Marc Slagle Whapps, LLC -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] mod_perl 2.0.0 (preview!)
Philippe M. Chiasson wrote: #* Allright folks, RC6 was released a while ago, and various issues were resolved. According to our planned schedule, I am releasing a mod_perl-2.0.0 preview! As before, this is your last chance to affect the new API, since after 2.0.0 is released, incompatible API changes will not happen. So, one more time, test this tarball as much as possible. If all is well, this could become the official 2.0.0 release. *# Builds and all tests pass on Solaris 9 x86, Perl 5.8.6 Marc Slagle
Re: design patters with mod_perl
Greger wrote: As for now, I return XML from the package methods, and use XSLT for the transformation to XHTML. This works very well, seems flexible, but are there better ways? I guess it all depends on what one is doing, naturally. In this case it is an application using the mysql database. We are using a home-grown application framework that does something very similar to this. We use one mod_perl application to generate the XML, and another one to do the XSLT transforms. This lets us spread the application out over our hardware nicely. If you are doing something like this, I can say you aren't wasting your time with a framework that can't scale up with your application. It all comes down to if you would rather be creating your own framework, or using one of the many good frameworks already out there and just writing the guts of your application. Marc Slagle Online-Rewards 403 Vine Street, Second Floor Tel: 513-665-9070 ext 313 http://www.online-rewards.com
