perl-win32-gui-users

[perl-win32-gui-users] The memory leak problem (fixed, I hope ;)

[Sam <sa...@se...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I said I'd report when I know more, so here goes...

The problem isn't with DefWindowProc at all (in fact 
DefWindowProc doesn't do anything except default handling - 
duh!). My apologies for being misleading.

The memory usage in the task manager thingee is useful, but 
inherently misleading. It isn't a cache allocation thing or anything 
like that, again sorry for being misleading.

The problem is with the C-perl interface. The WindowMsgLoop 
needs a good perl start, and end block:
dSP;
ENTER;
SAVETMPS;

....

FREETMPS;
LEAVE;

This is because it calls into the perl interpreter. The Dialog XSUB 
doesn't need those blocks explicitly however because they are 
added by xsubpp. However because the Dialog XSUB pretty much 
never exits (and therefore calls FREETMPS) it accumulates TMPs. 
There are (I believe) two ways to fix this:
1/ make the dialog XSUB return after processing one message, 
and call it from perl like
while( Win32::GUI::Dialog() ) {
}
2/ give the Dialog XSUB an explicit block around the perl interpreter 
calls it makes. I believe that this will work fine, but I haven't tested 
it. I implemented (1) in my copy of win32::GUI.

NB:
It may be necessary to add blocks in other places (in fact I'm sure 
of it), but this is the only problem I am aware of.
I can't create and distribute a patch on work time, but in my own 
time (of which I have very little unfortunately) I will create a patch for 
0.0.502, and send this to Aldo, if he so desires.


-----BEGIN PGP SIGNATURE-----
Version: N/A

iQA/AwUBOlsd7ZsRND2Z+TaWEQLI4ACfT9k/+/Lm84a6GAhfnF8sa91kBGEAoIXP
QULIwerislw19RYsRAihlTY+
=5seU
-----END PGP SIGNATURE-----

Sam Jacobson
R & D Manager / Software Engineer
Selective Communications
Ph +64 9 302 1142
www.selective.co.nz

Re: [perl-win32-gui-users] The memory leak problem (fixed, I hope ;)

[Aldo C. <da...@pe...>]

Sam wrote:
> I said I'd report when I know more, so here goes...
>
> The problem isn't with DefWindowProc at all (in fact 
> DefWindowProc doesn't do anything except default handling - 
> duh!). My apologies for being misleading.

no problem. even checking the obvious is helpful in such
cases :-)

> The memory usage in the task manager thingee is useful, but 
> inherently misleading. It isn't a cache allocation thing or
> anything like that, again sorry for being misleading.
>
> The problem is with the C-perl interface. The WindowMsgLoop
> needs a good perl start, and end block:
> dSP;
> ENTER;
> SAVETMPS;
>
> ....
>
> FREETMPS;
> LEAVE;

unfortunately not. WindowMsgLoop, itself, does not actually
call the Perl interpreter: the various DoEvent_* functions
performs the needed calls, and they all have (SAVE|FREE)TMPS
blocks. I tried, just to give it a try, to make the changes
you suggested to WindowMsgLoop, but nothing changes.

> This is because it calls into the perl interpreter. The Dialog
> XSUB doesn't need those blocks explicitly however because they
> are added by xsubpp. However because the Dialog XSUB pretty much
> never exits (and therefore calls FREETMPS) it accumulates TMPs. 
> There are (I believe) two ways to fix this:
> 1/ make the dialog XSUB return after processing one message, 
> and call it from perl like
> while( Win32::GUI::Dialog() ) {
> }

this is a good hint. unfortunately, it is not a solution.
there is already a one-go Dialog XSUB, which is called
DoEvents. I tried replacing the Dialog() call with this:

1 while ( Win32::GUI::DoEvents != -1 );

and indeed, there is no apparent memory leak!

BUT, the processor is busy at 100% while the Perl
program runs: this is because the while loop, even if
'void', does consume CPU time. too bad :-(

BUT, this is a first approach to a possible solution,
because it seems to isolate the problem in the Dialog()
XSUB. I'll try to debug it and see if I can understand
something more.

> 2/ give the Dialog XSUB an explicit block around the perl
> interpreter calls it makes. I believe that this will work
> fine, but I haven't tested it. I implemented (1) in my copy
> of win32::GUI.

what do you mean by 'interpreter calls' here?

> NB:
> It may be necessary to add blocks in other places (in fact
> I'm sure of it), but this is the only problem I am aware of.
> I can't create and distribute a patch on work time, but in my own
> time (of which I have very little unfortunately) I will create
> a patch for 0.0.502, and send this to Aldo, if he so desires.

please do so if you can :-)


cheers,
Aldo

__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;

Re: [perl-win32-gui-users] The memory leak problem (fixed, I hope ;)

[Aldo C. <da...@pe...>]

Sam wrote:
> 2/ give the Dialog XSUB an explicit block around the perl
> interpreter calls it makes. I believe that this will work fine,
> but I haven't tested it.

you got it Sam!!!!!

I added ENTER/SAVETMPS + FREETMPS/LEAVE inside the Dialog()
loop (while (stayhere)) and it works like a charm now.
there is a small memory increase, but it's completely
acceptable (some k's when you do something in the window
at startup, click buttons, etc. but nothing when you simply
move the mouse around).

I think that the problem is in the magical stuff I've
added to support windows-as-hashes (eg. the TIEHASH stuff
that permits $Window->{-text}); since doing hv_fetch()
on a tied hash really calls the Perl sub FETCH on that
object, TMPs are really created (it seems).
hv_fetch alone would have not required a (SAVE|FREE)TMPS
block, but the magic behind it apparently does.

I will release a new version very soon with this nasty,
nasty, nasty bug finally *fixed* forever :-)

