This queue is for tickets about the Text-CSV_XS CPAN distribution.

Report information
The Basics
Id:
85810
Status:
resolved
Priority:
Low/Low
Queue:

People
Owner:
Nobody in particular
Requestors:
GMCHARLT [...] cpan.org
Cc:
AdminCc:

BugTracker
Severity:
Normal
Broken in:
0.98
Fixed in:
(no value)



Subject: error_input() segfaults after successful parse
The error_input() method segfaults after a (successful) parse(). Here is some code that invokes the segfault: use Text::CSV_XS; my $csv = Text::CSV_XS->new ({ binary => 1 }); my $str = q{"abc","def"}; $csv->parse($str); my $bad_input = $csv->error_input(); # segfaults here If one tries this with version 0.96 of Text::CSV_XS, the test program doesn't segfault; instead, $bad_input is undefined. The documentation implies but doesn't (to my reading) explicitly state that error_input() should be called only if parse() returns an error status. It would be better if error_input() either reverted to its original behavior or if it threw an exception when called after a successful parse, as that could be caught by an eval block while a segfault simply terminates the script. Thanks for your consideration.
Subject: Re: [rt.cpan.org #85810] error_input() segfaults after successful parse
Date: Mon, 3 Jun 2013 08:08:18 +0200
To: bug-Text-CSV_XS@rt.cpan.org
From: "H.Merijn Brand" <h.m.brand@xs4all.nl>
On Sun, 2 Jun 2013 20:28:20 -0400, "Galen Charlton via RT" <bug-Text-CSV_XS@rt.cpan.org> wrote:
Show quoted text
> The error_input () method segfaults after a (successful) parse (). > Here is some code that invokes the segfault:
I probably need more information about your perl version and your system architecture, as I tried that snippet on a plethora of perl versions on different architectures and did not get a segfault.
Show quoted text
> If one tries this with version 0.96 of Text::CSV_XS, the test > program doesn't segfault; instead, $bad_input is undefined.
The documentation makes no assumption on what the function should return when no error occurred. The reason is that I don't want to take action on success, as that will slowdown parsing. The intent is to only return some documented value on failure. core-dumps however are not acceptable, but I cannot reproduce.
Show quoted text
> The documentation implies but doesn't (to my reading) explicitly > state that error_input () should be called only if parse () returns > an error status.
I could make the docs clearer, but I still would not like core-dumps. For now, following the docs, and my mindset, *any* value would do as return value after success. C<undef> would be the most logical value of choice though, but I won't if that costs parsing speed.
Show quoted text
> It would be better if error_input () either reverted to its original > behavior or if it threw an exception when called after a successful > parse, as that could be caught by an eval block while a segfault > simply terminates the script.
I feel that would be as overdesigning for failure. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Subject: error_input () segfaults after successful parse
Found, fixed and pushed. Now testing, will release asap.
On Mon Jun 03 08:49:28 2013, HMBRAND wrote:
Show quoted text
> Found, fixed and pushed. > Now testing, will release asap.
Thank you very much.


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.