Matthias or Alex Metcalf, I have a Perl script with one of the functions doing a do...until call that has two commConnect calls inside it (these are going to Serial Tool 1.0.2 while using System 7.5.5). This seems to eat up memory pretty quick. Here is the function: ****************************************************************** ############ # ReceiveData accepts the data from the Tool. It stops when the Tool sends the DONESENDING # command. Also wrote it so that the script closes the connection to the tool when the Tool # hasn't sent anything for 30 seconds (which probably means the Newton hasn't sent anything # to the tool for 30 seconds). ############ sub ReceiveData { my $data; my $alldata; my $startTime =3D time(); my $currentTime =3D $startTime; my $differenceTime; print "Attempting to receive the data...\n"; do { $currentTime =3D time(); &CommConnect'Idle(); $data =3D &CommConnect'Receive(); if ($data) { print $data, "\n"; } # Here for debugging. May have to remove if output is too messy. if ($data) { $startTime =3D $currentTime; } # restart the counter. if (!$data) { $differenceTime =3D $currentTime - $startTime; if ($differenceTime > 15) { print "No data has been sent for $differenceTime seconds. Closing the connection. \n"; &CloseToolConnection; print "alldata is: \n", $alldata, "\n"; print "Aborting the script. The Newton never sent the DONESENDING command!"; exit 0; } } $alldata .=3D $data if $data; } until ($alldata =3D~ /DONESENDING/); print "\n...Finished sending.\n\n"; print "alldata is: \n", $alldata, "\n\n\n"; ModifyData($alldata); } # sub ReceiveData ***********************************************************************= When I run ZoneRanger and the sript at the same time I can watch the Free Memory dissapear, but even more interestingly, I can watch the number of MacPerl handles increasing _very_ quickly. When I use ZoneRanger to look at MacPerl's blocks I have a pattern th= at repeats over and over, which probably means it's the result of the loop. Here is a sample of the pattern: Address Type Size Attr Resource ID Name -----------------------------------------------------------------------= --------0x0156AB80 Handle 0 ... 0x0156ABA0 Free 20 ... 0x0156ABC0 Handle 0 ... 0x0156ABE0 Free 20 ... 0x0156AC00 Handle 0 ... 0x0156AC20 Free 20 ... From this, it looks like a NewHandle is called (or NewPtr?) to make a large handle. That handle is then resized to 20. Next, a NewHandle is called, but then this handle is resized to 0 (and not disposed), then the first handle is freed, leaving a 20 byte free block and a 0 byte handle. Here's another interesting point. This is what one of the free blocks look like: Offset Hex Contents ASCII Contents -----------------------------------------------------------------------= 0x00000000 | 7265 6365 6976 6500 000E 8020 0156 AC50 | receive...=C4 .V=A8P 0x00000010 | 0156 AC90 AB00 0014 0000 0020 001C 01F8 | .V=A8=EA=B4...... .... All the free blocks look like this. 'receive' is one of the calls I make in commConnect. So, where's the problem at? In the Serial Tool? In the MacPerl XFCN adapter? Is there any hope of having this fixed? I'll mail the entire script to anyone that's interested. thanks, rob -- <mailto: "Robert A. Decker" comrade@umich.edu> Programmer Analyst - Health Media Research Lab University of Michigan Comprehensive Cancer Center "Get A Life" quote #8: "Wow. A doctor. Maybe you can help me with another little problem I'm having. What exactly does it mean when you wake up every morning in a pool of your own vomit?" -Chris Elliott