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.
}


Reply via email to