NetBSD Problem Report #51903

From www@NetBSD.org  Sun Jan 22 08:10:54 2017
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 23F0A7A26C
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 22 Jan 2017 08:10:54 +0000 (UTC)
Message-Id: <20170122081052.F00877A2BD@mollari.NetBSD.org>
Date: Sun, 22 Jan 2017 08:10:52 +0000 (UTC)
From: dhgutteridge@sympatico.ca
Reply-To: dhgutteridge@sympatico.ca
To: gnats-bugs@NetBSD.org
Subject: textproc/p5-XML-Sablotron has significant segfault issues
X-Send-Pr-Version: www-1.0

>Number:         51903
>Category:       pkg
>Synopsis:       textproc/p5-XML-Sablotron has significant segfault issues
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jan 22 08:15:00 +0000 2017
>Last-Modified:  Wed Jan 25 19:30:00 +0000 2017
>Originator:     David H. Gutteridge
>Release:        current
>Organization:
>Environment:
NetBSD arcus-v3.nonus-porta.net 7.99.40 NetBSD 7.99.40 (GENERIC.201610250000Z) amd64
>Description:
I was running some Perl code that uses textproc/p5-XML-Sablotron which
was consistently segfaulting, so I tried running "make test" on that
package, and found each test script generates segfaults as well, e.g.
sablot.t results in:

