[perl #17197] SIGSEGV in perl 5.8.0 multithread build with -DLEAKTEST
per...@perl.org
# Please include the string: [perl #17197]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17197 >
This is a bug report for perl from DL-pds...@ubsw.com,
generated with the help of perlbug 1.34 running under perl v5.8.0.
Hi,
I am getting a SIGSEGV, Segmentation fault, from miniperl during the
build of perl 5.8.0 when I have these build options:
sh Configure \
-Dprefix='/tmp/perl/5.8.0-mt-debug' \
-Dprivlib='/tmp/perl/5.8.0-mt-debug/lib' \
-Darchlib='/tmp/perl/5.8.0-mt-debug/lib' \
-Dsitelib='/tmp/perl/5.8.0-mt-debug/lib' \
-Dsitearch='/tmp/perl/5.8.0-mt-debug/lib' \
-Dlocincpth='/sbcimp/run/pd/gdbm/1.8.0/include' \
-Dloclibpth='/sbcimp/run/pd/gdbm/1.8.0/lib' \
-Dcc=gcc \
-Dusethreads \
-Uinstallusrbinperl \
-Dperladmin='dl-pds...@ubsw.com' \
-Dcf_email='dl-pds...@ubsw.com' \
-Dccflags='-DLEAKTEST' \
-Doptimize='-g' \
-des
The build is successful if
1> -Dccflags='-DLEAKTEST' is removed
or
2> -Dusethreads is removed
i.e. it's the combination of multi thread + DLEAKTEST which is giving grief.
I'm building on Solaris 2.6:
SunOS 5.6 Generic_105181-30 sun4u sparc SUNW,Ultra-Enterprise
I'm building with gcc 3.1:
gcc -v
Reading specs from /sbcimp/run/pd/gcc/3.1/lib/gcc-lib/sparc-sun-solaris2.6/3.1/specs
Configured with: /sbcimp/build/pd/gcc/gcc-3.1/configure --prefix=/sbcimp/run/pd/gcc/3.1 --enable-languages=c++ --enable-threads=solaris
Thread model: solaris
gcc version 3.1
The build error comes here:
cp op.c opmini.c
`sh cflags "optimize='-g'" opmini.o` -DPERL_EXTERNAL_GLOB opmini.c
CCCMD = gcc -DPERL_CORE -c -D_REENTRANT -DLEAKTEST -DDEBUGGING -fno-strict-aliasing -I/sbcimp/run/pd/gdbm/1.8.0/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -Wall
rm -f opmini.c
gcc -L/sbcimp/run/pd/gdbm/1.8.0/lib -o miniperl \
miniperlmain.o opmini.o libperl.a -lsocket -lnsl -ldl -lm -lposix4 -lpthread -lc
./miniperl -w -Ilib -MExporter -e '<?>' || make minitest
Segmentation Fault - core dumped
Running the miniperl thru gdb shows:
ln4d419cmp> gdb ./miniperl
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.6"...
(gdb) run
Starting program: /tmp/perl-5.8.0-mt-debug/miniperl
[New LWP 1]
[New LWP 2]
[New LWP 3]
Program received signal SIGSEGV, Segmentation fault.
0x000abaa0 in Perl_safexmalloc (x=31337, size=344) at util.c:221
221 xycount[x][SIZE_TO_Y(size)]++;
(gdb) bt
#0 0x000abaa0 in Perl_safexmalloc (x=31337, size=344) at util.c:221
#1 0x000c0b30 in Perl_reentrant_init (my_perl=0x210180) at reentr.c:143
#2 0x00046200 in perl_construct (my_perl=0x211ceb) at perl.c:275
#3 0x00025c0c in main (argc=1, argv=0xeffffcb4, env=0xeffffcbc)
at miniperlmain.c:79
I'm not sure if this is a bug. Maybe -D_REENTRANT -DLEAKTEST aren't meant
to work together ? Anyway, I'm reporting it in case there's an easy fix.
Regards
Judith
dl-pds...@ubsw.com
---
Flags:
category=install
severity=low
---
Site configuration information for perl v5.8.0:
Configured by judithp at Thu Sep 12 12:52:10 BST 2002.
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=solaris, osvers=2.6, archname=sun4-solaris-thread-multi
uname='sunos ln4d419cmp 5.6 generic_105181-30 sun4u sparc sunw,ultra-enterprise '
config_args='-Dprefix=/tmp/perl/5.8.0-mt-debug -Dprivlib=/tmp/perl/5.8.0-mt-debug/lib -Darchlib=/tmp/perl/5.8.0-mt-debug/lib -Dsitelib=/tmp/perl/5.8.0-mt-debug/lib -Dsitearch=/tmp/perl/5.8.0-mt-debug/lib -Dlocincpth=/sbcimp/run/pd/gdbm/1.8.0/include -Dloclibpth=/sbcimp/run/pd/gdbm/1.8.0/lib -Dcc=gcc -Dusethreads -Uinstallusrbinperl -Dperladmin=dl-pds...@ubsw.com -Dcf_email=dl-pds...@ubsw.com -Doptimize=-g -des'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -DDEBUGGING -fno-strict-aliasing -I/sbcimp/run/pd/gdbm/1.8.0/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-g',
cppflags='-D_REENTRANT -DDEBUGGING -fno-strict-aliasing -I/sbcimp/run/pd/gdbm/1.8.0/include'
ccversion='', gccversion='3.1', gccosandvers='solaris2.6'
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/sbcimp/run/pd/gdbm/1.8.0/lib '
libpth=/sbcimp/run/pd/gdbm/1.8.0/lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -lgdbm -ldl -lm -lposix4 -lpthread -lc
perllibs=-lsocket -lnsl -ldl -lm -lposix4 -lpthread -lc
libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-fPIC', lddlflags='-G -L/sbcimp/run/pd/gdbm/1.8.0/lib'
Locally applied patches:
---
@INC for perl v5.8.0:
/tmp/perl/5.8.0-mt-debug/lib
/tmp/perl/5.8.0-mt-debug/lib
/tmp/perl/5.8.0-mt-debug/lib
/tmp/perl/5.8.0-mt-debug/lib
.
---
Environment for perl v5.8.0:
HOME=/sbclocal/sca
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH=/sbcimp/run/pd/gdbm/1.8.0/lib
LOGDIR (unset)
PATH=/tmp/perl/5.8.0-mt-debug/bin:/sbcimp/run/pd/gcc/3.1/bin:/sbin:/usr/sbin:/bin:/usr/ccs/bin:/usr/openwin/bin:/usr/dt/bin:/sbcimp/run/pd/gnutar/1.12/bin:/sbcimp/run/pd/gzip/1.2.4/bin
PERL_BADLANG (unset)
SHELL=/usr/bin/ksh
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
Andy Dougherty
> I am getting a SIGSEGV, Segmentation fault, from miniperl during the
> build of perl 5.8.0 when I have these build options:
> i.e. it's the combination of multi thread + DLEAKTEST which is giving grief.
> I'm not sure if this is a bug. Maybe -D_REENTRANT -DLEAKTEST aren't meant
> to work together ? Anyway, I'm reporting it in case there's an easy fix.
Last I checked, LEAKTEST didn't really work in any case, and has not
really been suppoted since before version 5.000. (Occasionally someone
fixes things up to make it work, but usually it gets broken again shortly
thereafter.) Instead, we recommend various third-party leak testers, such
as Purify or third degree.
--
Andy Dougherty doug...@lafayette.edu
H.Merijn Brand
Remove it (with a rusty chainsaw)? Unsupport it from Configure? Undocument it?
If we don't use it ourselves, and we have no value for it, and valuable - free
- third party tools (valgrind) are available, why still keep it in?
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smo...@perl.org
http://archives.develooper.com/daily...@perl.org/ per...@perl.org
send smoke reports to: smokers...@perl.org, QA: http://qa.perl.org
Andy Dougherty
> On Fri 13 Sep 2002 01:51, Andy Dougherty <doug...@lafayette.edu> wrote:
> > Last I checked, LEAKTEST didn't really work in any case, and has not
> > really been suppoted since before version 5.000. (Occasionally someone
> > fixes things up to make it work, but usually it gets broken again shortly
> > thereafter.) Instead, we recommend various third-party leak testers, such
> > as Purify or third degree.
>
> Remove it (with a rusty chainsaw)? Unsupport it from Configure? Undocument it?
It is not "supported" in Configure -- it's not even mentioned. It's not
"supported" in INSTALL -- it's not even mentioned. Odd, though, that
someone added it to perlrun, even though the below comment in handy.h is
unchanged from 6 years ago:
XXX LEAKTEST doesn't really work in perl5. There are direct calls to
safemalloc() in the source, so LEAKTEST won't pick them up.
(The main "offenders" are extensions.)
Further, if you try LEAKTEST, you'll also end up calling
Safefree, which might call safexfree() on some things that weren't
malloced with safexmalloc. The correct "fix" to this, if anyone
is interested, is to ensure that all calls go through the New and
Renew macros.
--Andy Dougherty August 1996
It just never seemed worth the effort to go in and rip it out. It
could potentially be made useful, I suppose, but for now I think
LEAKTEST should be removed from perlrun.pod.
Andy Dougherty doug...@lafayette.edu
Colin Watson
> XXX LEAKTEST doesn't really work in perl5. There are direct calls to
> safemalloc() in the source, so LEAKTEST won't pick them up.
> (The main "offenders" are extensions.)
> Further, if you try LEAKTEST, you'll also end up calling
> Safefree, which might call safexfree() on some things that weren't
> malloced with safexmalloc. The correct "fix" to this, if anyone
> is interested, is to ensure that all calls go through the New and
> Renew macros.
> --Andy Dougherty August 1996
>
> It just never seemed worth the effort to go in and rip it out. It
> could potentially be made useful, I suppose, but for now I think
> LEAKTEST should be removed from perlrun.pod.
It's also implied by the discussion of the -DL switch in
perldebguts.pod; I got misled by that last week into trying to make
-DLEAKTEST work, before realizing it was too much of a blind alley.
--
Colin Watson [cjwa...@flatline.org.uk]
Andy Dougherty
> On Fri, Sep 13, 2002 at 08:51:17AM -0400, Andy Dougherty wrote:
> > XXX LEAKTEST doesn't really work in perl5. There are direct calls to
> > safemalloc() in the source, so LEAKTEST won't pick them up.
> > (The main "offenders" are extensions.)
> > It just never seemed worth the effort to go in and rip it out. It
> > could potentially be made useful, I suppose, but for now I think
> > LEAKTEST should be removed from perlrun.pod.
>
> It's also implied by the discussion of the -DL switch in
> perldebguts.pod; I got misled by that last week into trying to make
> -DLEAKTEST work, before realizing it was too much of a blind alley.
Well, it clearly did work for someone (Ilya?) at least in some situations
for a while. (It may all also have been very dependent upon whether or
not perl's malloc or the system malloc was being used, and whether or not
EMBED_MY_MALLOC was or was not in force.) I suspect it's even more
confused with threads. (At one point, the threads extension actually
called plain raw 'malloc()' directly, bypassing both the New() interface
and the safemalloc() interface. I haven't checked lately to see what's
up.)
This sort of thing has always been the state with LEAKTEST. It almost
works, so it seems a shame to rip it out, but it doesn't quite work.
--
Andy Dougherty doug...@lafayette.edu
Dept. of Physics
Lafayette College, Easton PA 18042
Nick Ing-Simmons
># New Ticket Created by DL-pds...@ubsw.com
># Please include the string: [perl #17197]
># in the subject line of all future correspondence about this issue.
># <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17197 >
>
>
>
>This is a bug report for perl from DL-pds...@ubsw.com,
>generated with the help of perlbug 1.34 running under perl v5.8.0.
>
>Hi,
>
>I am getting a SIGSEGV, Segmentation fault, from miniperl during the
>build of perl 5.8.0 when I have these build options:
>
>
>
> 1> -Dccflags='-DLEAKTEST' is removed
>or
> 2> -Dusethreads is removed
>i.e. it's the combination of multi thread + DLEAKTEST which is giving grief.
>
>
>
>0x000abaa0 in Perl_safexmalloc (x=31337, size=344) at util.c:221
>221 xycount[x][SIZE_TO_Y(size)]++;
>(gdb) bt
>#0 0x000abaa0 in Perl_safexmalloc (x=31337, size=344) at util.c:221
>#1 0x000c0b30 in Perl_reentrant_init (my_perl=0x210180) at reentr.c:143
>#2 0x00046200 in perl_construct (my_perl=0x211ceb) at perl.c:275
>#3 0x00025c0c in main (argc=1, argv=0xeffffcb4, env=0xeffffcbc)
> at miniperlmain.c:79
>
>
>I'm not sure if this is a bug. Maybe -D_REENTRANT -DLEAKTEST aren't meant
> to work together ? Anyway, I'm reporting it in case there's an easy fix.
I don't think anyone has been maintaining the -DLEAKTEST stuff for
a year or three. These days we tend to diagnose leaks with valgrind/purify
rather than LEAKTEST's clever #fdefine hackery:
handy.h: XXX LEAKTEST doesn't really work in perl5. There are direct calls to
handy.h: safemalloc() in the source, so LEAKTEST won't pick them up.
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
Nick Ing-Simmons
>
>Remove it (with a rusty chainsaw)? Unsupport it from Configure? Undocument it?
>
>If we don't use it ourselves, and we have no value for it, and valuable - free
>- third party tools (valgrind) are available, why still keep it in?
I vote for removing it. One less #define forest to fight through.
Nick Ing-Simmons
>I suspect it's even more
>confused with threads. (At one point, the threads extension actually
>called plain raw 'malloc()' directly, bypassing both the New() interface
>and the safemalloc() interface. I haven't checked lately to see what's
>up.)
The direct use of malloc() was to bypass Win32's per-thread-pool scheme
to try and allocate data global to all threads. I _think_ that should
have been backed out now in favour of threads::shared and "proper"
sv_dup() "cloning".
>
>This sort of thing has always been the state with LEAKTEST. It almost
>works, so it seems a shame to rip it out, but it doesn't quite work.
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
Slaven Rezic
> H.Merijn Brand <h.m....@hccnet.nl> writes:
> >
> >Remove it (with a rusty chainsaw)? Unsupport it from Configure? Undocument it?
> >
> >If we don't use it ourselves, and we have no value for it, and valuable - free
> >- third party tools (valgrind) are available, why still keep it in?
>
> I vote for removing it. One less #define forest to fight through.
>
What about the systems without purify (I assume it's commercial) and
valgrind (only for Linux/i386)?
Regards,
Slaven
--
Slaven Rezic - slaven...@berlin.de
babybike - routeplanner for cyclists in Berlin
handheld (e.g. Compaq iPAQ with Linux) version of bbbike
http://bbbike.sourceforge.net
Nick Ing-Simmons
>Nick Ing-Simmons <ni...@ing-simmons.net> writes:
>
>> H.Merijn Brand <h.m....@hccnet.nl> writes:
>> >
>> >Remove it (with a rusty chainsaw)? Unsupport it from Configure? Undocument it?
>> >
>> >If we don't use it ourselves, and we have no value for it, and valuable - free
>> >- third party tools (valgrind) are available, why still keep it in?
>>
>> I vote for removing it. One less #define forest to fight through.
>>
>
>What about the systems without purify (I assume it's commercial) and
>valgrind (only for Linux/i386)?
Well broadly speaking memory leaks are platform independant, so
we can find them on one that does. Personally I think a debugging malloc
(tweaked version of perl's malloc ?) would be at least as good as
LEAKTEST.
However if you want to side with Andy and leave it in that is okay too.
Nicholas Clark
[removing -DLEAKTEST]
> What about the systems without purify (I assume it's commercial) and
> valgrind (only for Linux/i386)?
If you use google you can detect some message to a list about a FreeBSD guy
working on a port sometime back in February, but sadly nothing further seems
to have happened.
I see no reason why valgrind could not be extended to any other CPU
architecture if someone were brave enough to implement the code to translate
its instructions to and from valgrind's internal representation.
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
H.Merijn Brand
> Nick Ing-Simmons <ni...@ing-simmons.net> writes:
>
> > H.Merijn Brand <h.m....@hccnet.nl> writes:
> > >
> > >Remove it (with a rusty chainsaw)? Unsupport it from Configure? Undocument it?
> > >
> > >If we don't use it ourselves, and we have no value for it, and valuable - free
> > >- third party tools (valgrind) are available, why still keep it in?
> >
> > I vote for removing it. One less #define forest to fight through.
> >
>
> What about the systems without purify (I assume it's commercial) and
> valgrind (only for Linux/i386)?
The chances that LEAKTEST will be changed to *work* on those systems is
problably about the same to the chance that valgrind is ported to such system
A *very* cheap solution might be to just link with the debugging version of
GNU malloc, but IIRC, that ain't maintained anymore either.
Bottom line is that the code in there now is useless, and there's no signals
that it is to be made useful in the (near) future.
Andy Dougherty
> However if you want to side with Andy and leave it in that is okay too.
Me? I'm not taking any sides :-), just reporting history.
--
Andy Dougherty doug...@lafayette.edu
Rafael Garcia-Suarez
>
> a. I don't know if I caught the 'L' flag for -DDEBUGGING enough
There's a few DEBUG_L* symbols in perl.h that you can wipe out.
Update also DEBUG_MASK in this same file.
The code that understands the letters after -D is in perl.c,
around line 2363 :
static char debopts[] = "psltocPmfrxuLHXDSTRJvC";
H.Merijn Brand
OK, grrr, krack
--- perl.h 2002-09-09 13:06:50.000000000 +0200
+++ perl.h 2002-09-16 16:59:08.000000000 +0200
@@ -2452,7 +2452,6 @@ Gid_t getegid (void);
#define DEBUG_r_FLAG 0x00000200 /* 512 */
#define DEBUG_x_FLAG 0x00000400 /* 1024 */
#define DEBUG_u_FLAG 0x00000800 /* 2048 */
-#define DEBUG_L_FLAG 0x00001000 /* 4096 */
#define DEBUG_H_FLAG 0x00002000 /* 8192 */
#define DEBUG_X_FLAG 0x00004000 /* 16384 */
#define DEBUG_D_FLAG 0x00008000 /* 32768 */
@@ -2462,7 +2461,7 @@ Gid_t getegid (void);
#define DEBUG_J_FLAG 0x00080000 /* 524288 */
#define DEBUG_v_FLAG 0x00100000 /*1048576 */
#define DEBUG_C_FLAG 0x00200000 /*2097152 */
-#define DEBUG_MASK 0x003FFFFF /* mask of all the standard flags */
+#define DEBUG_MASK 0x003FEFFF /* mask of all the standard flags */
#define DEBUG_DB_RECURSE_FLAG 0x40000000
#define DEBUG_TOP_FLAG 0x80000000 /* XXX what's this for ??? Signal
@@ -2480,7 +2479,6 @@ Gid_t getegid (void);
# define DEBUG_r_TEST_ (PL_debug & DEBUG_r_FLAG)
# define DEBUG_x_TEST_ (PL_debug & DEBUG_x_FLAG)
# define DEBUG_u_TEST_ (PL_debug & DEBUG_u_FLAG)
-# define DEBUG_L_TEST_ (PL_debug & DEBUG_L_FLAG)
# define DEBUG_H_TEST_ (PL_debug & DEBUG_H_FLAG)
# define DEBUG_X_TEST_ (PL_debug & DEBUG_X_FLAG)
# define DEBUG_D_TEST_ (PL_debug & DEBUG_D_FLAG)
@@ -2508,7 +2506,6 @@ Gid_t getegid (void);
# define DEBUG_r_TEST DEBUG_r_TEST_
# define DEBUG_x_TEST DEBUG_x_TEST_
# define DEBUG_u_TEST DEBUG_u_TEST_
-# define DEBUG_L_TEST DEBUG_L_TEST_
# define DEBUG_H_TEST DEBUG_H_TEST_
# define DEBUG_X_TEST DEBUG_X_TEST_
# define DEBUG_D_TEST DEBUG_D_TEST_
@@ -2545,7 +2542,6 @@ Gid_t getegid (void);
# define DEBUG_r(a) DEBUG__(DEBUG_r_TEST, a)
# define DEBUG_x(a) DEBUG__(DEBUG_x_TEST, a)
# define DEBUG_u(a) DEBUG__(DEBUG_u_TEST, a)
-# define DEBUG_L(a) DEBUG__(DEBUG_L_TEST, a)
# define DEBUG_H(a) DEBUG__(DEBUG_H_TEST, a)
# define DEBUG_X(a) DEBUG__(DEBUG_X_TEST, a)
# define DEBUG_D(a) DEBUG__(DEBUG_D_TEST, a)
@@ -2575,7 +2571,6 @@ Gid_t getegid (void);
# define DEBUG_r_TEST (0)
# define DEBUG_x_TEST (0)
# define DEBUG_u_TEST (0)
-# define DEBUG_L_TEST (0)
# define DEBUG_H_TEST (0)
# define DEBUG_X_TEST (0)
# define DEBUG_D_TEST (0)
@@ -2600,7 +2595,6 @@ Gid_t getegid (void);
# define DEBUG_r(a)
# define DEBUG_x(a)
# define DEBUG_u(a)
-# define DEBUG_L(a)
# define DEBUG_H(a)
# define DEBUG_X(a)
# define DEBUG_D(a)
--- perl-current/perl.c 2002-09-04 16:07:19.000000000 +0200
+++ perl-current/perl.c 2002-09-16 16:57:59.000000000 +0200
@@ -2360,7 +2360,7 @@ Perl_moreswitches(pTHX_ char *s)
forbid_setid("-D");
if (isALPHA(s[1])) {
/* if adding extra options, remember to update DEBUG_MASK */
- static char debopts[] = "psltocPmfrxuLHXDSTRJvC";
+ static char debopts[] = "psltocPmfrxuHXDSTRJvC";
char *d;
for (s++; *s && (d = strchr(debopts,*s)); s++)
Rafael Garcia-Suarez
>
> OK, grrr, krack
> --- perl-current/perl.c 2002-09-04 16:07:19.000000000 +0200
> +++ perl-current/perl.c 2002-09-16 16:57:59.000000000 +0200
> @@ -2360,7 +2360,7 @@ Perl_moreswitches(pTHX_ char *s)
> forbid_setid("-D");
> if (isALPHA(s[1])) {
> /* if adding extra options, remember to update DEBUG_MASK */
> - static char debopts[] = "psltocPmfrxuLHXDSTRJvC";
> + static char debopts[] = "psltocPmfrxuHXDSTRJvC";
You're fast, perhaps too fast. This should be
static char debopts[] = "psltocPmfrxu HXDSTRJvC";
Rafael Garcia-Suarez
Your patches (with my correction) build fine and passes all tests here.
And, by the way, there should be tests that -D<number> and -D<appropriate
combination of letters> do the right thing. I'm just thinking aloud.
H.Merijn Brand
> Rafael Garcia-Suarez <raphel.gar...@hexaflux.com> wrote:
> > "H.Merijn Brand" <h.m....@hccnet.nl> wrote:
> > >
> > > OK, grrr, krack
> > > --- perl-current/perl.c 2002-09-04 16:07:19.000000000 +0200
> > > +++ perl-current/perl.c 2002-09-16 16:57:59.000000000 +0200
> > > @@ -2360,7 +2360,7 @@ Perl_moreswitches(pTHX_ char *s)
> > > forbid_setid("-D");
> > > if (isALPHA(s[1])) {
> > > /* if adding extra options, remember to update DEBUG_MASK */
> > > - static char debopts[] = "psltocPmfrxuLHXDSTRJvC";
> > > + static char debopts[] = "psltocPmfrxuHXDSTRJvC";
> >
> > You're fast, perhaps too fast. This should be
> > static char debopts[] = "psltocPmfrxu HXDSTRJvC";
>
> Your patches (with my correction) build fine and passes all tests here.
Feel free to apply. I won't so short before I leave for YAPC :)
> And, by the way, there should be tests that -D<number> and -D<appropriate
> combination of letters> do the right thing. I'm just thinking aloud.
--
Rafael Garcia-Suarez
> Feel free to apply. I won't so short before I leave for YAPC :)
Have a good time, all. I'll stay in Lyon -- my day-job configuration
makes impossible for me to take some vacation now. :(
Nicholas Clark
> On Mon 16 Sep 2002 16:48, Rafael Garcia-Suarez <raphel.gar...@hexaflux.com> wrote:
> > "H.Merijn Brand" <h.m....@hccnet.nl> wrote:
> > >
> > > a. I don't know if I caught the 'L' flag for -DDEBUGGING enough
> >
> > There's a few DEBUG_L* symbols in perl.h that you can wipe out.
> > Update also DEBUG_MASK in this same file.
> >
> > The code that understands the letters after -D is in perl.c,
> > around line 2363 :
> >
> > static char debopts[] = "psltocPmfrxuLHXDSTRJvC";
>
> OK, grrr, krack
> --- perl-current/perl.c 2002-09-04 16:07:19.000000000 +0200
> +++ perl-current/perl.c 2002-09-16 16:57:59.000000000 +0200
> @@ -2360,7 +2360,7 @@ Perl_moreswitches(pTHX_ char *s)
> forbid_setid("-D");
> if (isALPHA(s[1])) {
> /* if adding extra options, remember to update DEBUG_MASK */
> - static char debopts[] = "psltocPmfrxuLHXDSTRJvC";
> + static char debopts[] = "psltocPmfrxuHXDSTRJvC";
> char *d;
>
> for (s++; *s && (d = strchr(debopts,*s)); s++)
Are you going to add a warning on -L that says that leaktest is gone?
Or just let the warning that they'll get:
Unrecognized switch: -L (-h will show valid options).
be enough of a hint to RTFM. I suspect that no-one not on p5p attempts to use
leaktest, so it's probably not worth a warning.