Fri Feb 03 04:29:39 2012: Request 74652 was acted upon.
Transaction: Correspondence added by mark.doot...@znix.com
Queue: Wx
Subject: Re: [rt.cpan.org #74652] Segfault on Wx::PlThreadEvent destruction
Broken in: 0.9903
Severity: (no value)
Owner: Nobody
Requestors: ad...@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=74652 >
Hi,
For thread events you must use Wx::PostEvent
Wx::PostEvent(
$CONDUIT,
Wx::PlThreadEvent->new( -1, $SIGNAL, $_[1] )
);
I think this may be your problem as Wx::PostEvent employs a 'thread
safe' stash for the thread data by using threads::shared. The error you
are seeing is probably the result of not using Wx::PostEvent.
Regards
Mark
On 03/02/2012 08:33, Adam Kennedy via RT wrote:
> Fri Feb 03 03:33:41 2012: Request 74652 was acted upon.
> Transaction: Ticket created by ADAMK
> Queue: Wx
> Subject: Segfault on Wx::PlThreadEvent destruction
> Broken in: 0.9903
> Severity: (no value)
> Owner: Nobody
> Requestors: ad...@cpan.org
> Status: new
> Ticket<URL: https://rt.cpan.org/Ticket/Display.html?id=74652>
>
>
> The following code is from Padre::Wx::Role::Conduit.
>
> It seems to show that on rare occasions thread events can explode when
> they fall out of scope and are destroyed (at least, that's my assumption
> since the $_[1] param is always a plain string).
>
> It does not happen often, but the Find in Files background thread in
> Padre produces hundreds or thousands of thread events.
>
> sub signal {
> if ($CONDUIT) {
> $CONDUIT->AddPendingEvent(
> Wx::PlThreadEvent->new( -1, $SIGNAL, $_[1] )
> );
> }
> return 1;
>
> # NOTE: Crashes like the following have been observed.
> #
> # Free to wrong pool 8d60100 not 963e10 at
> # C:/strawberry/perl/site/lib/Padre/Wx/Role/Conduit.pm line 153.
> # Attempt to free unreferenced scalar: SV 0x2099354,
> # Perl interpreter: 0x4f2c2b4
> # at C:/strawberry/perl/site/lib/Padre/Wx/Role/Conduit.pm line 153.
> #
> # It appears that the destruction of the Wx::PlThreadEvent can
> # cause segfaults in some situations.
> }
>