Core was generated by `perl'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000079a2b2ed422b in Perl_pp_entersub ()
   from /usr/pkg/lib/perl5/5.24.0/x86_64-netbsd-thread-multi/CORE/libperl.so
(gdb) bt
#0  0x000079a2b2ed422b in Perl_pp_entersub ()
   from /usr/pkg/lib/perl5/5.24.0/x86_64-netbsd-thread-multi/CORE/libperl.so
#1  0x000079a2b2e4f730 in Perl_call_sv ()
   from /usr/pkg/lib/perl5/5.24.0/x86_64-netbsd-thread-multi/CORE/libperl.so
#2  0x000079a2b1a0b7eb in SchemeHandlerGetStub ()
   from /usr/pkg/lib/perl5/vendor_perl/5.24.0/x86_64-netbsd-thread-multi/auto/XML/Sablotron/Sablotron.so
#3  0x000079a2b16742f4 in DataLine::get(Situation&, char*, int) ()
   from /usr/pkg/lib/libsablot.so.0
#4  0x000079a2b165b15b in TreeConstructer::feedDocumentToParser(Situation&, void*) () from /usr/pkg/lib/libsablot.so.0
#5  0x000079a2b165b375 in TreeConstructer::parseDataLineUsingGivenExpat(Situation&, Tree*, DataLine*, XML_ParserStruct*) () from /usr/pkg/lib/libsablot.so.0
#6  0x000079a2b165b539 in TreeConstructer::parseDataLineUsingExpat(Situation&, Tree*, DataLine*, char*) () from /usr/pkg/lib/libsablot.so.0
#7  0x000079a2b166e9bc in Tree::parse(Situation&, DataLine*) ()
   from /usr/pkg/lib/libsablot.so.0
#8  0x000079a2b165d461 in Processor::addLineParse(Situation&, Tree*&, Str&, int, int) () from /usr/pkg/lib/libsablot.so.0
#9  0x000079a2b165f031 in Processor::readTreeFromURI(Situation&, Tree*&, Str const&, Str const&, int, int) () from /usr/pkg/lib/libsablot.so.0
#10 0x000079a2b164639c in Expression::getDocument_(Situation&, void*&, Str const&, Str const&, Processor*) () from /usr/pkg/lib/libsablot.so.0
#11 0x000079a2b1649272 in Expression::callFunc(Situation&, Expression&, PList<Expression*>&, Context*) () from /usr/pkg/lib/libsablot.so.0
#12 0x000079a2b164ec25 in Expression::eval(Situation&, Expression&, Context*, int) () from /usr/pkg/lib/libsablot.so.0
#13 0x000079a2b164dde5 in Expression::createContext(Situation&, Context*&, int)
    () from /usr/pkg/lib/libsablot.so.0
#14 0x000079a2b164d905 in Expression::createContext(Situation&, Context*&, int)
    () from /usr/pkg/lib/libsablot.so.0
#15 0x000079a2b167e002 in XSLElement::execute(Situation&, Context*, int) ()
   from /usr/pkg/lib/libsablot.so.0
#16 0x000079a2b1677539 in VertexList::execute(Situation&, Context*, int) ()
   from /usr/pkg/lib/libsablot.so.0
#17 0x000079a2b1677573 in Daddy::execute(Situation&, Context*, int) ()
   from /usr/pkg/lib/libsablot.so.0
#18 0x000079a2b167c919 in XSLElement::execute(Situation&, Context*, int) ()
   from /usr/pkg/lib/libsablot.so.0
#19 0x000079a2b165ea17 in Processor::execApplyTemplates(Situation&, Context*, int) () from /usr/pkg/lib/libsablot.so.0
#20 0x000079a2b165eae1 in Processor::execute(Situation&, Vertex*, Context*&, int) () from /usr/pkg/lib/libsablot.so.0
#21 0x000079a2b167dc4f in XSLElement::execute(Situation&, Context*, int) ()
   from /usr/pkg/lib/libsablot.so.0
#22 0x000079a2b1677539 in VertexList::execute(Situation&, Context*, int) ()
   from /usr/pkg/lib/libsablot.so.0
#23 0x000079a2b1677573 in Daddy::execute(Situation&, Context*, int) ()
   from /usr/pkg/lib/libsablot.so.0
#24 0x000079a2b1677589 in RootNode::execute(Situation&, Context*, int) ()
   from /usr/pkg/lib/libsablot.so.0
#25 0x000079a2b1660e80 in Processor::run(Situation&, char const*, void*) ()
   from /usr/pkg/lib/libsablot.so.0
#26 0x000079a2b1662058 in SablotRunProcessor ()
   from /usr/pkg/lib/libsablot.so.0
#27 0x000079a2b1a18fac in XS_XML__Sablotron__Processor_RunProcessor ()
   from /usr/pkg/lib/perl5/vendor_perl/5.24.0/x86_64-netbsd-thread-multi/auto/XML/Sablotron/Sablotron.so
#28 0x000079a2b2ed458c in Perl_pp_entersub ()
   from /usr/pkg/lib/perl5/5.24.0/x86_64-netbsd-thread-multi/CORE/libperl.so
#29 0x000079a2b2ecd0e6 in Perl_runops_standard ()
   from /usr/pkg/lib/perl5/5.24.0/x86_64-netbsd-thread-multi/CORE/libperl.so
#30 0x000079a2b2e56ee3 in perl_run ()
   from /usr/pkg/lib/perl5/5.24.0/x86_64-netbsd-thread-multi/CORE/libperl.so
#31 0x0000000000401092 in main ()

I don't know if this is NetBSD-specific, or a more general issue.

>How-To-Repeat:
Try "make test".
>Fix:
Not known at present.

>Audit-Trail:
From: Benny Siegert <bsiegert@gmail.com>
To: gnats-bugs@netbsd.org
Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org
Subject: Re: pkg/51903: textproc/p5-XML-Sablotron has significant segfault issues
Date: Sun, 22 Jan 2017 13:17:17 +0100

 > I don't know if this is NetBSD-specific, or a more general issue.

 Probably NetBSD-specific. I get this on Linux:

 ===> Testing for p5-XML-Sablotron-1.01nb6
 Manifying 2 pod documents
 Running Mkbootstrap for XML::Sablotron ()
 chmod 644 "Sablotron.bs"
 PERL_DL_NONLAZY=1 "/home/bsiegert/pkg/bin/perl"
 "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef
 *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')"
 t/*.t
 t/dom.t ......... ok
 t/domHandler.t .. ok
 t/sablot.t ...... ok
 All tests successful.
 Files=3, Tests=53,  1 wallclock secs ( 0.04 usr  0.00 sys +  0.08 cusr
  0.00 csys =  0.12 CPU)
 Result: PASS

 Maybe it has something to do with PaX being enabled on NetBSD-current?

From: coypu@SDF.ORG
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/51903
Date: Sun, 22 Jan 2017 16:29:30 +0000

 No, disabling PaX & ASLR doesn't help.
 It's also complaining before the segfault:

 ===> Testing for p5-XML-Sablotron-1.01nb6
 Manifying 2 pod documents
 Running Mkbootstrap for XML::Sablotron ()
 chmod 644 "Sablotron.bs"
 PERL_DL_NONLAZY=1 "/home/pkg/pkg/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
 t/dom.t ......... Failed 1/39 subtests 
 t/domHandler.t .. Failed 3/4 subtests 
 t/sablot.t ...... Failed 3/10 subtests 

 Test Summary Report
 -------------------
 t/dom.t       (Wstat: 139 Tests: 38 Failed: 0)
   Non-zero wait status: 139
   Parse errors: Bad plan.  You planned 39 tests but ran 38.
 t/domHandler.t (Wstat: 139 Tests: 1 Failed: 0)
   Non-zero wait status: 139
   Parse errors: Bad plan.  You planned 4 tests but ran 1.
 t/sablot.t    (Wstat: 139 Tests: 7 Failed: 0)
   Non-zero wait status: 139
   Parse errors: Bad plan.  You planned 10 tests but ran 7.
 Files=3, Tests=46,  0 wallclock secs ( 0.01 usr  0.02 sys +  0.03 cusr  0.04 csys =  0.10 CPU)
 Result: FAIL
 Failed 3/3 test programs. 0/46 subtests failed.
 *** Error code 255

From: "David H. Gutteridge" <dhgutteridge@sympatico.ca>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/51903
Date: Sun, 22 Jan 2017 12:26:04 -0500

 On Sun, 2017-01-22 at 16:30 +0000, coypu@SDF.ORG wrote:
 > 
 >  No, disabling PaX & ASLR doesn't help.
 >  It's also complaining before the segfault:
 >  
 >  ===> Testing for p5-XML-Sablotron-1.01nb6
 >  Manifying 2 pod documents
 >  Running Mkbootstrap for XML::Sablotron ()
 >  chmod 644 "Sablotron.bs"
 >  PERL_DL_NONLAZY=1 "/home/pkg/pkg/bin/perl" "-MExtUtils::Command::MM" 
 > "-MTest::Harness" "-e" "undef *Test::Harness::Switches;
 > test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
 >  t/dom.t ......... Failed 1/39 subtests 
 >  t/domHandler.t .. Failed 3/4 subtests 
 >  t/sablot.t ...... Failed 3/10 subtests 
 >  
 >  Test Summary Report
 >  -------------------
 >  t/dom.t       (Wstat: 139 Tests: 38 Failed: 0)
 >    Non-zero wait status: 139
 >    Parse errors: Bad plan.  You planned 39 tests but ran 38.
 >  t/domHandler.t (Wstat: 139 Tests: 1 Failed: 0)
 >    Non-zero wait status: 139
 >    Parse errors: Bad plan.  You planned 4 tests but ran 1.
 >  t/sablot.t    (Wstat: 139 Tests: 7 Failed: 0)
 >    Non-zero wait status: 139
 >    Parse errors: Bad plan.  You planned 10 tests but ran 7.
 >  Files=3, Tests=46,  0 wallclock secs ( 0.01 usr  0.02 sys +  0.03
 > cusr  0.04 csys =  0.10 CPU)
 >  Result: FAIL
 >  Failed 3/3 test programs. 0/46 subtests failed.
 >  *** Error code 255

 Each of those test scripts generates a distinct segfault, that's why
 the test target is noting fewer sub-test completions than expected for
 all of them. The perl.core file gets overwritten as each test script
 runs and faults.

 Thanks for checking on another OS, that was one of the things I was
 wondering about, because I'm working on a package that optionally
 depends on this one, and I wasn't sure if it was worth offering that
 choice. It seems it is (though not as the default, at least at
 present).

From: Thomas Klausner <wiz@NetBSD.org>
To: NetBSD bugtracking <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: pkg/51903
Date: Sun, 22 Jan 2017 18:37:48 +0100

 On Sun, Jan 22, 2017 at 05:30:01PM +0000, David H. Gutteridge wrote:
 >  Thanks for checking on another OS, that was one of the things I was
 >  wondering about, because I'm working on a package that optionally
 >  depends on this one, and I wasn't sure if it was worth offering that
 >  choice. It seems it is (though not as the default, at least at
 >  present).

 Please note that the last release of this upstream was in 2010, and that was an " ** UNAUTHORIZED RELEASE **":
 http://search.cpan.org/~mlehmann/XML-Sablotron/

 The last authorized one is from 2005, so I wouldn't use this package...
  Thomas

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/51903
Date: Mon, 23 Jan 2017 18:03:37 +0000

 On Sun, Jan 22, 2017 at 05:30:01PM +0000, David H. Gutteridge wrote:
  >  Each of those test scripts generates a distinct segfault, that's why
  >  the test target is noting fewer sub-test completions than expected for
  >  all of them. The perl.core file gets overwritten as each test script
  >  runs and faults.
  >  
  >  Thanks for checking on another OS, that was one of the things I was
  >  wondering about, because I'm working on a package that optionally
  >  depends on this one, and I wasn't sure if it was worth offering that
  >  choice. It seems it is (though not as the default, at least at
  >  present).

 Check for warnings during the build? Given the symptoms there must be
 something wrong with the Perl <-> C glue. I remember fixing this some
 in the past; it probably needs more.

 -- 
 David A. Holland
 dholland@netbsd.org

From: "David H. Gutteridge" <dhgutteridge@sympatico.ca>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/51903
Date: Mon, 23 Jan 2017 17:13:54 -0500

 On Mon, 2017-01-23 at 18:05 +0000, David Holland wrote:
 > The following reply was made to PR pkg/51903; it has been noted by
 > GNATS.
 > 
 > From: David Holland <dholland-pbugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: pkg/51903
 > Date: Mon, 23 Jan 2017 18:03:37 +0000
 >  
 >  Check for warnings during the build? Given the symptoms there must
 > be
 >  something wrong with the Perl <-> C glue. I remember fixing this
 > some
 >  in the past; it probably needs more.

 There are compiler warnings that reference pointers being cast to int,
 which seems an obvious culprit. I'd started looking at fixing that the
 other day. I haven't resolved all of it, and I have zero experience
 with Perl XS code, but I've made progress. That is, when each of the
 test scripts is invoked manually, two of the three now complete
 successfully where all three triggered segfaults before. Unfortunately,
 sablot.t still faults exactly the same way. (With what I've done so
 far, I was also able to get my package submission PR pkg/51906 to use
 this as a dependency without faulting, where it would immediately
 fault previously.)

 I added more changes to your existing patch to Processor/Processor.h,
 and also patched two more files. (There's separate confusion about
 function signatures indicating an int return value where the variable
 is actually unsigned long, I made those size_t as well for
 consistency.)

 What I've tried so far is:

 (Most of this patch is pre-existing, I adjusted more int and unsigned
 long use to size_t.)

 --- Processor/Processor.h.orig	2004-06-04 09:20:40.000000000
 -0400
 +++ Processor/Processor.h
 @@ -119,7 +119,7 @@
      if (processor_obj) 
        XPUSHs(processor_obj);
      else
 -      XPUSHs(&sv_undef);
 +      XPUSHs(&PL_sv_undef);
      XPUSHs(sv_2mortal(newSViv(severity)));
      XPUSHs(sv_2mortal(newSViv(facility)));
      XPUSHs(sv_2mortal(newSViv(code)));
 @@ -167,7 +167,7 @@
      if (processor_obj) 
        XPUSHs(processor_obj);
      else
 -      XPUSHs(&sv_undef);
 +      XPUSHs(&PL_sv_undef);
      XPUSHs(sv_2mortal(newSViv(code)));
      XPUSHs(sv_2mortal(newSViv(level)));
      foo = fields;
 @@ -215,7 +215,7 @@
      if (processor_obj) 
        XPUSHs(processor_obj);
      else
 -      XPUSHs(&sv_undef);
 +      XPUSHs(&PL_sv_undef);
      XPUSHs(sv_2mortal(newSViv(code)));
      XPUSHs(sv_2mortal(newSViv(level)));
      foo = fields;
 @@ -250,7 +250,7 @@
    GV *gv;
    unsigned long ret = 0;
    SV *value;
 -  unsigned int len;
 +  size_t len;
  
    wrapper = (SV*)userData;
  
 @@ -270,7 +270,7 @@
      if (processor_obj) 
        XPUSHs(processor_obj);
      else
 -      XPUSHs(&sv_undef);
 +      XPUSHs(&PL_sv_undef);
      XPUSHs(sv_2mortal(newSVpv((char*) scheme, strlen(scheme))));
      XPUSHs(sv_2mortal(newSVpv((char*) rest, strlen(rest))));
  
 @@ -309,14 +309,14 @@
    return ret;
  }
  
 -int SchemeHandlerOpenStub(void *userData, void *processor,
 -    const char *scheme, const char *rest, int *handle) {
 +size_t SchemeHandlerOpenStub(void *userData, void *processor,
 +    const char *scheme, const char *rest, size_t *handle) {
  
    SV *wrapper;
    SV * processor_obj;
    HV *stash;
    GV *gv;
 -  unsigned long ret = 0;
 +  size_t ret = 0;
    SV *value;
  
    wrapper = (SV*)userData;
 @@ -337,7 +337,7 @@
      if (processor_obj) 
        XPUSHs(processor_obj);
      else
 -      XPUSHs(&sv_undef);
 +      XPUSHs(&PL_sv_undef);
      XPUSHs(sv_2mortal(newSVpv((char*) scheme, strlen(scheme))));
      XPUSHs(sv_2mortal(newSVpv((char*) rest, strlen(rest))));
  
 @@ -351,7 +351,7 @@
      if ( SvOK(value) ) {
        ret = 0;
        SvREFCNT_inc(value);
 -      *handle = (int) value;
 +      *handle = (size_t)value;
      } else {
        ret = 100;
        *handle = 0;
 @@ -366,16 +366,16 @@
    return ret;
  }
  
 -int SchemeHandlerGetStub(void *userData, void *processor,
 -    int handle, char *buffer, int *byteCount) {
 +size_t SchemeHandlerGetStub(void *userData, void *processor,
 +    size_t handle, char *buffer, int *byteCount) {
  
    SV *wrapper;
    SV * processor_obj;
    HV *stash;
    GV *gv;
 -  unsigned long ret = 0;
 +  size_t ret = 0;
    SV *value;
 -  unsigned int len;
 +  size_t len;
  
    wrapper = (SV*)userData;
  
 @@ -395,7 +395,7 @@
      if (processor_obj) 
        XPUSHs(processor_obj);
      else
 -      XPUSHs(&sv_undef);
 +      XPUSHs(&PL_sv_undef);
      XPUSHs((SV*)handle);
      XPUSHs(sv_2mortal(newSViv(*byteCount)));
      PUTBACK;
 @@ -425,14 +425,14 @@
    return ret;
  }
  
 -int SchemeHandlerPutStub(void *userData, void *processor,
 -    int handle, const char *buffer, int *byteCount) {
 +size_t SchemeHandlerPutStub(void *userData, void *processor,
 +    size_t handle, const char *buffer, int *byteCount) {
  
    SV *wrapper;
    SV * processor_obj;
    HV *stash;
    GV *gv;
 -  unsigned long ret = 0;
 +  size_t ret = 0;
    SV *value;
  
    wrapper = (SV*)userData;
 @@ -453,7 +453,7 @@
      if (processor_obj) 
        XPUSHs(processor_obj);
      else
 -      XPUSHs(&sv_undef);
 +      XPUSHs(&PL_sv_undef);
      XPUSHs((SV*) handle);
      XPUSHs(sv_2mortal(newSVpv((char*) buffer, *byteCount)));
      PUTBACK;
 @@ -479,14 +479,14 @@
    return ret;
  }
  
 -int SchemeHandlerCloseStub(void *userData, void *processor,
 -    int handle) {
 +size_t SchemeHandlerCloseStub(void *userData, void *processor,
 +    size_t handle) {
  
    SV *wrapper;
    SV * processor_obj;
    HV *stash;
    GV *gv;
 -  unsigned long ret = 0;
 +  size_t ret = 0;
  
    wrapper = (SV*)userData;
  
 @@ -506,7 +506,7 @@
      if (processor_obj) 
        XPUSHs(processor_obj);
      else
 -      XPUSHs(&sv_undef);
 +      XPUSHs(&PL_sv_undef);
      XPUSHs((SV*) handle);
  
      PUTBACK;
 @@ -553,7 +553,7 @@
          if (processor_obj) 
              XPUSHs(processor_obj);
          else
 -            XPUSHs(&sv_undef);
 +            XPUSHs(&PL_sv_undef);
  
          PUTBACK;
          
 @@ -593,7 +593,7 @@
          if (processor_obj) 
              XPUSHs(processor_obj);
          else
 -            XPUSHs(&sv_undef);
 +            XPUSHs(&PL_sv_undef);
  
          XPUSHs(sv_2mortal(newSVpv((char*) name, strlen(name))));
          att = (char**)atts;
 @@ -639,7 +639,7 @@
          if (processor_obj) 
              XPUSHs(processor_obj);
          else
 -            XPUSHs(&sv_undef);
 +            XPUSHs(&PL_sv_undef);
  
          XPUSHs(sv_2mortal(newSVpv((char*) name, strlen(name))));
  
 @@ -680,7 +680,7 @@
          if (processor_obj) 
              XPUSHs(processor_obj);
          else
 -            XPUSHs(&sv_undef);
 +            XPUSHs(&PL_sv_undef);
  
          XPUSHs(sv_2mortal(newSVpv((char*) prefix, strlen(prefix))));
          XPUSHs(sv_2mortal(newSVpv((char*) uri, strlen(uri))));
 @@ -722,7 +722,7 @@
          if (processor_obj) 
              XPUSHs(processor_obj);
          else
 -            XPUSHs(&sv_undef);
 +            XPUSHs(&PL_sv_undef);
  
          XPUSHs(sv_2mortal(newSVpv((char*) prefix, strlen(prefix))));
  
 @@ -763,7 +763,7 @@
          if (processor_obj) 
              XPUSHs(processor_obj);
          else
 -            XPUSHs(&sv_undef);
 +            XPUSHs(&PL_sv_undef);
  
          XPUSHs(sv_2mortal(newSVpv((char*) contents,
 strlen(contents))));
  
 @@ -804,7 +804,7 @@
          if (processor_obj) 
              XPUSHs(processor_obj);
          else
 -            XPUSHs(&sv_undef);
 +            XPUSHs(&PL_sv_undef);
  
          XPUSHs(sv_2mortal(newSVpv((char*) target, strlen(target))));
          XPUSHs(sv_2mortal(newSVpv((char*) contents,
 strlen(contents))));
 @@ -846,7 +846,7 @@
          if (processor_obj) 
              XPUSHs(processor_obj);
          else
 -            XPUSHs(&sv_undef);
 +            XPUSHs(&PL_sv_undef);
  
          XPUSHs(sv_2mortal(newSVpv((char*) contents, length)));
  
 @@ -886,7 +886,7 @@
          if (processor_obj) 
              XPUSHs(processor_obj);
          else
 -            XPUSHs(&sv_undef);
 +            XPUSHs(&PL_sv_undef);
  
          PUTBACK;
          
 @@ -931,7 +931,7 @@
      if (processor_obj) 
        XPUSHs(processor_obj);
      else
 -      XPUSHs(&sv_undef);
 +      XPUSHs(&PL_sv_undef);
      XPUSHs(sv_2mortal(newSVpv((char*) contentType,
 strlen(contentType))));
      XPUSHs(sv_2mortal(newSVpv((char*) encoding, strlen(encoding))));

 --- Processor/Handler_stubs.h.orig	2003-02-21 09:17:32.000000000
 -0500
 +++ Processor/Handler_stubs.h
 @@ -67,22 +67,22 @@
  
  Declare
  (
 - int SchemeHandlerOpenStub(void *userData, void *processor, const char
 *scheme, const char *rest, int *handle);
 + size_t SchemeHandlerOpenStub(void *userData, void *processor, const
 char *scheme, const char *rest, size_t *handle);
  )
  
  Declare
  (
 - int SchemeHandlerGetStub(void *userData, void *processor, int handle,
 char *buffer, int *byteCount); 
 + size_t SchemeHandlerGetStub(void *userData, void *processor, size_t
 handle, char *buffer, int *byteCount); 
  )
  
  Declare
  (
 - int SchemeHandlerPutStub(void *userData, void *processor, int handle,
 const char *buffer, int *byteCount);
 + size_t SchemeHandlerPutStub(void *userData, void *processor, size_t
 handle, const char *buffer, int *byteCount);
  )
  
  Declare
  (
 - int SchemeHandlerCloseStub(void *userData, void *processor, int
 handle);
 + size_t SchemeHandlerCloseStub(void *userData, void *processor, size_t
 handle);
  )
  
  /* SAX-like handler */

 --- Situation/Situation.xsh.orig	2003-02-21 09:17:32.000000000
 -0500
 +++ Situation/Situation.xsh
 @@ -42,13 +42,13 @@
  PROTOTYPES: ENABLE
  ##############################################################
  
 -int
 +size_t
  _getNewSituationHandle(object)
          SV*      object
          CODE:
          SablotSituation sit;
          SablotCreateSituation(&sit);
 -        RETVAL = (int)sit;
 +        RETVAL = (size_t)sit;
          OUTPUT:
          RETVAL
  


From: "David H. Gutteridge" <dhgutteridge@sympatico.ca>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/51903
Date: Mon, 23 Jan 2017 18:59:29 -0500

 Bah, it looks like Gnats keeps garbling characters in my emails. Here's
 a uuencoded tgz of the patches so far, if anyone's curious.

 begin-base64 644 p5-XML-Sablotron_new_patches.tgz
 H4sIANOWhlgAA+1aW2/iOBTu6+ZXWNrRigChzgVSikZqhzJTaaqCGlrNPqEU
 DGQ3k6DEMNNdzX9fX3KDNk1oOy3M+ns58SU+/o6PfWwnjcOFjcdzZRD4YxSG
 fjA6t72Ji4JRiJe34Wh+8HxAgpZhUKmaTZiVFBrU9QNVh4ZqmDpJHtBSAx4A
 +AK6C7EMsR0AcDBxwrGzcFFevaLyPcW7S4Q/WGfvJElRFJB4weGaFzTmDT9w
 Zr9pEOoK1BRNBbB9rJrHutaAMYACmxBKtVotvxnp5AQoLbOuaaDGxcmJBCRw
 hsauHSAJVCQFOB4G1niOvqLo7f4CeRZpoLLynQmoLkMUnNnYrgOeXsTa6mDs
 eyEG4zkZ0WrImljPC1CI60xBdc7aljtSDYTOP2j0k3VGOlK1QC4m/gnhcn2g
 b/KW65HW2+V0iqKS6u0dRl1/6WG5A3L4llYVvVxWWxmag+VTaGZMnKc+h2tp
 fZtcy6gsQ7jr+iHalnIunS1aWyOUdPawCqzTL4rr/I2iIkLwUHrrpUngFdC4
 F//Tp5eI/RSPx3/VaDXNOP5rhkry1ZZp6CL+vwby4n/ylIn9hgJbCjRo7Nfg
 sQHXYr9xL/ZnmmBxX1XbdRPUuKBxn8KZgkqyQI38279kwAsA+DK4ts7DjdIO
 L0VuiMjKmq33R7gaLb0JmrKFcq1kcDHKFGaLSLb21Q+w7VY89M26cVaVEK1Q
 4OA7WS6uO7XHjluy7tifIFaP2YLsfqgtmNhdWyR9LqjnEpu5acWp74P3YOog
 dxJyvprapHy5+D/wbULGlwnO99MNqM5W7I2lFzozD02A63szECBM3oasxCKV
 Vra7RB3KMKlHdwEu8hi5KIazJLPXt8BeLEjIfg8q1k1VjsM/LWVdMXlXTLi7
 pl+sKhW6r6rKIN5ChzggFCs8KRcOSqaFaMPN36eJ6G1mDR2266oBapHk9iAj
 sAw8Kki1H6Sm8vQzCDfP9gcR8K9Ue9ZBhFv/SacRohvE3hd5U+KNYM0RWPY5
 ySZRM5x3sn6t5Pp16rQ5rv64G7Nh09l6yYVw4qbKrMFE1hrAWvU/V5hVZcCG
 lSNrdwprddX72L0cjhxvHFXvxCaJnIKOA/FPGURjVLtXysdUjseQ4gcz7qZe
 Faaa0/dhNLKtVl1tETJclp6QZQ+snFbpA3LeNCytjtlpm0PyW0++l4ozepuF
 eC52ZIqyjqan3UemHgnqmTFJJurgevjhtPuZu6qhNVnsiGRpVy173/CAqxbf
 OOQ5bGmlDzpsKb07HjOMpk4dkotdckhQyiMzwSAegmIPNfnuJpKlPbT8FdKm
 j+b63xZN3vfAt/CuEktcE7aoR3Gxox71gFc0+URork2Egq4XE9gkUUTlUUJp
 k0nPkxzOoc05tPeBQ/GM9uzM9pAmMptDChtTt+S1qzJJRefKls7uULj4dc3A
 uR6xgysX+891EaCp8z1hy5Mbw17cyjJwkibIs5zcKJmaRq3Fxa9tLc63xRYE
 LvafL9lxYeThMGEcZ2Q5H0GDcuZi/zljO5ih9JTLk1vPiALLMbsZLG5zsf92
 SxkTujM8z3rIEWd6tA9Mc0J9W2e3G1zsyC6reDSGdwu06YI0b6tbH+SN/Ynj
 zZKG4ox4FXjx7z/x9z/LwUsbO743Sp++hy/zBbDg/x9oqkby/4+utuj/P7qq
 iu9/r4H173/J2B8mTw3iBdv9/ZPTSHSFUld1eoNCBZ3bg6v+sD/8c9CzjkHv
 8vTDRU8Cvz8L0QE3PpVKYESiyiWZaHFn+AG1QlYJNMZyuviQgxR/4CVpQbd/
 1jvO1LNvXR8nzZGTJO5slnYDZGOU1CGLjoPTK1YArnrDm9OL+I6VtVC7Xxbd
 sK4r6F8PycKZ6Q+v/zMWBwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
 AQEBAQEBAQEBgZ3Ef6ZMCIUAUAAA
 ====

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/51903
Date: Tue, 24 Jan 2017 16:43:52 +0000

 On Mon, Jan 23, 2017 at 06:05:01PM +0000, David Holland wrote:
  >  Check for warnings during the build? Given the symptoms there must be
  >  something wrong with the Perl <-> C glue. I remember fixing this some
  >  in the past; it probably needs more.

 So, erm, when I fixed it in the past I apparently wrote this:

 date: 2011-10-15 13:53:51 -0400;  author: dholland;  state: Exp; lines: +3 -1;
 Fix build with perl 5.14... I think. Someone who actually knows how to
 write Perl bindings should double-check this.

 XXX: This will almost certainly not work on LP64 platforms as it casts
 XXX: Perl-provided pointers to int and back. However, fixing this
 XXX: requires changing the API of the parent Sablotron package, which
 XXX: doesn't seem like a great idea at the moment.


 Looks like textproc/sablotron itself was last updated in 2005, so it
 may be time to patch it. Or maybe just kill it off.

 There seems to be a slightly newer sablotron 1.0.3 on sourceforge
 here: https://sourceforge.net/projects/sablotron/files/

 but that site also seems to be an import some random person did and
 not from the original upstream, so whether it's any good (or even safe
 to use) is an open question.

 Is the package you're looking at using sablotron because it is also
 old, or because its upstream likes sablotron over other possible
 options? If the latter, that's a sign it might be worth working on it
 a bit...


 -- 
 David A. Holland
 dholland@netbsd.org

From: "David H. Gutteridge" <dhgutteridge@sympatico.ca>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/51903
Date: Tue, 24 Jan 2017 15:13:00 -0500

 On Tue, 2017-01-24 at 16:45 +0000, David Holland wrote: 
 >  So, erm, when I fixed it in the past I apparently wrote this:
 >  
 >  date: 2011-10-15 13:53:51 -0400;  author: dholland;  state: Exp;
 > lines: +3 -1;
 >  Fix build with perl 5.14... I think. Someone who actually knows how
 > to
 >  write Perl bindings should double-check this.
 >  
 >  XXX: This will almost certainly not work on LP64 platforms as it
 > casts
 >  XXX: Perl-provided pointers to int and back. However, fixing this
 >  XXX: requires changing the API of the parent Sablotron package,
 > which
 >  XXX: doesn't seem like a great idea at the moment.
 >  
 >  
 >  Looks like textproc/sablotron itself was last updated in 2005, so it
 >  may be time to patch it. Or maybe just kill it off.
 >  
 >  There seems to be a slightly newer sablotron 1.0.3 on sourceforge
 >  here: https://sourceforge.net/projects/sablotron/files/
 >  
 >  but that site also seems to be an import some random person did and
 >  not from the original upstream, so whether it's any good (or even
 > safe
 >  to use) is an open question.
 >  
 >  Is the package you're looking at using sablotron because it is also
 >  old, or because its upstream likes sablotron over other possible
 >  options? If the latter, that's a sign it might be worth working on 
 >  it a bit...

 Both, actually. It's also old (but it's basic Perl + XSL, and seems to
 "just work"), but it prefers Sablotron over LibXSLT. However, it works
 fine with LibXSLT as well, which is what I've made the package depend
 upon. It doesn't seem critical to have a working Sablotron from that
 perspective.

From: "David H. Gutteridge" <dhgutteridge@sympatico.ca>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/51903
Date: Tue, 24 Jan 2017 18:53:22 -0500

 On Tue, 2017-01-24 at 16:45 +0000, David Holland wrote:
 >  Looks like textproc/sablotron itself was last updated in 2005, so it
 >  may be time to patch it. Or maybe just kill it off.

 According to a book from 2002 ("XML Primer Plus" by Nicholas Chase),
 Perl's "XML::Sablotron is the most mature and widely-packaged" XSLT
 module. I imagine that's why the author of the package I'm working on
 preferred it over XML::LibXSLT. Nowadays, that statement isn't really
 relevant, e.g. the pkgsrc DESCR for XML::LibXSLT states "Performance is
 currently about twice that of XML::Sablotron." (That statement's also
 possibly out of date.)

 Support in other downstream packagers seems mixed. Debian removed the
 Sablotron library in 2011. Fedora doesn't support it either. FreeBSD
 still provides Sablotron itself, but deleted the associated Perl
 modules in 2013.

From: Benny Siegert <bsiegert@gmail.com>
To: gnats-bugs@netbsd.org
Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org, 
	dhgutteridge@sympatico.ca
Subject: Re: pkg/51903
Date: Wed, 25 Jan 2017 15:00:21 +0100

 On Wed, Jan 25, 2017 at 12:55 AM, David H. Gutteridge
 <dhgutteridge@sympatico.ca> wrote:
 >  Support in other downstream packagers seems mixed. Debian removed the
 >  Sablotron library in 2011. Fedora doesn't support it either. FreeBSD
 >  still provides Sablotron itself, but deleted the associated Perl
 >  modules in 2013.

 Should I formally file a request to remove sablotron and
 p5-XML-Sablotron after the next branch?

From: "Thomas Klausner" <wiz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/51903 CVS commit: pkgsrc/textproc
Date: Wed, 25 Jan 2017 14:12:23 +0000

 Module Name:	pkgsrc
 Committed By:	wiz
 Date:		Wed Jan 25 14:12:23 UTC 2017

 Modified Files:
 	pkgsrc/textproc: Makefile
 Removed Files:
 	pkgsrc/textproc/p5-XML-Sablotron: DESCR Makefile distinfo
 	pkgsrc/textproc/p5-XML-Sablotron/patches: patch-DOM_DOM_xsh
 	    patch-Processor_Processor_h

 Log Message:
 Remove p5-XML-Sablotron.

 Obsolete and core dumps.

 Inspired by PR 51903.


 To generate a diff of this commit:
 cvs rdiff -u -r1.902 -r1.903 pkgsrc/textproc/Makefile
 cvs rdiff -u -r1.1.1.1 -r0 pkgsrc/textproc/p5-XML-Sablotron/DESCR
 cvs rdiff -u -r1.22 -r0 pkgsrc/textproc/p5-XML-Sablotron/Makefile
 cvs rdiff -u -r1.5 -r0 pkgsrc/textproc/p5-XML-Sablotron/distinfo
 cvs rdiff -u -r1.1 -r0 \
     pkgsrc/textproc/p5-XML-Sablotron/patches/patch-DOM_DOM_xsh \
     pkgsrc/textproc/p5-XML-Sablotron/patches/patch-Processor_Processor_h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: PR/51903 CVS commit: pkgsrc/textproc
Date: Wed, 25 Jan 2017 16:51:00 +0000

 On Wed, Jan 25, 2017 at 02:15:01PM +0000, Thomas Klausner wrote:
  >  Log Message:
  >  Remove p5-XML-Sablotron.
  >  
  >  Obsolete and core dumps.

 If we're going to do that, we should remove the base sablotron also.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Thomas Klausner <wiz@NetBSD.org>
To: NetBSD bugtracking <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: PR/51903 CVS commit: pkgsrc/textproc
Date: Wed, 25 Jan 2017 20:28:39 +0100

 On Wed, Jan 25, 2017 at 04:55:01PM +0000, David Holland wrote:
 > The following reply was made to PR pkg/51903; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-pbugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: PR/51903 CVS commit: pkgsrc/textproc
 > Date: Wed, 25 Jan 2017 16:51:00 +0000
 > 
 >  On Wed, Jan 25, 2017 at 02:15:01PM +0000, Thomas Klausner wrote:
 >   >  Log Message:
 >   >  Remove p5-XML-Sablotron.
 >   >  
 >   >  Obsolete and core dumps.
 >  
 >  If we're going to do that, we should remove the base sablotron also.

 The base sablotron is still used by math/scilab. That needs to be
 fixed first.
  Thomas

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.