cheers,
Aldo

__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;

Re: [perl-win32-gui-users] The memory leak problem (fixed, I hope ;)

[Sam <sa...@se...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Sam wrote:
> > I said I'd report when I know more, so here goes...
> >
> > The problem isn't with DefWindowProc at all (in fact 
> > DefWindowProc doesn't do anything except default handling - 
> > duh!). My apologies for being misleading.
> 
> no problem. even checking the obvious is helpful in such
> cases :-)
> 
> > The memory usage in the task manager thingee is useful, but 
> > inherently misleading. It isn't a cache allocation thing or
> > anything like that, again sorry for being misleading.
> >
> > The problem is with the C-perl interface. The WindowMsgLoop
> > needs a good perl start, and end block:
> > dSP;
> > ENTER;
> > SAVETMPS;
> >
> > ....
> >
> > FREETMPS;
> > LEAVE;
> 
> unfortunately not. WindowMsgLoop, itself, does not actually
> call the Perl interpreter: the various DoEvent_* functions
> performs the needed calls, and they all have (SAVE|FREE)TMPS
> blocks. I tried, just to give it a try, to make the changes
> you suggested to WindowMsgLoop, but nothing changes.
> 
> > This is because it calls into the perl interpreter. The Dialog
> > XSUB doesn't need those blocks explicitly however because they
> > are added by xsubpp. However because the Dialog XSUB pretty much
> > never exits (and therefore calls FREETMPS) it accumulates TMPs. 
> > There are (I believe) two ways to fix this:
> > 1/ make the dialog XSUB return after processing one message, 
> > and call it from perl like
> > while( Win32::GUI::Dialog() ) {
> > }
> 
> this is a good hint. unfortunately, it is not a solution.
> there is already a one-go Dialog XSUB, which is called
> DoEvents. I tried replacing the Dialog() call with this:
> 
> 1 while ( Win32::GUI::DoEvents != -1 );
> 
> and indeed, there is no apparent memory leak!
> 
> BUT, the processor is busy at 100% while the Perl
> program runs: this is because the while loop, even if
> 'void', does consume CPU time. too bad :-(
That's because it uses PeekMessage, which returns immediately 
regardless of whether or not there are any messages waiting.

> BUT, this is a first approach to a possible solution,
> because it seems to isolate the problem in the Dialog()
> XSUB. I'll try to debug it and see if I can understand
> something more.
> 
> > 2/ give the Dialog XSUB an explicit block around the perl
> > interpreter calls it makes. I believe that this will work
> > fine, but I haven't tested it. I implemented (1) in my copy
> > of win32::GUI.
> 
> what do you mean by 'interpreter calls' here?
> 
> > NB:
> > It may be necessary to add blocks in other places (in fact
> > I'm sure of it), but this is the only problem I am aware of.
> > I can't create and distribute a patch on work time, but in my own
> > time (of which I have very little unfortunately) I will create
> > a patch for 0.0.502, and send this to Aldo, if he so desires.
> 
> please do so if you can :-)
> 
> 
> cheers,
> Aldo
> 
> __END__
> $_=q,just perl,,s, , another ,,s,$, hacker,,print;
> 
> 
> 
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> 



-----BEGIN PGP SIGNATURE-----
Version: N/A

iQA/AwUBOlwquJsRND2Z+TaWEQJEPwCeLjIAiDb1DHzs8woIpcIpaV7u3JEAnR4G
38Dh5N9HX44Guqr612WBFf6Y
=mvOy
-----END PGP SIGNATURE-----

Sam Jacobson
R & D Manager / Software Engineer
Selective Communications
Ph +64 9 302 1142
www.selective.co.nz

RE: [perl-win32-gui-users] The memory leak problem (fixed, I hope ;)

[Jake S. <js...@gr...>]

Well done Sam!!!!!

Well done Aldo!!!