Re: [OT] Re: Hiding perl code
On Mon, 22 Jul 2002 10:17:21 -0500 (CDT), Dave Rolsky [EMAIL PROTECTED] said:
use Filter::decrypt ;
ÿ £j¨tBÃavð@¥£hK6' {'ÂÃ^zÂ'
[]
Of course, perl itself (or mod_perl) sees the cleartext, so a good
hacker will find a way to break it.
perl -MO=Deparse /path/to/encrypted/file(s)
Funny, that would be a nice test. Unfortunately I have only encrypted
files for an old perl and have never tried with a perl that is
Deparse-enabled. If anybody else is willing to test how well Dave's
suggestion works, please post your experience.
--
andreas
Re: Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
5.8.0-RC3 still produces the SEGV with apache 1.3.26, mod_perl 1.27, Apache::Request 1.0 and MaxRequestPerChild 0. My recipe to reproduce the SEGV currently is: Set MaxRequestPerChild to 1 and request a static image. Unless the problem is fixed before 5.8.0 comes out (i.e.~Thursday), I fear we must document the fact: --- perl-5.7.3@17527/pod/perldelta.pod~ Sun Jul 14 02:18:36 2002 +++ perl-5.7.3@17527/pod/perldelta.pod Sun Jul 14 15:34:54 2002 -3133,6 +3133,10 Use mod_perl 1.27 or higher. +=head2 mod_perl 1.27 sometimes produces a segmentation fault + +Setting MaxRequestsPerChild to 0 seems to work around the problem. + =head2 lib/ftmp-security tests warn 'system possibly insecure' Don't panic. Read the 'make test' section of INSTALL instead. Jim, in any case it would be great if you could release a new Apache::Request with the two fixes that Doug has posted to the list[1], so that people need not fall into the two already fixed traps.--Thanks! -- andreas [1] http://mathforum.org/epigone/modperl/zhoolamgheld and http://mathforum.org/epigone/modperl/glongsnaysimp
Re: Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
On Sat, 29 Jun 2002 16:48:57 -0700 (PDT), Doug MacEachern [EMAIL PROTECTED] said: On Mon, 24 Jun 2002, Andreas J. Koenig wrote: This stack trace is all I have. I cannot reproduce this SEGV at will, so it will be difficult to obtain additional information. All I can do is let the webserver run in -X mode and wait. I have no hints (yet) what kind of request triggers it. ... #6 0x820baa2 in PerlIO_cleanup (my_perl=0x82fc9c8) at perlio.c:2124 #7 0x810d298 in perl_destruct (my_perl=0x82fc9c8) at perl.c:490 #8 0x8099039 in perl_shutdown (s=0x82f140c, p=0x88f9c24) at mod_perl.c:294 #9 0x809b373 in perl_child_exit (s=0x82f140c, p=0x88f9c24) at mod_perl.c:958 #10 0x809afce in perl_child_exit_cleanup (data=0x88f9db4) at mod_perl.c:926 looks like a leaked PerlIO* from Request.xs, as this is happening when the child is killed by apache (e.g. MaxRequestsPerChild reached). patch below may cure, seems like a better approach in any case. it is ugly here because the FILE was opened by an apache api function which will close it when the request pool is cleared, so we must dup. Thanks Doug, another great step forward! I can confirm that setting MaxRequestPerChild to 0 is an excellent way to avert the SEGV. But unfortunately your patch doesn't cure completely. This is the latest stack trace I got after I applied your patch. It was triggered by a static file request that did not call a mod_perl handler. MaxRequestPerChild was set to 3. Program received signal SIGSEGV, Segmentation fault. 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x82fd0a0) at malloc.c:3097 3097malloc.c: No such file or directory. (gdb) bt #0 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x82fd0a0) at malloc.c:3097 #1 0x400d7f5a in __libc_free (mem=0x82fd0a8) at malloc.c:3023 #2 0x8169142 in Perl_safesysfree (where=0x82fd0a8) at util.c:151 #3 0x8197ea2 in Perl_sv_clear (my_perl=0x82fc9c8, sv=0x86ed0bc) at sv.c:5049 #4 0x819831d in Perl_sv_free (my_perl=0x82fc9c8, sv=0x86ed0bc) at sv.c:5192 #5 0x818d4d8 in do_clean_all (my_perl=0x82fc9c8, sv=0x86ed0bc) at sv.c:400 #6 0x818d147 in S_visit (my_perl=0x82fc9c8, f=0x818d47c do_clean_all) at sv.c:292 #7 0x818d4fe in Perl_sv_clean_all (my_perl=0x82fc9c8) at sv.c:418 #8 0x810ddd5 in perl_destruct (my_perl=0x82fc9c8) at perl.c:771 #9 0x8099039 in perl_shutdown (s=0x82f140c, p=0x8903d6c) at mod_perl.c:294 #10 0x809b373 in perl_child_exit (s=0x82f140c, p=0x8903d6c) at mod_perl.c:958 #11 0x809afce in perl_child_exit_cleanup (data=0x8903efc) at mod_perl.c:926 #12 0x80ddc8e in run_cleanups () #13 0x80dc4bd in ap_clear_pool () #14 0x80dc531 in ap_destroy_pool () #15 0x80e945b in clean_child_exit () #16 0x80ec707 in child_main () #17 0x80eccb0 in make_child () #18 0x80ece09 in startup_children () #19 0x80ed466 in standalone_main () #20 0x80edc33 in main () #21 0x4009698b in __libc_start_main (main=0x80ed8dc main, argc=4, argv=0xbcc4, init=0x807a6f8 _init, fini=0x828da5c _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xbcbc) at ../sysdeps/generic/libc-start.c:92 -- andreas
Re: Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
On Sun, 30 Jun 2002 15:30:18 -0700 (PDT), Doug MacEachern [EMAIL PROTECTED]
said:
#0 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x82fd0a0) at malloc.c:3097
#1 0x400d7f5a in __libc_free (mem=0x82fd0a8) at malloc.c:3023
#2 0x8169142 in Perl_safesysfree (where=0x82fd0a8) at util.c:151
#3 0x8197ea2 in Perl_sv_clear (my_perl=0x82fc9c8, sv=0x86ed0bc) at sv.c:5049
hmm, looks like double free of SvPVX. if you could in gdb:
(gdb) up 3
(gdb) print *sv
(gdb) print *(XPV*)sv-sv_any
(gdb) up 3
#3 0x8197fa2 in Perl_sv_clear (my_perl=0x82fcaa8, sv=0x86ed170) at sv.c:5049
5049Safefree(SvPVX(sv));
(gdb) print *sv
$1 = {sv_any = 0x8638d10, sv_refcnt = 0, sv_flags = 4194307}
(gdb) print *(XPV*)sv-sv_any
$2 = {xpv_pv = 0x82fd188 , xpv_cur = 0, xpv_len = 140741932}
--
andreas
Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
This stack trace is all I have. I cannot reproduce this SEGV at will, so it will be difficult to obtain additional information. All I can do is let the webserver run in -X mode and wait. I have no hints (yet) what kind of request triggers it. Again, as in my older posted SEGV, the line numbers are wrong, I do not know why. I'd appreciate any hint what I could try to come closer to a real bugreport. Program received signal SIGSEGV, Segmentation fault. 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x8907350) at malloc.c:3097 3097malloc.c: No such file or directory. (gdb) bt #0 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x8907350) at malloc.c:3097 #1 0x400d7f5a in __libc_free (mem=0x8907c88) at malloc.c:3023 #2 0x400d044b in _IO_new_fclose (fp=0x8907c88) at iofclose.c:61 #3 0x820c861 in PerlIOStdio_close (my_perl=0x82fc9c8, f=0x8303a00) at perlio.c:2638 #4 0x820a329 in Perl_PerlIO_close (my_perl=0x82fc9c8, f=0x8303a00) at perlio.c:1206 #5 0x8208b81 in PerlIO_cleantable (my_perl=0x82fc9c8, tablep=0x82fd3a0) at perlio.c:498 #6 0x820baa2 in PerlIO_cleanup (my_perl=0x82fc9c8) at perlio.c:2124 #7 0x810d298 in perl_destruct (my_perl=0x82fc9c8) at perl.c:490 #8 0x8099039 in perl_shutdown (s=0x82f140c, p=0x88f9c24) at mod_perl.c:294 #9 0x809b373 in perl_child_exit (s=0x82f140c, p=0x88f9c24) at mod_perl.c:958 #10 0x809afce in perl_child_exit_cleanup (data=0x88f9db4) at mod_perl.c:926 #11 0x80ddc8e in run_cleanups () #12 0x80dc4bd in ap_clear_pool () #13 0x80dc531 in ap_destroy_pool () #14 0x80e945b in clean_child_exit () #15 0x80ec707 in child_main () #16 0x80eccb0 in make_child () #17 0x80ece09 in startup_children () #18 0x80ed466 in standalone_main () #19 0x80edc33 in main () #20 0x4009698b in __libc_start_main (main=0x80ed8dc main, argc=4, argv=0xbcd4, init=0x807a6f8 _init, fini=0x828da5c _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xbccc) at ../sysdeps/generic/libc-start.c:92 # /usr/local/perl-5.8.0-RC2/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.2.18pre15, archname=i686-linux-multi uname='linux pause.perl.org 2.2.18pre15 #5 fri oct 13 21:59:16 cest 2000 i686 unknown ' config_args='-des -Dprefix=/usr/local/perl-5.8.0-RC2 -Dinstallusrbinperl=n -Uversiononly -Dusemultiplicity -Doptimize=-g' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-g', cppflags='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lposix -lcrypt -lutil libc=/lib/libc-2.1.3.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.1.3' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING MULTIPLICITY USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Jun 24 2002 06:49:05 INC: /usr/local/perl-5.8.0-RC2/lib/5.8.0/i686-linux-multi /usr/local/perl-5.8.0-RC2/lib/5.8.0 /usr/local/perl-5.8.0-RC2/lib/site_perl/5.8.0/i686-linux-multi /usr/local/perl-5.8.0-RC2/lib/site_perl/5.8.0 /usr/local/perl-5.8.0-RC2/lib/site_perl . -- andreas
Re: SEGV in bleadperl@17165 under mod_perl
On Wed, 12 Jun 2002 23:45:41 +0200, [EMAIL PROTECTED] (Andreas J. Koenig) said: Currently I have a testcase that is still 7300 lines of perl code for the server (after all these are in one file) but only 50 lines for the client. I hope to cut that down to a reasonable size tomorrow. I fear I have to give up on this, I cannot cut the test case below 2800 lines. I cannot make it database-independent either. Whatever I cut out, the SEGV goes away. :-( I have switched to blead@17207 (apache is 1.3.24, mod_perl is 1.27) and this is the stack trace today. The line numbers are again wrong and I have no idea why. Please take another *sharp* look. If this bug cannot be fixed, I cannot upgrade PAUSE to 5.8.0 (unless I rename it to PAUSEGV :-) Program received signal SIGSEGV, Segmentation fault. 0x400ed761 in _IO_fflush (fp=0x877f1e0) at iofflush.c:43 43 iofflush.c: No such file or directory. (gdb) bt #0 0x400ed761 in _IO_fflush (fp=0x877f1e0) at iofflush.c:43 #1 0x8205fea in PerlIOStdio_flush (my_perl=0x82f4258, f=0x82fb298) at perlio.c:2738 #2 0x8203fde in Perl_PerlIO_flush (my_perl=0x82f4258, f=0x82fb298) at perlio.c:1459 #3 0x82040a8 in Perl_PerlIO_flush (my_perl=0x82f4258, f=0x82fb298) at perlio.c:1487 #4 0x8173e8f in Perl_my_popen (my_perl=0x82f4258, cmd=0x88b8fc1 -, mode=0xb524 w) at util.c:2080 #5 0x81e3297 in Perl_do_openn (my_perl=0x82f4258, gv=0x88c5f34, name=0x88b8fc1 -, len=1, as_raw=0, rawmode=0, rawperm=0, supplied_fp=0x0, svp=0x84f7098, num_svs=0) at doio.c:282 #6 0x81cbda3 in Perl_pp_open (my_perl=0x82f4258) at pp_sys.c:542 #7 0x816eb43 in Perl_runops_debug (my_perl=0x82f4258) at dump.c:1398 #8 0x81174a3 in S_call_body (my_perl=0x82f4258, myop=0xb758, is_eval=0) at perl.c:2044 #9 0x8117003 in Perl_call_sv (my_perl=0x82f4258, sv=0x8387470, flags=4) at perl.c:1962 #10 0x809da38 in perl_call_handler (sv=0x8387470, r=0x87869ac, args=0x0) at mod_perl.c:1658 #11 0x809cbc4 in perl_run_stacked_handlers (hook=0x828e399 PerlHandler, r=0x87869ac, handlers=0x83873ec) at mod_perl.c:1371 #12 0x809a637 in perl_handler (r=0x87869ac) at mod_perl.c:897 #13 0x80e6379 in ap_invoke_handler () at eval.c:88 #14 0x80fbbdf in process_request_internal () at eval.c:88 #15 0x80fbc4a in ap_process_request () at eval.c:88 #16 0x80f2897 in child_main () at eval.c:88 #17 0x80f2a55 in make_child () at eval.c:88 #18 0x80f2bd6 in startup_children () at eval.c:88 #19 0x80f326d in standalone_main () at eval.c:88 #20 0x80f3acc in main () at eval.c:88 #21 0x400a475d in __libc_start_main (main=0x80f3738 main, argc=4, ubp_av=0xbae4, init=0x807a628 _init, fini=0x8286704 _fini, rtld_fini=0x4000b8f4 _dl_fini, stack_end=0xbadc) at ../sysdeps/generic/libc-start.c:129 Loaded modules of the application are quite a lot: Apache Apache::Connection Apache::Constants Apache::Constants::Exports Apache::HeavyCGI Apache::HeavyCGI::Date Apache::HeavyCGI::Exception Apache::HeavyCGI::ExePlan Apache::HeavyCGI::Layout Apache::Request Apache::Server Apache::Status Apache::Symbol Apache::Table Apache::URI AutoLoader B Carp Class::Singleton Compress::Zlib Config Cwd DBD::mysql DBI Data::Dumper Devel::Symdump DirHandle DynaLoader Encode Encode::Alias Encode::Config Encode::Encoding Exporter Exporter::Heavy ExtUtils::Manifest Fcntl File::Basename File::Copy File::Find File::Spec File::Spec::Unix HTML::Entities HTML::Parser HTTP::Date IO IO::File IO::Handle IO::Seekable List::Util Mail::Mailer Mail::Mailer::rfc822 Mail::Mailer::sendmail Mail::Send Scalar::Util SelectSaver String::Random Symbol Text::Tabs Text::Wrap Time::HiRes Time::Local URI URI::Escape URI::URL URI::WithBase URI::_generic URI::_query URI::_server URI::_userpass URI::ftp Unicode::String XML::Parser XML::Parser::Expat XSLoader base bytes constant fields integer lib mod_perl overload pause_1999::authensegv pause_1999::configsegv re strict utf8 vars warnings warnings::register Most of the modules are not involved in any action, most of the testscript is unused code. The test script only does the following: 1. Authentication via DBI (mysql) 2. Receive an uploaded file via Apache::Request 3. Send mail via Mail::Mailer (sendmail) Action must be repeated about 6-8 times, only then the SEGV is reached. -- andreas
Re: SEGV in bleadperl@17165 under mod_perl
On Thu, 13 Jun 2002 15:11:04 -0700 (PDT), Doug MacEachern [EMAIL PROTECTED] said: patch below also cures (when calling system() with Apache::Upload handles still alive). Thank you so much, Doug. Your diagnostics confirmed: the upload filehandle was still in scope. The fix to Request.xs fixes the bug as does narrowing the scope of the filehandle. Phew! -- andreas
Re: SEGV in bleadperl@17165 under mod_perl
On Wed, 12 Jun 2002 17:18:53 +0100, Nick Ing-Simmons [EMAIL PROTECTED] said: Is this apache running multi-threaded? or just serially ? So far only tested with -Dusemultiplicity -Duseperlio. IIRC the back trace the SEGV was in stdio rather than in perl itself, suggesting that something else (the child?, another thread?) had done something nasty to the FILE *. Currently I have a testcase that is still 7300 lines of perl code for the server (after all these are in one file) but only 50 lines for the client. I hope to cut that down to a reasonable size tomorrow. Does it work with PERLIO=perlio or Configure -Ud_stdstdio ? Neither nor. -- andreas
SEGV in bleadperl@17165 under mod_perl
PAUSE is suffering from a SEGV since I installed RC1. After I upgraded yesterday to snapshot 17165 I finally caught the following within gdb. I'd appreciate further instructions where to go from here. Program received signal SIGSEGV, Segmentation fault. 0x400d05ff in _IO_fflush (fp=0x89e4178) at iofflush.c:41 41 iofflush.c: No such file or directory. (gdb) bt #0 0x400d05ff in _IO_fflush (fp=0x89e4178) at iofflush.c:41 #1 0x820ed73 in PerlIOStdio_flush (my_perl=0x82ffcc8, f=0x8306d30) at perlio.c:2728 #2 0x820cefb in Perl_PerlIO_flush (my_perl=0x82ffcc8, f=0x8306d30) at perlio.c:1449 #3 0x820cfc5 in Perl_PerlIO_flush (my_perl=0x82ffcc8, f=0x8306d30) at perlio.c:1477 #4 0x816fc96 in Perl_my_popen (my_perl=0x82ffcc8, cmd=0x8a073f1 -, mode=0xb828 w) at util.c:2080 #5 0x81e5875 in Perl_do_openn (my_perl=0x82ffcc8, gv=0x8a4b104, name=0x8a073f1 -, len=1, as_raw=0, rawmode=0, rawperm=0, supplied_fp=0x0, svp=0x8592824, num_svs=0) at doio.c:282 #6 0x81cee63 in Perl_pp_open (my_perl=0x82ffcc8) at pp_sys.c:542 #7 0x816ab3e in Perl_runops_debug (my_perl=0x82ffcc8) at dump.c:1398 #8 0x81133dc in S_call_body (my_perl=0x82ffcc8, myop=0xba00, is_eval=0) at perl.c:2039 #9 0x8112f27 in Perl_call_sv (my_perl=0x82ffcc8, sv=0x8504644, flags=4) at perl.c:1957 #10 0x809f5a0 in perl_call_handler (sv=0x8504644, r=0x890984c, args=0x0) at mod_perl.c:1658 #11 0x809e616 in perl_run_stacked_handlers (hook=0x82978b9 PerlHandler, r=0x890984c, handlers=0x843426c) at mod_perl.c:1371 #12 0x809b482 in perl_handler (r=0x890984c) at mod_perl.c:897 #13 0x80e39f3 in ap_invoke_handler (r=0x890984c) at http_config.c:537 #14 0x80f8219 in process_request_internal (r=0x890984c) at http_request.c:1308 #15 0x80f827c in ap_process_request (r=0x890984c) at http_request.c:1324 #16 0x80ef61c in child_main (child_num_arg=0) at http_main.c:4596 #17 0x80ef7b0 in make_child (s=0x82f470c, slot=0, now=1023774076) at http_main.c:4711 #18 0x80ef909 in startup_children (number_to_start=2) at http_main.c:4793 #19 0x80eff66 in standalone_main (argc=5, argv=0xbc64) at http_main.c:5098 #20 0x80f0723 in main (argc=5, argv=0xbc64) at http_main.c:5443 # /usr/local/perl-5.7.3@17165/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0 patch 17164) configuration: Platform: osname=linux, osvers=2.2.18pre15, archname=i686-linux-multi uname='linux pause.perl.org 2.2.18pre15 #5 fri oct 13 21:59:16 cest 2000 i686 unknown ' config_args='-Dprefix=/usr/local/perl-5.7.3@17165 -Dinstallusrbinperl=n -Uversiononly -Doptimize=-g -des -Dusedevel -Dusemultiplicity' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-g', cppflags='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lposix -lcrypt -lutil libc=/lib/libc-2.1.3.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.1.3' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING MULTIPLICITY USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Locally applied patches: DEVEL17164 Built under linux Compiled at Jun 10 2002 17:27:08 INC: /usr/local/perl-5.7.3@17165/lib/5.8.0/i686-linux-multi /usr/local/perl-5.7.3@17165/lib/5.8.0 /usr/local/perl-5.7.3@17165/lib/site_perl/5.8.0/i686-linux-multi /usr/local/perl-5.7.3@17165/lib/site_perl/5.8.0 /usr/local/perl-5.7.3@17165/lib/site_perl -- andreas
Re: SEGV in bleadperl@17165 under mod_perl
As Jarkko and Nick have pointed out, line numbering is off. I cannot find out why this is the case, the sources *are* from 17165 as I can verify via Apache::Status. On Tue, 11 Jun 2002 08:23:18 -0700 (PDT), Doug MacEachern [EMAIL PROTECTED] said: doug On Tue, 11 Jun 2002, Andreas J. Koenig wrote: PAUSE is suffering from a SEGV since I installed RC1. After I upgraded yesterday to snapshot 17165 I finally caught the following within gdb. I'd appreciate further instructions where to go from here. doug test case? If you had a chance to log into PAUSE, I can send you instructions how to start a server for testing. Requirement to provoke the SEGV seems to be - upload a file (which I do via Apache::Request) and - submit some menu item that sends mail (which I do via Mail::Mailer), e.g. change your name I seem to recall, that once I needed yet another mail sending action, but I'm not sure. #4 0x816fc96 in Perl_my_popen (my_perl=0x82ffcc8, cmd=0x8a073f1 -, mode=0xb828 w) at util.c:2080 doug looks like something along the lines of: doug open my $foo, '|-' or ...; This is indeed done by Mail::Mailer. -- andreas
Re: loss of shared memory in parent httpd
On Thu, 14 Mar 2002 07:25:27 -0500, Bill Marrs [EMAIL PROTECTED] said:
It's copy-on-write. The swap is a write-to-disk.
There's no such thing as sharing memory between one process on disk(/swap)
and another in memory.
agreed. What's interesting is that if I turn swap off and back on
again, the sharing is restored! So, now I'm tempted to run a crontab
every 30 minutes that turns the swap off and on again, just to keep
the httpds shared. No Apache restart required!
Funny, I'm doing this for ages and I never really knew why, you just
found the reason, Thank You! My concerns were similar to yours but on
a smaller scale, so I did not worry that much, but I'm running a
swapflusher regularly.
Make sure you have a recent kernel, because all old kernels up to
2.4.12 or so were extremely unresponsive during swapoff. With current
kernels, this is much, much faster and nothing to worry about.
Let me show you the script I use for the job. No rocket science, but
it's easy to do it wrong. Be careful to maintain equality of priority
among disks:
use strict;
$|=1;
print Running swapon -a, just in case...\n;
system swapon -a;
print Running swapon -s\n;
open S, swapon -s |;
my(%prio);
PARTITION: while (S) {
print;
next if /^Filename/;
chop;
my($f,$t,$s,$used,$p) = split;
my $disk = $f;
$disk =~ s/\d+$//;
$prio{$disk} ||= 5;
$prio{$disk}--;
if ($used == 0) {
print Unused, skipping\n;
next PARTITION;
}
print Turning off\n;
system swapoff $f;
print Turning on with priority $prio{$disk}\n;
system swapon -p $prio{$disk} $f;
}
system swapon -s;
Let me know if you see room for improvements,
Regards,
--
andreas
Re: [OT] New mod_perl logo (revisited)
On Thu, 21 Feb 2002 23:35:18 -, Jonathan M. Hollin [EMAIL PROTECTED] said: I am still soliciting entries for the new logo (send to mod_perl[at]digital-word.com)... so please keep those images coming. What about entering the old logo as a competitor as well? I think I'd vote for it. Or is there any reason why there must be a new logo? -- andreas
Re: [OT] New mod_perl logo (revisited)
On Fri, 22 Feb 2002 14:51:23 +0800, Stas Bekman [EMAIL PROTECTED] said: Andreas, all the logos from the first contest are in the competition. blush Sorry I missed it. Thanks for bearing with me. -- andreas
Re: Speed of downloading problem.
On Mon, 4 Feb 2002 08:37:52 -0600 , Purcell, Scott [EMAIL PROTECTED] said: The test is taking a 50mb file and placing it in the doc root of the IIS and Apache/htdocs. Then just having a href link pointing to it. We have ruled out the firewall and any networking. I know nothing about NT, but I'd play with the SendBufferSize config variable. -- andreas
Re: Exceptions section dropped?
On Mon, 14 Aug 2000 10:04:33 +0200 (CEST), Stas Bekman [EMAIL PROTECTED] said: cpan install mod_perl_guide Running make for S/ST/STAS/Apache-mod_perl_guide-1.22.tar.gz Got another SIGINT cpan install Apache::mod_perl_guide Running make for S/ST/STAS/Apache-mod_perl_guide-1.23.tar.gz ...while the latest version is 1.25. Something is wrong. I won't delete the previous versions of the Guide now, so whoever handles CPAN now (I think it's Jarkko Hietaniemi) will be able to verify and debug this apparently broken behavior. If you want to use CPAN.pm as a distribution medium for the guide, you need to be careful about versioning. You need to tell people which module (or pseudo module) they should install in order to get the guide and you should then make sure that this module always carries the latest version number. You need to know that PAUSE is parsing the *.pm files in order ot guess the $VERSION. So when I look at 1.25, I find only one file that contains the $VERSION=1.25 and that is src/Version.pm. And that file does not have a package declaration, so PAUSE has no chance to guess which package is referred to. Note that PAUSE is parsing, not interpreting the code, so perl tricks do not work. You need to write pretty straightforward code. So, I hear you asking, "what should I do"? I believe that you should include the $VERSION=1.25 in your mod_perl_guide.pm where there is already a package declaration. If it doesn't work, let me know shortly after the upload, and I'll find a better suggestion. -- andreas
Re: UPDATE on Devel::Symdump fails test
On Fri, 09 Jun 2000 11:23:49 +, Rob Tanner [EMAIL PROTECTED] said: I am therefore concluding with CAUTION that the test in Devel::Symdump is out of date. I updated it in my copy and rebuilt package and installed it. Time will now tell whether my conclusion was right. Your conclusion is right. I discovered the problem a day before my vacation, and was unable to make a new release that day. I'm doing that now. In general one can say, the test was not a good test and 5.6.0 did not break Devel::Symdump in any way. You can install it without fear, next version will only get rid of this test. -- andreas
Re: http headers for cache-friendly modperl site
On Mon, 11 Oct 1999 13:18:12 +0400 (MSD), Oleg Bartunov [EMAIL PROTECTED] said:
1. Do you have some examples on-line to illustrate
cache-friendly dynamical pages ?
On www.stadtplandienst.de the headers for the graphics have optimal
headers, I think. The headers for HTML could be improved though.
On the other machines where I have prepared everything to be
cache-friendly, I yet have to decide about a good expiration schedule.
And as often, without a pressing need, I haven't yet come around to
finetune it.
2. I'm building server with fully dynamic content using
Apache, modperl and HTML::Mason and would like to implement
cache-friendly strategy you described. But I have some problem:
In Russia we have several encodings for russian language
( koi8-r - mostly Unix, win-1251 - mostly windows and several
others). Documents generated in native server's encoding and
translated to another encoding on-fly depending on several
parameters (user directly specify port number for example or
server understand on some logic (by User Agent string for example) what
encoding would be the best for user). If user directly selected
port number URL would changed, say http://some.host:8100/ for koi8-r
and http://some.host:8101/ for win-1251. In such situation there
are no problem with caching on proxy servers because URL's are different.
But in case when server automagically recognize encoding of client
URL stays the same for differnet encodings - just http://some.host/
and this cause a trouble with proxy. Suppose if user1 from windows machine
and user2 from Unix request the same document using the same proxy.
This is exactly the same problem for any content negotiation. If you
are using content negotiation, you *must* specify the Vary header as
described in my document. But as soon as you have a Vary header, you
are out of luck with regard to caching proxies because squid is unable
to cache documents with a Vary header (it just expires them
immediately) and I believe there is no other Proxy available that does
handle Vary headers intelligenty. So although you are acting
cache-friendly and correct, the current available cache technology
isn't up to the task.
But as a workaround you can and should work with a redirect.
1. Decide about a parameter in the querystring or in the pathinfo or
in the path that codifies everything you would normally handle by
interpreting an incoming header, like Accept, Accept-Encoding,
Accept-Charset, User-Agent, etc.
2. As one of the first things your program should check for the
precense of this parameter in the requested URI.
3. If it is there, you have a unique URI and can answer in a
cache-friendly way. If it isn't there, you code it into the
received URI and answer with a redirect to the URI you just
constructed.
An example: www.meta-list.net, where we roughly do the following,
where $mgr is an Apache::HeavyCGI object we created earlier and $cgi
is an Apache::Request object.
my $acc = $cgi-param('acc');
if (defined($acc)) {
my $lang;
($mgr-{CAN_UTF8},$mgr-{CAN_GZIP},$mgr-{CAN_PNG},$mgr-{Lang}) =
unpack "a a a a*", $acc;
} else {
my $utf8 = $mgr-can_utf8;
my $gzip = $mgr-can_gzip;
my $png = $mgr-can_png;
my $lang = $r-header_in("Accept-Language");
my $param = $utf8 . $gzip . $png . $mgr-uri_escape($lang);
my $redir_to;
if ($r-method_number == M_GET) {
my $args = $r-args;
$redir_to = $mgr-myurl . "?acc=$param";
$redir_to .= "$args" if $args;
} elsif ($r-method_number == M_POST) {
warn "We got a POST but we are only prepared for GET!";
return;
}
$r-header_out("Location",$redir_to);
require Apache::Constants;
my $stat = Apache::Constants::REDIRECT();
$r-status($stat);
$r-send_http_header;
}
This code doesn't work exactly as posted because I simplified a few
things to illustrate the point, but I hope it helps clarify things.
--
andreas
