Skip Menu |

This queue is for tickets about the SOAP-Lite CPAN distribution.

Report information
The Basics
Id: 118455
Status: new
Priority: 0/
Queue: SOAP-Lite
People
Owner: Nobody in particular
Requestors: daniel [...] trustnetworks.co.uk
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Fri Oct 21 05:19:52 2016 daniel [...] trustnetworks.co.uk - Ticket created
Subject: SOAP::Lite goes completely bananas when serialising an exception
Date: Fri, 21 Oct 2016 10:19:37 +0100
To: "bug-SOAP-Lite [...] rt.cpan.org" <bug-SOAP-Lite [...] rt.cpan.org>
From: Daniel Beardsmore <daniel [...] trustnetworks.co.uk>
I use my own exception class, which is nothing more than a bog standard blessed hash reference. If such an exception is raised within make_handle's eval, the code at line 2943 in Lite.pm ultimately leads to some kind of infinite loop/recursion that reached nearly 4 GB in a couple of minutes. I've amended the code thus, to resolve the crash. $@ is not actually altered, but the serialisation is now given a plain string to pass back, and it avoids the crash. Modified line 2943 onwards: # DGB 2016-10-21 Module experiences an excruciating death if it tries to serialise an exception object, so let's not do that my $stringified = 'Exception: ' . $@; # died with complex detail return $self->make_fault($SOAP::Constants::FAULT_SERVER, 'Application error' => $stringified); I don't know what's happening, but this method is called endlessly, with $_[1] being given alternately and randomly the stringified exception and some other text it's finding somewhere. sub gen_id { sprintf "%U", $_[1] }
  Fri Oct 21 06:51:41 2016 daniel [...] trustnetworks.co.uk - Correspondence added
Subject: RE: [rt.cpan.org #118455] SOAP::Lite goes completely bananas when serialising an exception
Date: Fri, 21 Oct 2016 11:43:13 +0100
To: "bug-SOAP-Lite [...] rt.cpan.org" <bug-SOAP-Lite [...] rt.cpan.org>
From: Daniel Beardsmore <daniel [...] trustnetworks.co.uk>
Ah, I think I know where it may be going wrong. I just remembered: one of the fields in my exception is a Devel::StackTrace object, and it appears that the crash occurs when serialising one of those, as that will be where the mystery text is coming from (just the path to the script, which I wasn't storing). Off-hand however I don't know what's actually occurring, i.e. what would be required to detect and trap problems with exception objects. However, I am not sure that it's really sensible to try serialising the entire contents of some random exception object you've never seen as you have no idea what's going to be in there. My objects stringify back to the bare error text so that if they're called in a context where you're not able or prepared to process the stack trace data they're carrying, you just get back largely the same message that was thrown originally. As I recall, SOAP::Fault does the same. Detailed error reporting can be handled via logging on the SOAP server machine from the unmodified $@.