#42 Accessinng $RichEdit from its -on* event crashes perl

closed-fixed
Robert May
None
1
2006-10-15
2005-07-22
Dan Dascalescu
No

Given some code along the lines of:

my $re = $w->AddRichEdit( ... );

$re->Change(
-onMouseMove => sub {
my $text = $re->Text;
return 1;
},
);

perl 5.8.4, 5.8.6 and 5.8.7 will crash when the main
window is closed. If you replace AddRichEdit with
AddTextfield, or '$re->Text' with 'shift->Text' everything
will be OK.

Hope that helps,
Dan Dascalescu

Discussion

  • Dan Dascalescu
    Dan Dascalescu
    2005-07-22

    Code to reproduce the bug

     
    Attachments
  • Robert May
    Robert May
    2005-07-28

    Logged In: YES
    user_id=674651

    What version of Win32::GUI? I believe that this was fixed
    in V1.02.

     
  • Robert May
    Robert May
    2005-07-28

    • priority: 5 --> 1
     
  • Dan Dascalescu
    Dan Dascalescu
    2005-07-30

    Logged In: YES
    user_id=1092359

    I tried to build the latest version from CVS so I checked out
    Win32-GUI from CVS at 5:14 AM UTC and tried to build it
    (nmake all) but it failed with the following error

    LINK : fatal error LNK1181: cannot open input file "oldnames.
    lib"
    NMAKE : fatal error U1077: 'C:\WINNT\system32\cmd.exe' :
    return code '0x49d'

    So I used the PPM version, which is "Version: 1.02 (10 July
    2005)"

     
  • Robert May
    Robert May
    2005-08-04

    • priority: 1 --> 5
     
  • Robert May
    Robert May
    2005-12-02

    • priority: 5 --> 1
    • assigned_to: nobody --> robertemay
    • status: open --> open-fixed
     
  • Robert May
    Robert May
    2005-12-02

    Logged In: YES
    user_id=674651

    I beleive that I've found the root cause of this (and many
    other errors/warnings on program termination). It was
    possible in this scenario for the code to try to free the
    'perlud' data twice, with the second sweep happening in the
    *middle* of the first sweep. The second sweep would then
    access memory that had already been partially freed. A
    simple change to the PERUD_FREE macro ensures that the
    second sweep finds a NULL pointer, and does not try to
    access the already freed memory.

    Fingers crossed that I haven't broken anyhing else.

    Fix will be in CVS when I next committ (a couple of days
    probably), and will amke it into the V1.04 release.

    Regards,
    Rob.

     
  • Robert May
    Robert May
    2006-10-15

    • status: open-fixed --> closed-fixed