warning alert in perl test suite with latest patches

p5pRT commented 23 years ago

Migrated from rt.perl.org#3571 (status was 'resolved')

Searchable as RT3571$

p5pRT commented 23 years ago

From lvirden@cas.org

Created by lvirden@cas.org

This is a bug report for perl from lvirden@cas.org\, generated with the help of perlbug 1.29 running under perl v5.6.0.

----------------------------------------------------------------- During compilation and testing of the latest set of patches\, an assertion blotch was encountered - it however didn't cause a failure in the test suite!

op/tr................assertion botched (chunk's tail overwrite?): *((char *)((caddr_t)ovp + nbytes - sizeof (unsigned int) + i)) == 0x55

For those keeping score\, even with the latest set of patches\, the bug in comp/require.t remains...

Perl Info

``` Flags: category=core severity=low Site configuration information for perl v5.6.0: Configured by lwv26 at Mon Jul 3 07:54:50 EDT 2000. Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=solaris, osvers=2.6, archname=sun4-solaris uname='sunos lwv26awu 5.6 generic_105181-20 sun4u sparc sunw,ultra-5_10 ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='cc', optimize='-g', gccversion= cppflags='-DDEBUGGING -I/projects/gnu/sparc-sun-solaris2.6/include -I/vol/lwv26ldatae/include -I/vol/SUNWspro/SC5.0/include -I/usr/ccs/include' ccflags ='-DDEBUGGING -I/projects/gnu/sparc-sun-solaris2.6/include -I/vol/lwv26ldatae/include -I/vol/SUNWspro/SC5.0/include -I/usr/ccs/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 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, usemymalloc=y, prototype=define Linker and Libraries: ld='cc', ldflags ='-R/projects/gnu/sparc-sun-solaris2.6/lib:/vol/lwv26ldatae/lib:/vol/SUNWspro/SC5.0/lib:/usr/ccs/lib -L/projects/gnu/sparc-sun-solaris2.6/lib -L/vol/lwv26ldatae/lib -L/vol/SUNWspro/SC5.0/lib -L/usr/ccs/lib ' libpth=/projects/gnu/sparc-sun-solaris2.6/lib /vol/lwv26ldatae/lib /vol/SUNWspro/SC5.0/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt -lsec libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-KPIC', lddlflags='-G -R/projects/gnu/sparc-sun-solaris2.6/lib:/vol/lwv26ldatae/lib:/vol/SUNWspro/SC5.0/lib:/usr/ccs/lib -L/projects/gnu/sparc-sun-solaris2.6/lib -L/vol/lwv26ldatae/lib -L/vol/SUNWspro/SC5.0/lib -L/usr/ccs/lib' Locally applied patches: @INC for perl v5.6.0: /home/lwv26/lib/perl5/ /projects/sprs_lwv/lib/perl5/ /vol/lwv26ldatae//lib/perl5/5.6.0/sun4-solaris /vol/lwv26ldatae//lib/perl5/5.6.0 /vol/lwv26ldatae//lib/perl5/site_perl/5.6.0/sun4-solaris /vol/lwv26ldatae//lib/perl5/site_perl/5.6.0 /vol/lwv26ldatae//lib/perl5/site_perl . Environment for perl v5.6.0: HOME=/home/lwv26 LANG=C LANGUAGE (unset) LD_LIBRARY_PATH=/lprod/cas/lib:/usr/dt/lib:/usr/openwin/lib:/usr/lib LOGDIR (unset) PATH=/usr/dt/bin:/vol/SUNWspro/bin:/ldatae/bin:/projects/sprs_lwv/sol26/bin:/projects/sprs_lwv/sol26/bin/mime:/projects/sprs_lwv/sol2/bin:/projects/sprs_lwv/bin:/projects/sprs_lwv/bin/mime:/home/lwv26/bin/D.news:/usr/perl5/bin:/projects/gnu/sparc-sun-solaris2.6/bin:/usr/tcl83/bin:/usr/tcl82/sun4/bin:/usr/tcl82/bin:/projects/xopsrc/sun4/bin:/projects/xopsrc/bin:/usr/atria/bin:/projects/intranet/bin:/projects/clearcase/bin:/vol/tclsrcsol/TclPro1.3/solaris-sparc/bin:/ldata2/teTeX/bin/sparc-sun-solaris2.6:/vol/adobe/Acrobat3/bin:/ldata/bin:/home/lwv26/bin/D.aws:/home/lwv26/bin/sol2:/home/lwv26/bin/D.frontend:/home/lwv26/bin/D.ksh:/cas/test/bin/sun4:/projects/sprs_lwv/bin/sol2:/usr/java1.2/bin:/home/lwv26/bin/sun4:/lprod/cas/bin:/usr/local/bin:/usr/dt/bin:/usr/openwin/bin:/bin:/cas/bin/sun4:/cas/abin/sun4:/cas/X11/sun4/bin:/usr/ccs/bin:/lprod/bin:/usr/sbin:/usr/ucb:/cas/tools/bin/sun4:/cas/X11/sun4/tools/bin:/home/lwv26/bin:/cas/tools/pdbin/sun4:/home/lwv26/bin/D.mistypes:/ho! me/lwv26/bin/D.toys:/home/lwv26/bin/D.tools:/projects/npd/npdweb/bin-sol2:/vol/tclsrcsol/TclPro/solaris-sparc/bin:/usr/openwin/bin PERL5LIB=/home/lwv26/lib/perl5/:/projects/sprs_lwv/lib/perl5/: PERLDOC=-t PERLLIB=/home/lwv26/lib/perl:/projects/sprs_lwv/lib/perl: PERL_BADLANG (unset) SHELL=/bin/ksh ```

p5pRT commented 23 years ago

From @jhi

On Mon\, Jul 24\, 2000 at 09:09:42AM -0400\, Larry W. Virden wrote:

This is a bug report for perl from lvirden@cas.org\, generated with the help of perlbug 1.29 running under perl v5.6.0.

----------------------------------------------------------------- During compilation and testing of the latest set of patches\, an assertion blotch was encountered - it however didn't cause a failure in the test suite!

op/tr................assertion botched (chunk's tail overwrite?): *((char *)((caddr_t)ovp + nbytes - sizeof (unsigned int) + i)) == 0x55

Hmmm. For me in Digital UNIX this bug doesn't happen. (And I think it should cause a failure in the test suite.)

For those keeping score\, even with the latest set of patches\, the bug in comp/require.t remains...

Thanks\, yes\, I know that it's still broken. When I find the time...

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

From: Jarkko Hietaniemi \jhi@iki\.fi

During compilation and testing of the latest set of patches\, an assertion blotch was encountered - it however didn't cause a failure in the test suite!

op/tr................assertion botched (chunk's tail overwrite?): *((char *)((caddr_t)ovp + nbytes - sizeof (unsigned int) + i)) == 0x55

Hmmm. For me in Digital UNIX this bug doesn't happen. (And I think it should cause a failure in the test suite.)

Is there anything I can run to provide you more info on this error?

p5pRT commented 23 years ago

From @jhi

op/tr................assertion botched (chunk's tail overwrite?): *((char *)((caddr_t)ovp + nbytes - sizeof (unsigned int) + i)) == 0x55

Hmmm. For me in Digital UNIX this bug doesn't happen. (And I think it should cause a failure in the test suite.)

Is there anything I can run to provide you more info on this error?

Fix the bug? :-)

Well...Using binary search try finding the patch that caused this bug? Try compiling with -DDEBUGGING? Try compiling without Perl's malloc? (though this will probably make the problem just go into hiding) Try using Purify or other similar tool?

FWIW I tested perl-current@6430 on Solaris 7 + 2.8.1 and the op/tr test does not emit that warning.

p5pRT commented 23 years ago

From @tux

On Mon\, 24 Jul 2000 16:28:57 +0200\, Jarkko Hietaniemi \jhi@iki\.fi wrote:

On Mon\, Jul 24\, 2000 at 09:09:42AM -0400\, Larry W. Virden wrote:

This is a bug report for perl from lvirden@cas.org\, generated with the help of perlbug 1.29 running under perl v5.6.0.

----------------------------------------------------------------- During compilation and testing of the latest set of patches\, an assertion blotch was encountered - it however didn't cause a failure in the test suite!

op/tr................assertion botched (chunk's tail overwrite?): *((char *)((caddr_t)ovp + nbytes - sizeof (unsigned int) + i)) == 0x55

Hmmm. For me in Digital UNIX this bug doesn't happen. (And I think it should cause a failure in the test suite.)

For those keeping score\, even with the latest set of patches\, the bug in comp/require.t remains...

Thanks\, yes\, I know that it's still broken. When I find the time...

Just upgraded to bleedperl@6438 from perl-5.6.0 base on HP-UX 11.00 using cc and got it too :-( where the base version did not.

--8\<--- : op/tr................assertion botched (chunk's tail overwrite?): *((char *)((caddr_t)ovp + nbytes - sizeof (unsigned int) + i)) == 0x55 ok : -->8---

Surprisingly this has nothing to do with the tr operator\, but with utf8 usage. If I reduce tests 9 .. 15 to i.e. --8\<--- { use utf8; for (9..15) { print "ok $_\n" } # 9 - changing UTF8 characters in a UTF8 string\, same length. $l = chr(300); $r = chr(400); $x = 200.300.400; # \<==== This is the bummer! #$x =~ tr/\x{12c}/\x{190}/; #printf "not (%vd) "\, $x if $x ne 200.400.400 or length $x != 3; #print "ok 9\n"; print STDERR __LINE__\, "\n"; } -->8---

The above message is issued. Leaving out the asignement to $x will remove the message. I think Simon will have to solve this.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

Hi\,

I tracked this warning to patch 6363 file doop.c.

I'm totally new to perl internals so there are a couple of things that I don't understand: (this is for perl@6437):

#define HALF_UPGRADE(start\,end) \ STMT_START { \ U8* NeWsTr; \ STRLEN LeN = (end) - (start); \ NeWsTr = bytes_to_utf8(start\, &LeN); \ Copy(NeWsTr\,start\,LeN\,U8*); \ end = (start) + LeN; \ } STMT_END

Why Copy has a type of U8*? Shouldn't it be U8? And bytes_to_utf8 allocates a new string\, so shouldn't that be freed?

Hope this helps\,

Daniel

H.Merijn Brand wrote:

--8\<--- : op/tr................assertion botched (chunk's tail overwrite?): *((char *)((caddr_t)ovp + nbytes - sizeof (unsigned int) + i)) == 0x55 ok : -->8---

Surprisingly this has nothing to do with the tr operator\, but with utf8 usage. If I reduce tests 9 .. 15 to i.e. --8\<--- { use utf8; for (9..15) { print "ok $_\n" } # 9 - changing UTF8 characters in a UTF8 string\, same length. $l = chr(300); $r = chr(400); $x = 200.300.400; # \<==== This is the bummer! #$x =~ tr/\x{12c}/\x{190}/; #printf "not (%vd) "\, $x if $x ne 200.400.400 or length $x != 3; #print "ok 9\n"; print STDERR __LINE__\, "\n"; } -->8---

The above message is issued. Leaving out the asignement to $x will remove the message. I think Simon will have to solve this.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

I'm still getting the following warning in op/tr.t using bleedperl@6529 under Solaris:

assertion botched (chunk's tail overwrite?): *((char *)((caddr_t)ovp + nbytes - sizeof (unsigned int) + i)) == 0x55

I'm not able to get this warning under linux.

The following example triggers the warning:

# /tmp/x.t $ENV{PERL_DESTRUCT_LEVEL} = 2; ($x = 256.65.258) =~ tr/a/b/; { use utf8; $x = 60.400.125.60.400; $y = $x =~ tr/\x{3c}/\x{3c}/; }

Using a debugger:

(dbx) run /tmp/x.t Running: perl /tmp/x.t (process id 22074) assertion botched (chunk's tail overwrite?): *((char *)((caddr_t)ovp + nbytes - sizeof (unsigned int) + i)) == 0x55 signal ABRT (Abort) in _libc_kill at 0xef58828c 0xef58828c: _libc_kill+0x0008: bgeu _libc_kill+0x30 Current function is botch 971 PerlProc_abort(); (dbx) where
[1] _libc_kill(0x0\, 0x6\, 0xef5a3180\, 0x0\, 0xffffffff\, 0x0)\, at 0xef58828c [2] abort(0xef5a3180\, 0x74\, 0xef5aaa64\, 0x1c1964\, 0xef7ec884\, 0x4)\, at 0xef53a 600 =>[3] botch(diag = 0x1c194c "chunk's tail overwrite"\, s = 0x1c1964 "*((char *)(( caddr_t)ovp + nbytes - sizeof (unsigned int) + i)) == 0x55")\, line 971 in "mallo c.c" [4] free(mp = 0x1e3588)\, line 1565 in "malloc.c" [5] Perl_sv_clear(sv = 0x1d1fec)\, line 3850 in "sv.c" [6] Perl_sv_free(sv = 0x1d1fec)\, line 3974 in "sv.c" [7] Perl_gp_free(gv = 0x1d1fe0)\, line 1103 in "gv.c" [8] Perl_sv_clear(sv = 0x1d1fe0)\, line 3827 in "sv.c" [9] Perl_sv_free(sv = 0x1d1fe0)\, line 3974 in "sv.c" [10] do_clean_all(sv = 0x1d1fe0)\, line 8350 in "sv.c" [11] S_visit(f = 0x108d38 = &`perl`sv.c`do_clean_all(struct sv *sv))\, line 161 in "sv.c" [12] Perl_sv_clean_all()\, line 188 in "sv.c" [13] perl_destruct(my_perl = 0x1c8408)\, line 651 in "perl.c" [14] main(argc = 2\, argv = 0xeffffaf4\, env = 0xeffffb00)\, line 55 in "perlmain .c" (dbx) x 0x1d1fec 0x001d1fec: 0x001c9098 (dbx) call Perl_sv_dump(0x1d1fec) SV = PV(0x1c9098) at 0x1d1fec REFCNT = 0 FLAGS = (POK\,pPOK\,UTF8) PV = 0x1e3588 "\<\306\220}\<\306\220"\0 CUR = 7 LEN = 15 stopped in _libc_kill at 0xef58828c 0xef58828c: _libc_kill+0x0008: bgeu _libc_kill+0x30

This is ./myconfig (I get the same results whether I'm using Sun C Compiler or gcc version 2.95.2 19991024 (release)2.95):

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=solaris\, osvers=2.6\, archname=sun4-solaris uname='sunos tyr 5.6 generic_105181-20 sun4u sparc sunw\,ultra-250 ' config_args='-de -D optimize=-g' hint=recommended\, useposix=true\, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='cc'\, optimize='-g'\, gccversion=\, gccosandvers= cppflags='-DDEBUGGING -I/usr/local/include' ccflags ='-DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' stdchar='unsigned char'\, d_stdstdio=define\, usevfork=false intsize=4\, longsize=4\, ptrsize=4\, doublesize=8 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\, usemymalloc=y\, prototype=define Linker and Libraries: ld='cc'\, ldflags =' -L/usr/local/lib -L/opt/SUNWspro/WS6/lib ' libpth=/usr/local/lib /opt/SUNWspro/WS6/lib /lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldb -ldl -lm -lc -lcrypt -lsec libc=/lib/libc.so\, so=so\, useshrplib=false\, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags=' ' cccdlflags='-KPIC'\, lddlflags='-G -L/usr/local/lib -L/opt/SUNWspro/WS6/lib'

p5pRT commented 23 years ago

From @jhi

On Mon\, Aug 07\, 2000 at 05:29:00PM -0300\, Daniel Muino wrote:

I'm still getting the following warning in op/tr.t using bleedperl@6529 under Solaris:

assertion botched (chunk's tail overwrite?): *((char *)((caddr_t)ovp + nbytes - sizeof (unsigned int) + i)) == 0x55

Please try rsyncing again\, Simon submitted a new patch.

p5pRT commented 23 years ago

From @tux

On Wed\, 26 Jul 2000 17:59:27 +0200\, H.Merijn Brand \h\.m\.brand@hccnet\.nl wrote:

On Mon\, 24 Jul 2000 16:28:57 +0200\, Jarkko Hietaniemi \jhi@iki\.fi wrote: : Just upgraded to bleedperl@6438 from perl-5.6.0 base on HP-UX 11.00 using cc and got it too :-( where the base version did not.

--8\<--- : op/tr................assertion botched (chunk's tail overwrite?): *((char *)((caddr_t)ovp + nbytes - sizeof (unsigned int) + i)) == 0x55 ok : -->8---

Just upgraded to bleadperl@6544 from bleedperl@6534 and the tr warning on HP-UX 11.00 has gone :-)

--8\<--- HP-UX 11.00:CPAN/perl-5.6.0/t 105 > TEST op/tr.t op/pat.t op/regexp* op/tr.............ok op/pat............FAILED at test 69 op/regexp.........FAILED at test 98 op/regexp_noamp...FAILED at test 98 : -->8---

Oops got three new ones.

Is this because of Jeffrey's findings?

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

H.Merijn Brand (lists.p5p):

op/tr.............ok

Yey!

op/pat............FAILED at test 69 op/regexp.........FAILED at test 98 op/regexp_noamp...FAILED at test 98

Oh. :( Wasn't me\, I didn't touch anything.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

Jarkko Hietaniemi \jhi@iki\.fi wrote:

On Mon\, Aug 07\, 2000 at 05:29:00PM -0300\, Daniel Muino wrote:

I'm still getting the following warning in op/tr.t using bleedperl@6529 under Solaris:

assertion botched (chunk's tail overwrite?): *((char *)((caddr_t)ovp + nbytes - sizeof (unsigned int) + i)) == 0x55

Please try rsyncing again\, Simon submitted a new patch.

Using bleedperl@6544:

op/tr................ok

After applying Hugo's patch to op/pat.t and op/re_test:

op/pat...............ok op/regexp............ok op/regexp_noamp......ok

Should this bug be closed?

Daniel

-- $jhi++; # http://www.iki.fi/jhi/

p5pRT commented 23 years ago

From @tux

On Tue\, 8 Aug 2000 13:58:21 -0300\, Daniel Muino \dmuino@afip\.gov\.ar wrote:

Jarkko Hietaniemi \jhi@iki\.fi wrote:

On Mon\, Aug 07\, 2000 at 05:29:00PM -0300\, Daniel Muino wrote:

I'm still getting the following warning in op/tr.t using bleedperl@6529 under Solaris:

assertion botched (chunk's tail overwrite?): *((char *)((caddr_t)ovp + nbytes - sizeof (unsigned int) + i)) == 0x55

Please try rsyncing again\, Simon submitted a new patch.

Using bleedperl@6544:

op/tr................ok

After applying Hugo's patch to op/pat.t and op/re_test:

op/pat...............ok op/regexp............ok op/regexp_noamp......ok

Should this bug be closed?

The tr one? Yes.

The three re ones where introduced in the set 6535 .. 6544 I just rebuilt from 6450\, re-applying al subsequent patches. The bottom three are still in :-(

I'm off for a two week holiday this friday\, so large scale bug-tracking time cannot be found :-(

Any idear if there's free local ISP numbers in France\, so I can still follow P6 development?

p5pRT commented 23 years ago

From @jhi

I'm off for a two week holiday this friday\, so large scale bug-tracking time cannot be found :-(

Any idear if there's free local ISP numbers in France\, so I can still follow P6 development?

Hey\, I've got a much better idea. *I* go to France for two weeks of vacation\, and you can still have you your email access. Deal?

p5pRT commented 23 years ago

From @jhi

The three re ones where introduced in the set 6535 .. 6544 I just rebuilt from 6450\, re-applying al subsequent patches. The bottom three are still in :-(

Hugo's patch (6546) should help.

p5pRT commented 23 years ago

From @tux

On Tue\, 8 Aug 2000 13:45:21 -0500\, Jarkko Hietaniemi \jhi@iki\.fi wrote:

The three re ones where introduced in the set 6535 .. 6544 I just rebuilt from 6450\, re-applying al subsequent patches. The bottom three are still in :-(

Hugo's patch (6546) should help. Wasn't available yet when I answered yesterday-evening.

Applied. *ALL* tests OK in bleedperl@6558 :-) Installed ...

Close tickets for all 4: op/tr................ok op/pat...............ok op/regexp............ok op/regexp_noamp......ok

p5pRT commented 23 years ago

From @tux

On Tue\, 8 Aug 2000 13:42:53 -0500\, Jarkko Hietaniemi \jhi@iki\.fi wrote:

I'm off for a two week holiday this friday\, so large scale bug-tracking time cannot be found :-(

Any idear if there's free local ISP numbers in France\, so I can still follow P6 development?

Hey\, I've got a much better idea. *I* go to France for two weeks of vacation\, and you can still have you your email access. Deal?

To be honoust\, I'd realy would have no trouble in trading places\, so I could stay in touch with both p5p and p6\, which is very motivating for me\, but I'm sure my wife and both my kids will object quite fiercely.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

No\, it's because of his patches\, or something related. I sent a few patches yesterday\, and for whatever reason the end result had several files in an odd state. When I resync'd today\, I did a diff between what was there and what I expected\, and sent them into Jarkko\, so things should be okay again soon.

Funnily enough\, the op/readdir test also failed because it assumed that there would be less than 100 tests in the op/ directory\, and a new one I added pushed it over the limit. That's also re-included in the patches I just sent.

I was working on those patches for a long time\, and sent them at 4:30 in the morning\, so it's likely I just screwed up. My appologies to all. Jeffrey

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

Hi\,

just having a look at what happens to this subject line which should look something like:

Re: [ID 20000724.002] warning alert in perl test suite with latest p (from here on has been added to see what happens to the subject line thereafter\, do you suppose that's long enough? :-)

Ciao Richard Foley

richard@perl.org | richard@rfi.net | Richard.Foley@m.dasa.de 'Ciao' - shorter than 'Aufwiedersehen'

p5pRT commented 23 years ago

From @ysth

In article \39938D85\.6F207DC3@m\.dasa\.de\, Richard Foley \Richard\.Foley@m\.dasa\.de wrote:

Hi\,

just having a look at what happens to this subject line which should look something like:

Re: [ID 20000724.002] warning alert in perl test suite with latest p (from here on has been added to see what happens to the subject line thereafter\, do you suppose that's long enough? :-)

Ciao Richard Foley --- richard@perl.org | richard@rfi.net | Richard.Foley@m.dasa.de 'Ciao' - shorter than 'Aufwiedersehen'

The original post from perlbug wasn't truncated. perlbug split the line after 'latest'. Somebody else truncated it (but put the 'p' back on the first line??) either manually or by way of a faulty email client.

BTW\, I'd just as soon perlbug didn't split the subject lines. I don't really see the purpose in disturbing how the original mail to perlbug has it arranged.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

Yitzchak Scott-Thoennes wrote:

In article \39938D85\.6F207DC3@m\.dasa\.de\, Richard Foley \Richard\.Foley@m\.dasa\.de wrote:

Hi\,

just having a look at what happens to this subject line which should look something like:

Re: [ID 20000724.002] warning alert in perl test suite with latest p (from here on has been added to see what happens to the subject line thereafter\, do you suppose that's long enough? :-)

Ciao Richard Foley --- richard@perl.org | richard@rfi.net | Richard.Foley@m.dasa.de 'Ciao' - shorter than 'Aufwiedersehen'

The original post from perlbug wasn't truncated. perlbug split the line after 'latest'. Somebody else truncated it (but put the 'p' back on the first line??) either manually or by way of a faulty email client.

BTW\, I'd just as soon perlbug didn't split the subject lines. I don't really see the purpose in disturbing how the original mail to perlbug has it arranged. Perlbug is not splitting the subject lines. If there is any splitting of mail header lines\, this (I suspect) is happening via the email RFC which has lines longer than 72 chars (I think) split for 7-bit issues. Perhaps via a mail client?

Ciao Richard Foley

richard@perl.org | richard@rfi.net | Richard.Foley@m.dasa.de 'Ciao' - shorter than 'Aufwiedersehen'

p5pRT commented 23 years ago

From @ysth

In article \3993A140\.86F36227@m\.dasa\.de\, Richard Foley \Richard\.Foley@m\.dasa\.de wrote:

Yitzchak Scott-Thoennes wrote:

BTW\, I'd just as soon perlbug didn't split the subject lines. I don't really see the purpose in disturbing how the original mail to perlbug has it arranged. Perlbug is not splitting the subject lines. If there is any splitting of mail header lines\, this (I suspect) is happening via the email RFC which has lines longer than 72 chars (I think) split for 7-bit issues. Perhaps via a mail client?

When I mail directly to p5p\, Subject headers are preserved. When I mail perlbug\, what gets stored in the db and sent to p5p has the Subject split.

Perl / perl5