http://ASPN.ActiveState.com/ASPN/Mail/Browse/Threaded/perl5-porters For the maintenance, development, and porting of the programming language Perl. en-us Copyright 2005, ActiveState aspn-feedback@activestate.com aspn-feedback@activestate.com ASPN Mail Archive hourly 1 1901-01-01T00:00+00:00 http://ASPN.ActiveState.com/ASPN/img/logo_78x25.gif http://ASPN.ActiveState.com/ASPN/Mail/Browse/Threaded/perl5-porters G. Raphics (graphics @ ActiveState) http://ASPN.ActiveState.com/ASPN/Mail/Message/perl5-porters/3173812 <PRE>On Wed, 21 Jun 2006, Steve Hay wrote: > Alex Keim (via RT) wrote: > > Calls to system() fail if you have a large environment set on Windows. > > Thanks for the bug report. > > I can reproduce the problem on Win32 using the development version of > perl when perl is built with threads enabled (which it is by default). > > If you build perl without threads enabled then system() is implemented > differently and your test script runs fine. So there's a workaround > for you if don't need a threaded perl. There is a limitation in Windows itself: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/setenvironmen tvariable.asp It is actually somewhat confusing, as cmd.exe may have different limitation than the OS itself, depending on the actual version and service pack of Windows. I've seen limits of both 32K and 64K for the total size of the environment, and limits of 8K and 32K for the size of individual variables. Either way, this is a limitation. If you need to pass so much data to a subprocess, then you should write it to a file and pass the filename on the commandline or by an environment variable. Cheers, -Jan </PRE> Jan Dubois (jand@...) perl5-porters http://ASPN.ActiveState.com/ASPN/Mail/Message/perl5-porters/3173799 <PRE>Apologies for taking so very long to get back to you. On 2006â??04â??05, at 08:56, Itsuro Oda (via RT) wrote: > I have isolated a problem part of perl. The list 1 is a simple > reproduce script. > It is observed that a five bytes malloc is never freed per loop. > > --- list 1 (a memory leak script)--- > #!/usr/bin/perl > while (1) { > eval { > local $SIG{'ALRM'} = sub { die "Timeout Alarm" }; > alarm 1; > sleep 3; # will catch signal > alarm 0; > }; > } > ------------------------------------ You are using perl5.8.4, which I do not have built just now. But I ran your script for a couple of hours on Mac OS 10.4.6 with perl 5.8.3, 5.8.6, and development perl (5.9.x) and could see no leak using ps -l. However, I think that this is because the leak is slow and ps is not sensitive enough -- I came up with a variant of your test case leaks really fast on all those perls: $ perl -we 'eval{local $SIG{"USR1"} = sub{die "Aaargh..."}; kill ("USR1", $$)} while 1' > The list 2 is OK, memory leak not occur. > > --- list 2 (OK) --- > #!/usr/bin/perl > while (1) { > eval { > local $SIG{'ALRM'} = sub { die "Timeout Alarm" }; > alarm 3; > sleep 1; # will not catch signal > alarm 0; > }; > } This variant of my variant does not leak: $ ./perl -we 'eval {local $SIG{"USR1"} = sub{"Aaargh..."}; kill ("USR1", $$)} while 1' So it looks as if the issue has to do with calling die() in the signal handler. > ------------------------------------ > > The following is a log of my printf debug of perl. I hope it is > your help. Sorry. What's a "printf debug"? Do you mean you added printf()s to the perl source code? > > ---- list 1 --- > ... > ... > PerlMem_malloc size = 129 ptr_out = 80621f8 > PerlMem_free ptr_in = 80622b8 (**) > PerlMem_malloc size = 5 ptr_out = 80622b8 > PerlMem_malloc size = 1 ptr_out = 8063498 > PerlMem_free ptr_in = 80621f8 > op_ppaddr = 4009a650 sassign > PerlMem_free ptr_in = 8063498 > PerlMem_malloc size = 129 ptr_out = 80621f8 > PerlMem_free ptr_in = 80622b8 > PerlMem_malloc size = 5 ptr_out = 80622b8 (*) never freed > PerlMem_free ptr_in = 80621f8 > ... > PerlMem_malloc size = 1 ptr_out = 8063498 > PerlMem_realloc size = 14 ptr_out = 8063498 ptr_in = 8063498 > PerlMem_realloc size = 18 ptr_out = 8063498 ptr_in = 8063498 > PerlMem_realloc size = 35 ptr_out = 8063498 ptr_in = 8063498 > PerlMem_realloc size = 40 ptr_out = 8063498 ptr_in = 8063498 > PerlMem_realloc size = 42 ptr_out = 8063498 ptr_in = 8063498 > PerlMem_realloc size = 43 ptr_out = 8063498 ptr_in = 8063498 > PerlMem_free ptr_in = 8063498 > PerlMem_malloc size = 129 ptr_out = 80621f8 > PerlMem_malloc size = 5 ptr_out = 80634c8 (**) freed in next loop > PerlMem_free ptr_in = 80621f8 > op_ppaddr = 4009a800 unstack > op_ppaddr = 4009a320 nextstate > op_ppaddr = 400d40c0 entertry > ... OK. Here's what my test gives when run with "for 1..2" instead of "while 1" under -Dm with a debugging bleadperl (that is, development version of perl). Apologies in advance for the length: ... EXECUTING... 0x1301f90: (00551) free 0x1305d10: (00552) calloc 1 x 40 bytes 0x1301f80: (00553) malloc 21 bytes 0x1306080: (00554) malloc 24 bytes 0x1305d40: (00555) malloc 24 bytes 0x1300e80: (00556) malloc 20 bytes 0x1306090: (00557) free 0x1300e90: (00558) free 0x1300e80: (00559) malloc 24 bytes 0x1305d50: (00560) free 0x1305d40: (00561) malloc 24 bytes 0x1300e90: (00562) free 0x1307a00: (00563) malloc 48 bytes 0x1305d70: (00564) malloc 144 bytes 0x2815600: (00565) malloc 1916 bytes 0x1300e80: (00566) malloc 20 bytes 0x1300e80: (00567) rfree 0x1300e80: (00568) realloc 28 bytes 0x1300e80: (00569) rfree 0x1300e80: (00570) realloc 32 bytes 0x1300e80: (00571) rfree 0x1306040: (00572) realloc 36 bytes 0x1306040: (00573) rfree perl(17536) malloc: *** error for object 0x1300e80: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug 0x1306040: (00574) realloc 40 bytes 0x1306040: (00575) rfree perl(17536) malloc: *** error for object 0x1300e80: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug 0x1306040: (00576) realloc 44 bytes 0x1306050: (00577) free perl(17536) malloc: *** error for object 0x1300e80: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug 0x1300e80: (00578) malloc 24 bytes 0x1300e80: (00579) malloc 24 bytes perl(17536) malloc: *** error for object 0x1307a20: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug 0x1305d70: (00580) malloc 20 bytes 0x1300e90: (00581) free perl(17536) malloc: *** error for object 0x1307a20: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug 0x1307a00: (00582) malloc 20 bytes 0x1307a00: (00583) rfree perl(17536) malloc: *** error for object 0x1307a20: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug perl(17536) malloc: *** error for object 0x1307a20: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug 0x1306040: (00584) realloc 44 bytes 0x1306040: (00585) rfree perl(17536) malloc: *** error for object 0x1307a20: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug perl(17536) malloc: *** error for object 0x1307a00: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug perl(17536) malloc: *** error for object 0x1307a20: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug 0x1306040: (00586) realloc 48 bytes 0x1306040: (00587) rfree perl(17536) malloc: *** error for object 0x1307a20: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug perl(17536) malloc: *** error for object 0x1307a20: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug 0x1301d20: (00588) realloc 52 bytes 0x1301d20: (00589) rfree perl(17536) malloc: *** error for object 0x1307a20: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug perl(17536) malloc: *** error for object 0x1307a00: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug perl(17536) malloc: *** error for object 0x1307a20: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug perl(17536) malloc: *** error for object 0x1307a00: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug 0x1301d20: (00590) realloc 56 bytes 0x1301d20: (00591) rfree perl(17536) malloc: *** error for object 0x1307a20: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug perl(17536) malloc: *** error for object 0x1307a00: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug perl(17536) malloc: *** error for object 0x1307a20: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug perl(17536) malloc: *** error for object 0x1307a00: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug 0x1301d20: (00592) realloc 60 bytes panic: free from wrong pool at -e line 1. 0x1301d30: (00593) free perl(17536) malloc: *** error for object 0x1307a20: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug perl(17536) malloc: *** error for object 0x1307a00: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug perl(17536) malloc: *** set a breakpoint in szone_error to debug 0x0: (00594) free 0y{0L) free 0x0: (00596) free 0x1305e10: (00597) free 0x0: (00598) free 0x1307730: (00599) free 0x1307590: (00600) free 0x13077b0: (00601) free 0x13075b0: (00602) free 0x1301fe0: (00603) free 0x0: (00604) free 0x1301c40: (00606) free 0x1301a60: (00613) free 0x13019f0: (00614) free 0x1301a10: (00615) free 0x13019d0: (00616) free 0x2811210: (00617) free 0x1301d30: (00618) free 0x1301fb0: (00619) free Segmentation fault (I particularly dislike that last line, not least because the crash dump says "Unable to generate backtrace for 64 bit task" when the perl I'm using is a 32-bit binary.) Anyway, something nasty is happening, and I'll try to find time to look at it tomorrow. In the mean time, if anybody on the list wants to jump in, do so by all means! -- Dominic Dunlop </PRE> Dominic Dunlop (shouldbedomo@...) perl5-porters http://ASPN.ActiveState.com/ASPN/Mail/Message/perl5-porters/3173757 <PRE>On Sun, Jun 18, 2006 at 09:06:20PM -0700, Ask Bjoern Hansen wrote: > [1] I suspect Pixar and Dreamworks uses Perl to drive test suites or > build processes. I've no idea what BofA uses Perl for. Making lots of money? :-) Nicholas Clark </PRE> Nicholas Clark (nick@...) perl5-porters http://ASPN.ActiveState.com/ASPN/Mail/Message/perl5-porters/3173717 <PRE>On 6/22/06, David Landgren <david@... wrote: > Could Perl get Reversible Debugging? > [...] > We need a "come from" instruction > http://xrl.us/nnuw I don't recall reading a demand for a "come from" instruction in that thread, but I had an idea last night that I was going to dismiss as trivial, until reading that assertion in the week in p5p summary. It's a real simply come from instruction that forks at the labels instead of branching. Not suitable at all as a replacement for goto -- if you want to branch, use goto. But may be useful for setting checkpoints/breakpoints with a minimum of surgical insult. package ComeFrom; use Exporter; @... = qw/CFL ComeFromLabel CFlabel/, # all the same thing qw/ComeFrom CF/; # also all the same thing our %SubsByLabel; sub ComeFrom($\&){ my ($label, $sub) = @... push @... $sub; }; sub ComeFromLabel($;){ my $label = shift; foreach my $sub (@... unless(fork()){ #fixme: check for -1; install sane SIG_CHLD handler, etc goto &$sub; # keeping what's left of @... after shifting off the label exit; # we're not trying to make fork bombs here } } }; # establish more than one way to do it: *CFL = *CFlabel = \&ComeFromLabel; *CF = \&ComeFrom; =head1 USAGE Register subroutines with the ComeFrom system with the ComeFrom::ComeFrom instruction like so: ComeFrom Jellybean => sub { print "At ",~~localtime(), "the bean count was ", CountBeans(),"\n" }; Later this label can be jumped to -- this subroutine dispatched, or called, but in its own process (that's the crucial difference between this mechanism and a simple subroutine call -- subtle semantics) by inserting a 'JellyBean' CFlabel into some code that may be affecting the bean count: ... CFL 'Jellybean'; ... =head2 Differences Between ComeFromLabel and normal subroutine call * ComeFrom execution happens in own process * Multiple ComeFrom subroutines can be associated with a given label * CFL markers can be trivially edited to #CFL no-ops after debugging =head2 Why Bother? This functionality is a trivial subroutine redispatcher. In the event that it is easier for you to write your own than install mine, please don't let me stop you. =cut __END__ So.. shall I put this on CPAN? -- David L Nicol "if life were like Opera, this would probably have poison in it" -- Lyric Opera promotional coffee cup sleeve from Latte Land </PRE> David Nicol (davidnicol@...) perl5-porters http://ASPN.ActiveState.com/ASPN/Mail/Message/perl5-porters/3173674 <PRE>On 6/22/06, John Peacock <jpeacock@... wrote: > I /am/ splitting hairs, since I said it was "strictly" true. But you are > still ignoring my point that the actual example of using $^V for > comparison purposes _in_ _the_ _POD_ uses v-strings, which continues to > work with version objects. Believe me, if I had know where the I saw that the docs did say C<$^V ge v5.8.0> (or some other version) but they did also promise a particular kind of stringification. I didn't think I needed to mention that the docs show a comparision using a real v-string. I figured that given the documentation's promise of a particular kind of stringification that I could just state that and that would be the end of it. I don't think we have a perly notion that you can make a string that can't be compared to other strings. Josh </PRE> Joshua ben Jore (twists@...) perl5-porters http://ASPN.ActiveState.com/ASPN/Mail/Message/perl5-porters/3173673 <PRE>Joshua ben Jore wrote: > I think the documentation used chr(5).chr(6).chr(0) as an example, not > a statement that the behavior was true only in 5.6.0. It certainly > reads that way. I wouldn't have thought that the docs were defining > $^V for the 5.6.0 perl and that the format was undefined for all other > versions. I think this is really splitting hairs if you mean that when > it says the string is chr(5).chr(6).chr(0) it really means that the > only valid way to make that value is v5.6.0. I /am/ splitting hairs, since I said it was "strictly" true. But you are still ignoring my point that the actual example of using $^V for comparison purposes _in_ _the_ _POD_ uses v-strings, which continues to work with version objects. Believe me, if I had know where the v-string/version object stuff would have gone, and the totally off the wall way people have used v-strings in the past, I wouldn't have done *any* of this work. I've seen things that ordinary humans just weren't meant to see! ;-) I think the documentation needs to be altered to eliminate any discussion of the underlying representation and merely discuss the correct usage of $^V. John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748 </PRE> John Peacock (jpeacock@...) perl5-porters http://ASPN.ActiveState.com/ASPN/Mail/Message/perl5-porters/3173663 <PRE>Joshua ben Jore wrote: > The documentation in perlvar says that $^V stringifies to a string > like C<chr(5) . chr(6) . chr(0)> which is nonprintable. perlvar has > said this since 5.6.0 and it still does. I didn't realize it but the > current stringification of $^V in bleadperl is contrary to what's been > documented. Per the docs, $^V eq "\005\011\004" is the correct > response and the "v5.9.4" is the wrong response. You're right, I should have updated the documentation when I added the $^V object patch. I made sure that the more common case (of trying to print out $^V) still worked, even though $^V is now an object: $ LD_LIBRARY_PATH=. ./perl -e 'printf("%vd",$^V)' 5.9.4 But, to actually quote the documentation: >$^V The revision, version, and subversion of the Perl interpreter, > represented as a string composed of characters with those ordi- > nals. Thus in Perl v5.6.0 it equals "chr(5) . chr(6) . chr(0)" > and will return true for "$^V eq v5.6.0". Note that the char- > acters in this string value can potentially be in Unicode > range. > > This can be used to determine whether the Perl interpreter exe- > cuting a script is in the right range of versions. (Mnemonic: > use ^V for Version Control.) Example: > > warn "No \"our\" declarations!\n" if $^V and $^V lt v5.6.0; Which is all strictly true: in Perl v5.6.0, $^V is the same as "chr(5) . chr(6) . chr(0)"; it just isn't true in 5.9.x. It is only because you used the form "\5\x08\0" that anything broke. Had you used the examples cited (using v-strings), you would never have noticed anything wrong... John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748 </PRE> John Peacock (jpeacock@...) perl5-porters http://ASPN.ActiveState.com/ASPN/Mail/Message/perl5-porters/3173641 <PRE>On 6/22/06, John Peacock <jpeacock@... wrote: > Which is all strictly true: in Perl v5.6.0, $^V is the same as "chr(5) . > chr(6) . chr(0)"; it just isn't true in 5.9.x. It is only because you > used the form "\5\x08\0" that anything broke. Had you used the examples > cited (using v-strings), you would never have noticed anything wrong... I think the documentation used chr(5).chr(6).chr(0) as an example, not a statement that the behavior was true only in 5.6.0. It certainly reads that way. I wouldn't have thought that the docs were defining $^V for the 5.6.0 perl and that the format was undefined for all other versions. I think this is really splitting hairs if you mean that when it says the string is chr(5).chr(6).chr(0) it really means that the only valid way to make that value is v5.6.0. I'm pretty sure that it's wrong for $^V to stringify the way you've got it going now. Pleasant as the stringification is. Josh </PRE> Joshua ben Jore (twists@...) perl5-porters http://ASPN.ActiveState.com/ASPN/Mail/Message/perl5-porters/3173640 <PRE>On 6/22/06, Rafael Garcia-Suarez <rgarciasuarez@... wrote: > On the other hand, $^V is not a plain scalar, it's an object, and it > doesn't stringify to a string of non printable chars. The documentation in perlvar says that $^V stringifies to a string like C<chr(5) . chr(6) . chr(0)> which is nonprintable. perlvar has said this since 5.6.0 and it still does. I didn't realize it but the current stringification of $^V in bleadperl is contrary to what's been documented. Per the docs, $^V eq "\005\011\004" is the correct response and the "v5.9.4" is the wrong response. Maybe we want a $^Version variable if we want something to stringify to "v5.9.4". Josh </PRE> Joshua ben Jore (twists@...) perl5-porters http://ASPN.ActiveState.com/ASPN/Mail/Message/perl5-porters/3173580 <PRE>On Thu, 22 Jun 2006, H.Merijn Brand wrote: > Abe found a situation that might lead to inconsistencies > > consider > > # ./Configure -A prepend:lddlflags=-shared ..... > > which he wants for gcov. at the moment the prepend things are *used* (not > when they are parsed), lddlflags is still undef, so it is set to "-shared" > > That would be OK if lddlflags isn't altered later on, but in this case the > complete handling of lddlflags is borked, because it is done later, and the > default now doesn't apply anymore [ . . . ] > What we wanted is that -A prepend was executed *AFTER* setting lddlflags in > this section Yes, both 'append' and 'prepend' suffer from this problem. My initial inclination would be to have the script that parses the -A options create two new variables -- lddlflags_prepend and lddlflags_append -- and then the lddlflags section in Configure (from dlsrc.U) would go about setting the defaults, and then do dflt="$lddlflags_prepend $dflt $lddlflags_append" before calling ./myread. As you correctly observe, however, it's not just lddlflags. All the variable assignments sprinkled throughout Configure suffer from this problem. I don't see an elegant solution to that. > It is possible to solve it for lddlflags, but can anyone think of a more > generic solution? Of course, it's also possible that there may be a different elegant solution to the original problem, if it's still a problem. (It's possible to work around nearly anything with appropriate config.over scripts, for example). Alas, I've never used 'gcov' and have no idea why it needs the '-shared' flag but isn't getting it anyway. If someone would like to walk me through the problem, I may be able to suggest another approach. -- Andy Dougherty doughera@... </PRE> Andy Dougherty (doughera@...) perl5-porters