Wx::Font->new($gl_cfg->{client_point_size}, wxMODERN, wxFONTSTYLE_ITALIC, wxFONTWEIGHT_BOLD, 0, $gl_cfg->{client_font})

620 bytes doesn't seem like a lot for a new font.

Is it really necessary to create a new font each time? Couldn't you create the font once and reference it when you need it?

Ditto other things.

Hi BrowserUK,

Thanks for that. A sensible suggestion. I just did that and made a global replace. I also moved the Wx::Font line before the rest of the code, like this:

    my $loc_font_wx=Wx::Font->new($gl_cfg->{client_point_size}, wxMODE
+RN, wxFONTSTYLE_ITALIC, wxFONTWEIGHT_BOLD, 0, $gl_cfg->{client_font})
+;
    $mu->record('after i_Booking set focus');
    
#     Referring Dr details from Dr file
    $booking_dlg->{Ctl_Booking_Referring_Doctor_Lbl} = Wx::StaticText-
+>new($booking_dlg->{booking_main}, wxID_ANY, __t('Referring Doctor'),
+ wxDefaultPosition, wxDefaultSize, );
    
    $mu->record('before i_Booking i_staticText 1');
    
    $booking_dlg->{Ctl_Booking_Referring_Doctor_Txt} = i_staticText->n
+ew($booking_dlg->{booking_main}, wxID_ANY, "", wxDefaultPosition, wxD
+efaultSize, );
    $mu->record('after i_Booking i_staticText 1');
    $booking_dlg->{Ctl_Booking_Referring_Doctor_Txt}->SetFont($loc_fon
+t_wx);
    $mu->record('before i_Booking Ctl_Booking_Referring_Doctor_Ref_4_L
+bl');
    $booking_dlg->{Ctl_Booking_Referring_Doctor_Ref_4_Lbl} = Wx::Stati
+cText->new($booking_dlg->{booking_main}, wxID_ANY, __t("Ref 4"), wxDe
+faultPosition, wxDefaultSize, );
    $mu->record('before i_Booking i_staticText 2');
    $booking_dlg->{Ctl_Booking_Referring_Doctor_Ref_4_Txt} = i_staticT
+ext->new($booking_dlg->{booking_main}, wxID_ANY, "", wxDefaultPositio
+n, __xy_size(100), );
    $mu->record('after i_Booking i_staticText 2');
    $booking_dlg->{Ctl_Booking_Referring_Doctor_Ref_4_Txt}->SetFont($l
+oc_font_wx);
[download]

The output is unchanged:

     0  773984 (     0)  193264 (     0)  43436 (     0)      8 (     
+0)  368884 (     0) after i_Booking set focus
     0  773984 (     0)  193264 (     0)  43436 (     0)      8 (     
+0)  368884 (     0) before i_Booking i_staticText 1
     0  773984 (     0)  193264 (     0)  43436 (     0)      8 (     
+0)  368884 (     0) after i_Booking i_staticText 1
     0  774604 (   620)  193264 (     0)  43436 (     0)      8 (     
+0)  368884 (     0) before i_Booking Ctl_Booking_Referring_Doctor_Ref
+_4_Lbl
[download]

But even so, the variable should be destroyed when it moves out of scope and it is not, so I suspect some sort of circular reference. I just can't see it.

Steve.

But even so, the variable should be destroyed when it moves out of scope and it is not, so I suspect some sort of circular reference. I just can't see it.

If $booking_dlg->{booking_main} contains a reference to $booking_dlg? Then this is a circular reference:

$booking_dlg->{Ctl_Booking_Referring_Doctor_Txt} = i_staticText->new($
+booking_dlg->{booking_main}
[download]

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this

In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

Is there any difference between Wx::StaticText->new(...) and i_staticText->new(...) ?

Hi Richard,

Yes, Wx::StaticText->new(...) is the standard call, but on Linux you cannot set the background attributes.

i_staticText->new(...) is based on Wx::Panel, to give it a background and then Wx::StaticText->new(...) is within the panel. That way I can adjust the background attributes like background colour and length of field.

Regards

Steve

What convinced you the problem has to be a memory leak, as opposed to memory corruption? Could you try valgrind with --free-fill and --malloc-fill?

Did you run it under gdb to see where and how it faults? A SEGV could be something as simple as exceeding stack ulimit.

Well, thanks for asking that question. It made me think. I guessed it might be a leak because the memory being utilised seemed to be increasing the longer I ran it, but in an unpredictable way.

However, Valgrind gives the following, but it doesn't particularly seem to depend on any segment of code:

==2576== LEAK SUMMARY:
==2576==    definitely lost: 731,689 bytes in 54,909 blocks
==2576==    indirectly lost: 68,896 bytes in 2,326 blocks
==2576==      possibly lost: 37,769,458 bytes in 52,844 blocks
==2576==    still reachable: 78,109,700 bytes in 547,738 blocks
==2576==         suppressed: 0 bytes in 0 blocks
==2576== Reachable blocks (those to which a pointer was found) are not
+ shown.
==2576== To see them, rerun with: --leak-check=full --show-leak-kinds=
+all
==2576== 
==2576== For counts of detected and suppressed errors, rerun with: -v
==2576== ERROR SUMMARY: 2610 errors from 2610 contexts (suppressed: 1 
+from 1)
image@iExam_SD_0003:~/Documents/Endoscopia$
[download]

as it gives a similar dump to this even when I do ctrl-c immediately on start-up.

Regards

Steve