Skip Menu |

This queue is for tickets about the Class-Accessor-Grouped CPAN distribution.

Report information
The Basics
Id: 63459
Status: resolved
Priority: 0/
Queue: Class-Accessor-Grouped

People
Owner: Nobody in particular
Requestors: TJC [...] cpan.org
toby.corkindale [...] strategicdata.com.au
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.10000
Fixed in: 0.10002



Subject: CAG relies upon C:XSA, which is unstable
I gather you've already seen some issues with Class::XSAccessor on Win32, but I'm seeing segfaults from it on Linux as well, not even with particularly much load, under perl 5.12.2. Your docs mention potential instability on win32+mod_perl, but I worry that the instability crosses over into Linux territory as well. Of course my issues are yet to be confirmed, but I'll link the other bugreport to here. I figure that if my crashes can be replicated and confirmed, then the concerns should be mentioned in the docs here too. And then maybe the default value for CAG_USE_XS should be "disabled"?
Subject: Re: [rt.cpan.org #63459] CAG relies upon C:XSA, which is unstable
Date: Tue, 30 Nov 2010 03:28:09 -0500
To: Toby C via RT <bug-Class-Accessor-Grouped [...] rt.cpan.org>
From: Rafael Kitover <rkitover [...] cpan.org>
We'll discuss it, thank you for the report. If it is possible, please reproduce the segfault using Class::XSAccessor alone and follow up with the author of that module. On Mon, Nov 29, 2010 at 09:40:17PM -0500, Toby C via RT wrote: Show quoted text
> Mon Nov 29 21:40:16 2010: Request 63459 was acted upon. > Transaction: Ticket created by TJC > Queue: Class-Accessor-Grouped > Subject: CAG relies upon C:XSA, which is unstable > Broken in: 0.10000 > Severity: Normal > Owner: Nobody > Requestors: TJC@cpan.org, toby.corkindale@strategicdata.com.au > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=63459 > > > > I gather you've already seen some issues with Class::XSAccessor on Win32, > but I'm seeing segfaults from it on Linux as well, not even with > particularly much load, under perl 5.12.2. > > Your docs mention potential instability on win32+mod_perl, but I worry > that the instability crosses over into Linux territory as well. Of course > my issues are yet to be confirmed, but I'll link the other bugreport to > here. > I figure that if my crashes can be replicated and confirmed, then the > concerns should be mentioned in the docs here too. > > And then maybe the default value for CAG_USE_XS should be "disabled"?
On Mon Nov 29 21:40:16 2010, TJC wrote: Show quoted text
> I gather you've already seen some issues with Class::XSAccessor on Win32, > but I'm seeing segfaults from it on Linux as well, not even with > particularly much load, under perl 5.12.2. > > Your docs mention potential instability on win32+mod_perl, but I worry > that the instability crosses over into Linux territory as well. Of course > my issues are yet to be confirmed, but I'll link the other bugreport to > here. > I figure that if my crashes can be replicated and confirmed, then the > concerns should be mentioned in the docs here too.
You are the first one to report linux-based crashes, so as Rafael said we need more info. Show quoted text
> And then maybe the default value for CAG_USE_XS should be "disabled"?
The author of Class::XSAccessor is one of the most responsive ones I know, and will fix any bug brought to his attention. A lot of work went into making C::XSA optional-and-on-by-default, we are not planning on changing it until C::XSA is demonstrated to be a real problem. So - reproducing test please
On Tue Nov 30 06:22:03 2010, RIBASUSHI wrote: Show quoted text
> On Mon Nov 29 21:40:16 2010, TJC wrote:
> > I gather you've already seen some issues with Class::XSAccessor on Win32, > > but I'm seeing segfaults from it on Linux as well, not even with > > particularly much load, under perl 5.12.2. > > > > Your docs mention potential instability on win32+mod_perl, but I worry > > that the instability crosses over into Linux territory as well. Of course > > my issues are yet to be confirmed, but I'll link the other bugreport to > > here. > > I figure that if my crashes can be replicated and confirmed, then the > > concerns should be mentioned in the docs here too.
> > You are the first one to report linux-based crashes, so as Rafael said > we need more info. >
> > And then maybe the default value for CAG_USE_XS should be "disabled"?
> > The author of Class::XSAccessor is one of the most responsive ones I > know, and will fix any bug brought to his attention. A lot of work went > into making C::XSA optional-and-on-by-default, we are not planning on > changing it until C::XSA is demonstrated to be a real problem. > > So - reproducing test please
I understand. I did say above that "my issues are yet to be confirmed".. I will work to create a reproducible test case. (See other bug that's linked as dependency) I can currently reproduce the bug every time, but only in a certain chunk of code. Memory allocation errors are tricky to isolate. In a sufficiently simple test case the glitchy bit of memory access might not touch anything else important enough to cause a crash. I think it's worth raising the issue, as then if other people are also hitting the issue, but aren't sure if they're imagining it too, then we can see if there's a pattern. Anyway, I'll keep you posted with developments as they occur; for the time being I've been running with CAG_USE_XS=0, which in my case stops the segfaults. I'm glad you thought to add that option. Cheers, Toby
On Tue Nov 30 07:05:22 2010, TJC wrote: Show quoted text
> I can currently reproduce the bug every time, but only in a certain > chunk of code. Memory > allocation errors are tricky to isolate. In a sufficiently simple test > case the glitchy bit of > memory access might not touch anything else important enough to cause > a crash.
Yes, but such problems are very easy to reduce if you start with a known always-failing case (which you already have). What is your environment? Are there threads/forks? Are running under some shady persistence like mod_perl? Which perl version? Any non-standard patches? Also is the app which fails an open source one? Because then all I need is a failcase against the big thing with instructions how to reproduce and I should be able to reduce it for Steffen.
On Tue Nov 30 07:24:06 2010, RIBASUSHI wrote: Show quoted text
> On Tue Nov 30 07:05:22 2010, TJC wrote:
> > I can currently reproduce the bug every time, but only in a certain > > chunk of code. Memory > > allocation errors are tricky to isolate. In a sufficiently simple test > > case the glitchy bit of > > memory access might not touch anything else important enough to cause > > a crash.
> > Yes, but such problems are very easy to reduce if you start with a known > always-failing case (which you already have). What is your environment? > Are there threads/forks? Are running under some shady persistence like > mod_perl? Which perl version? Any non-standard patches? > > Also is the app which fails an open source one? Because then all I need > is a failcase against the big thing with instructions how to reproduce > and I should be able to reduce it for Steffen.
Thanks Peter. I did manage to find a test case that failed in an open-source project and get some stack traces, and from there Steffen has been able to reproduce the crash himself. I'm impressed at the speed he's been able to work on it, and I hope a solution is equally quickly forthcoming. Cheers, Toby
On Tue Nov 30 19:41:34 2010, TJC wrote: Show quoted text
> I'm impressed at the speed he's been able to work on it, and I hope a > solution is equally > quickly forthcoming. >
Hehe, when I say he is responsive - I did mean responsive. I want to make sure that you are happy with C::XSA 1.10, so I can release a new CAG which requires this version as a minimum.
On Thu Dec 02 06:02:19 2010, RIBASUSHI wrote: Show quoted text
> On Tue Nov 30 19:41:34 2010, TJC wrote:
> > I'm impressed at the speed he's been able to work on it, and I hope
a Show quoted text
> > solution is equally > > quickly forthcoming. > >
> > Hehe, when I say he is responsive - I did mean responsive. I want to > make sure that you are happy with C::XSA 1.10, so I can release a new > CAG which requires this version as a minimum.
It looks like 1.10 is good for us. I'm mildly worried that there's still a definite memory leak - but it only occurs in corner cases that don't effect us, and probably not many other people either. (If you spawn and reap embedded Perl interpreters frequently) cheers, Toby
0.10002 requires the latest Class::XSAccessor before using it, which essentially fixes this problem. Please make sure to upgrade CAG as it fixes another nasty bug that slipped in. Cheers!