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: gutteridge@netbsd.org
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: Mon Jan 21 02:28:21 +0000 2019
>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.
>Release-Note:
>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
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home