Skip Menu |

This queue is for tickets about the MIME-tools CPAN distribution.

Report information
The Basics
Id: 88872
Status: rejected
Priority: 0/
Queue: MIME-tools

People
Owner: dfs+pause [...] roaringpenguin.com
Requestors: 'spro^^*%*^6ut# [...] &$%*c
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Sometimes multipart Content-Type is ignored when parsing
Here is my little ‘one’-liner to reproduce the bug: $ cat sample\ input.txt | perl -lMMIME::Parser -e 'my $p = new MIME::Parser; $p->output_under("/tmp"); $e=$p->parse(\*STDIN); print $p->filer->output_dir; $e->dump_skeleton' /tmp/msg-1379787083-1641-0 Content-type: text/plain Effective-type: text/plain Body-file: /tmp/msg-1379787083-1641-0/msg-1641-1.txt So it has only created one file. But see the attachment, which I am feeding to it (the output of lwp-request -m GET -e 'nntp://nntp.perl.org/000001ceab1a$29aebd20$7d0c3760$@cp.net'). It is a multipart document. Thank you for your attention.
Subject: sample input.txt
Date: Fri, 6 Sep 2013 17:00:07 +0100 From: meta.support@cp.net ("John Unsworth - CP Meta Support") Server: you can post Content-Language: en-gb Content-Type: multipart/mixed;boundary="----=_NextPart_000_0001_01CEAB22.8B73C160" Approved: news@nntp.perl.org Client-Date: Sat, 21 Sep 2013 18:08:09 GMT Delivered-To: mailing list perl5-porters@perl.org Delivered-To: moderator for perl5-porters@perl.org Delivered-To: perl5-porters@perl.org Delivered-To: perlmail-perlbug-followup@onion.perl.org Delivered-To: perlbug-followup@perl.org In-Reply-To: <rt-3.6.HEAD-1873-1378423344-99.119617-94-0@perl.org> Mailing-List: contact perl5-porters-help@perl.org; run by ezmlm Message-ID: <000001ceab1a$29aebd20$7d0c3760$@cp.net> MIME-Version: 1.0 Newsgroups: perl.perl5.porters Path: nntp.perl.org Received: (qmail 3942 invoked from network); 6 Sep 2013 16:00:18 -0000 Received: from x1.develooper.com (207.171.7.70)by x6.develooper.com with SMTP; 6 Sep 2013 16:00:18 -0000 Received: (qmail 24824 invoked by uid 225); 6 Sep 2013 16:00:17 -0000 Received: (qmail 24816 invoked by alias); 6 Sep 2013 16:00:17 -0000 Received: from x6.develooper.com (HELO x6.develooper.com) (207.171.7.86)by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Fri, 06 Sep 2013 09:00:13 -0700 Received: from lists-nntp.develooper.com (localhost.localdomain [127.0.0.1])by x6.develooper.com (Postfix) with SMTP id 059311778Afor <perl5-porters@perl.org>; Fri, 6 Sep 2013 09:00:08 -0700 (PDT) Received: (qmail 3153 invoked by uid 514); 6 Sep 2013 16:00:06 -0000 Received: (qmail 2707 invoked from network); 6 Sep 2013 16:00:04 -0000 Received: from x1.develooper.com (207.171.7.70)by x6.develooper.com with SMTP; 6 Sep 2013 16:00:04 -0000 Received: (qmail 24769 invoked by uid 225); 6 Sep 2013 16:00:03 -0000 Received: (qmail 24758 invoked by alias); 6 Sep 2013 16:00:02 -0000 Received: from mail.criticalpath.net (HELO mail.criticalpath.net) (209.228.128.133)by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Fri, 06 Sep 2013 08:59:52 -0700 Received: from JUNSWORTHLT4 (10.128.2.81) by mail.criticalpath.net (8.5.140.03) (authenticated as john.unsworth)id 5208BA720014A825 for perlbug-followup@perl.org; Fri, 6 Sep 2013 16:59:47 +0100 References: <RT-Ticket-119617@perl.org> <006201ceaa29$9fc54610$df4fd230$@cp.net> <rt-3.6.HEAD-1873-1378423344-99.119617-94-0@perl.org> Return-Path: <meta.support@cp.net> Subject: RE: [perl #119617] PerlEmbed 5.14: sv_setsv(ERRSV, &PL_sv_undef); crashes on Linux Thread-Index: AQFeDSk/g60VTU2FGmRE4gE9KeT5ggG2UFPRAcdl3k2afihKoA== To: <perlbug-followup@perl.org> X-Mailer: Microsoft Outlook 15.0 X-Old-Spam-Check-By: la.mx.develooper.com X-Old-Spam-Status: No, hits=-5.9 required=8.0tests=BAYES_00,PERLBUG_CONF,SPF_PASS X-Spam-Check-By: la.mx.develooper.com X-Spam-Status: No, hits=-5.9 required=8.0tests=BAYES_00,PERLBUG_CONF X-Virus-Checked: Checked X-Virus-Checked: Checked Xref: nntp.perl.org perl.perl5.porters:207396 ------=_NextPart_000_0001_01CEAB22.8B73C160 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi James, I'm afraid I'm failing miserably with this. I have extracted the calls = that our code makes into a windows console application but it crashes on = the call to CLEAR_ERRSV(). Everything else seems to work OK if I remove = the call. I can see that vTHX->Ierrgv returns zero. I have attached the = code and test script. It is built against 5.14 from ActiveState. Let me = know what you suggest. Regards, John. Summary of my perl5 (revision 5 version 14 subversion 1) configuration: Platform: osname=3DMSWin32, osvers=3D5.2, archname=3DMSWin32-x86-multi-thread uname=3D'' config_args=3D'undef' hint=3Drecommended, useposix=3Dtrue, d_sigaction=3Dundef useithreads=3Ddefine, usemultiplicity=3Ddefine useperlio=3Ddefine, d_sfio=3Dundef, uselargefiles=3Ddefine, = usesocks=3Dundef use64bitint=3Dundef, use64bitall=3Dundef, uselongdouble=3Dundef usemymalloc=3Dn, bincompat5005=3Dundef Compiler: cc=3D'cl', ccflags =3D'-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 = -D_CONSOLE - DNO_STRICT -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE = -DPERL_IMPLICIT_CONTEXT - DPERL_IMPLICIT_SYS -DUSE_PERLIO -D_USE_32BIT_TIME_T', optimize=3D'-MD -Zi -DNDEBUG -O1', cppflags=3D'-DWIN32' ccversion=3D'12.00.8168', gccversion=3D'', gccosandvers=3D'' intsize=3D4, longsize=3D4, ptrsize=3D4, doublesize=3D8, = byteorder=3D1234 d_longlong=3Dundef, longlongsize=3D8, d_longdbl=3Ddefine, = longdblsize=3D8 ivtype=3D'long', ivsize=3D4, nvtype=3D'double', nvsize=3D8, = Off_t=3D'__int64', lseeksi ze=3D8 alignbytes=3D8, prototype=3Ddefine Linker and Libraries: ld=3D'link', ldflags =3D'-nologo -nodefaultlib -debug -opt:ref,icf = -libpath:"C: \Perl\lib\CORE" -machine:x86' libpth=3D\lib libs=3Doldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib = comdlg32.l ib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib = uuid.lib ws2_32 .lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib = msvcrt. lib perllibs=3Doldnames.lib kernel32.lib user32.lib gdi32.lib = winspool.lib comdlg 32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib = uuid.lib ws 2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib = comctl32.lib msv crt.lib libc=3Dmsvcrt.lib, so=3Ddll, useshrplib=3Dtrue, = libperl=3Dperl514.lib gnulibc_version=3D'' Dynamic Linking: dlsrc=3Ddl_win32.xs, dlext=3Ddll, d_dlsymun=3Dundef, ccdlflags=3D' ' cccdlflags=3D' ', lddlflags=3D'-dll -nologo -nodefaultlib -debug = -opt:ref,icf - libpath:"C:\Perl\lib\CORE" -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PERL_PRESERVE_IVUV = PL_OP_SLAB_ALLOC USE_ITHREADS USE_LARGE_FILES USE_PERLIO = USE_PERL_ATOF USE_SITECUSTOMIZE Locally applied patches: ActivePerl Build 1401 [294969] Built under MSWin32 Compiled at Jun 16 2011 18:54:40 @INC: C:/Perl514/site/lib C:/Perl514/lib Regards, John -----Original Message----- From: James E Keenan via RT [mailto:perlbug-followup@perl.org]=20 Sent: 06 September 2013 00:22 To: john.unsworth@cp.net Subject: [perl #119617] PerlEmbed 5.14: sv_setsv(ERRSV, &PL_sv_undef); = crashes on Linux On Thu Sep 05 04:18:28 2013, john.unsworth@cp.net wrote: > This is a bug report for perl from john.unsworth@cp.net, >=20 > generated with the help of perlbug 1.39 running under perl 5.10.1. >=20 > =20 >=20 > The C++ application calling Perl worked correctly up to Perl 5.10.=20 > However when I upgraded to 5.14 it cores on Linux; it continues to=20 > work OK on Windows. >=20 > =20 >=20 > This is reported just before the core: >=20 > =20 >=20 > Bizarre copy of UNKNOWN. >=20 > Segmentation fault (core dumped) >=20 > =20 >=20 > By adding trace lines I found that the call to sv_setsv(ERRSV,=20 > &PL_sv_undef); was causing the crash >=20 > =20 >=20 > I looked into the header files and found a macro CLEAR_ERROR. At 5.10=20 > this is defined as: >=20 > =20 >=20 > #define ERRSV GvSV(PL_errgv) >=20 > #define CLEAR_ERRSV() STMT_START { sv_setpvn(ERRSV,"",0); if > (SvMAGICAL(ERRSV)) { mg_free(ERRSV); } SvPOK_only(ERRSV); } STMT_END >=20 > =20 >=20 > However at 5.14 it is: >=20 > =20 >=20 > #define ERRSV GvSVn(PL_errgv) >=20 > #define CLEAR_ERRSV() STMT_START { \ >=20 > if (!GvSV(PL_errgv)) { \ >=20 > sv_setpvs(GvSV(gv_add_by_type(PL_errgv, SVt_PV)), ""); = \ >=20 > } else if (SvREADONLY(GvSV(PL_errgv))) { \ >=20 > SvREFCNT_dec(GvSV(PL_errgv)); \ >=20 > GvSV(PL_errgv) =3D newSVpvs(""); \ >=20 > } else { \ >=20 > SV *const errsv =3D GvSV(PL_errgv); \ >=20 > sv_setpvs(errsv, ""); \ >=20 > if (SvMAGICAL(errsv)) { \ >=20 > mg_free(errsv); \ >=20 > } \ >=20 > SvPOK_only(errsv); \ >=20 > } \ >=20 > } STMT_END >=20 > =20 >=20 > So it seems that the implementation of ERRSV has changed in that at 5.14 it > is not initially defined, hence I assume that sv_setsv(ERRSV, &PL_sv_undef); > was trying to set an undefined variable and thus causing the error.=20 > The correct fix seems to be to change this to CLEAR_ERRSV(). Shouldn't = > this be mentioned in the embed documentation? There is no mention at=20 > all of how to reset the error variable. >=20 Would it be possible for you to attach a file which reproduces this = problem either (a) in a file in a pure Perl format; or (b) in a minimal C++ program calling a small Perl program? Thank you very much. Jim Keenan ------=_NextPart_000_0001_01CEAB22.8B73C160 Content-Type: application/octet-stream; name="test.pl" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="test.pl" package test; use strict; sub test { print "Hello\n"; fred(); return 7; } print "loaded OK\n"; #test::test(); 1; ------=_NextPart_000_0001_01CEAB22.8B73C160 Content-Type: text/plain; name="PerlCrash.cpp" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="PerlCrash.cpp" // PerlCrash.cpp : Defines the entry point for the console application.=0A= //=0A= =0A= #include <tchar.h>=0A= =0A= extern "C"=0A= {=0A= =0A= #define HAS_BOOL 1=0A= #define WIN32IO_IS_STDIO=0A= #define HAS_UNION_SEMUN=0A= =0A= #include "EXTERN.h"=0A= #include "perl.h"=0A= #include "XSUB.h"=0A= =0A= } // end extern "C"=0A= =0A= int _tmain(int argc, _TCHAR* argv[])=0A= {=0A= char **perl_argv =3D (char **) calloc(3, sizeof(char *));=0A= int perl_argc =3D 1;=0A= =0A= perl_argv[0] =3D _strdup("PerlCrash.exe");=0A= perl_argv[1] =3D _strdup("test.pl");=0A= =0A= PERL_SYS_INIT(&perl_argc, &perl_argv);=0A= =0A= PerlInterpreter *my_perl =3D perl_alloc();=0A= =0A= perl_construct(my_perl);=0A= =0A= int iRet =3D perl_parse(my_perl, NULL, perl_argc, perl_argv, NULL);=0A= =0A= iRet =3D perl_run(my_perl);=0A= SV **sp =3D PL_stack_sp;=0A= =0A= PERL_SET_CONTEXT(my_perl);=0A= SPAGAIN;=0A= ENTER;=0A= SAVETMPS;=0A= PUSHMARK(sp);=0A= =0A= PUTBACK;=0A= =0A= int ret =3D perl_call_pv("test::test", G_SCALAR|G_EVAL);=0A= =0A= GV* err =3D (vTHX->Ierrgv);=0A= CLEAR_ERRSV();=0A= =0A= return 0;=0A= }=0A= =0A= ------=_NextPart_000_0001_01CEAB22.8B73C160 Content-Type: application/octet-stream; name="test.pl" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="test.pl" package test; use strict; sub test { print "Hello\n"; fred(); return 7; } print "loaded OK\n"; #test::test(); 1; ------=_NextPart_000_0001_01CEAB22.8B73C160--
Subject: Re: [rt.cpan.org #88872] Sometimes multipart Content-Type is ignored when parsing
Date: Sun, 22 Sep 2013 10:54:17 -0400
To: bug-MIME-tools [...] rt.cpan.org
From: "David F. Skoll" <dfs [...] roaringpenguin.com>
Hi, I cannot reproduce the problem. Here's the output I get; what version of MIME-tools and what platform are you testing on? Regards, David. $ perl -Ilib -lMMIME::Parser -e 'my $p = new MIME::Parser; $p->output_under("/tmp"); $e=$p->parse(\*STDIN); print $p->filer->output_dir; $e->dump_skeleton' < /tmp/sample.txt /tmp/msg-1379861585-22373-0 Content-type: multipart/mixed Effective-type: multipart/mixed Body-file: NONE Subject: RE: [perl #119617] PerlEmbed 5.14: sv_setsv(ERRSV, &PL_sv_undef); crashes on Linux Num-parts: 4 -- Content-type: text/plain Effective-type: text/plain Body-file: /tmp/msg-1379861585-22373-0/msg-22373-1.txt -- Content-type: application/octet-stream Effective-type: application/octet-stream Body-file: /tmp/msg-1379861585-22373-0/test.pl Recommended-filename: test.pl -- Content-type: text/plain Effective-type: text/plain Body-file: /tmp/msg-1379861585-22373-0/PerlCrash.cpp Recommended-filename: PerlCrash.cpp -- Content-type: application/octet-stream Effective-type: application/octet-stream Body-file: /tmp/msg-1379861585-22373-0/test-1.pl Recommended-filename: test.pl --
On Sun Sep 22 10:54:34 2013, dfs@roaringpenguin.com wrote: Show quoted text
> Hi, > > I cannot reproduce the problem. Here's the output I get; what version > of MIME-tools and what platform are you testing on?
The system-installed Perl 5.12.4 on Mountain Lion. I did a force install to clobber the existing MIME-tools installation and the problem went away. I probably fiddled with something and temporarily sabotaged it. Sorry for the noise. Please reject this ticket.
Rejecting ticket per request from original requestor.