[Gambas-user] debugging a (apparent) memory leak

[Tobias Boege]

On Wed, 30 Oct 2013, Kevin Fishburne wrote:
> On 10/28/2013 10:36 PM, Beno?t Minisini wrote:
> > Le 29/10/2013 03:27, Beno?t Minisini a ?crit :
> >> Le 29/10/2013 02:20, Kevin Fishburne a ?crit :
> >>> I don't think it's always been like this, but when I sometimes forget to
> >>> close the server app running on my physical server and it runs for a few
> >>> days I notice gb3 is using all 8 GB of system RAM and several GB of the
> >>> swap partition. There's nothing in the app (that I know of) that should
> >>> ever be using that much memory, so it sounds like a memory leak.
> >>>
> >>> Is there a way, other than manually following the logic of the entire
> >>> execution sequence, to identify what part of the code is continually
> >>> sucking up more and more RAM?
> >>>
> >>> Also, other than the infamous GOSUB without a corresponding RETURN, what
> >>> types of declarations or code logic should I look for if I do scan
> >>> through the codebase? Red flags, in other words.
> >>>
> >> If you have a main loop somewhere, you can count the number of object
> >> allocations at each loop, by using the Class.Count property:
> >>
> >> Dim hClass As Class
> >> For Each hClass In Classes
> >>      Print hClass.Name;;hClass.Count
> >> Next
> >>
> >> Then you can see which kind of object allocation grows indefinitely.
> >>
> > Another possibility would be an array whose size grows indefinitely too,
> > but the last method won't allow you to detect it.
> >
> 
> I came up with this code to give a sorted, real-time display of 
> objects/classes in the "main loop":
> 
> ---
> 
>    ' General declarations.
>    Dim hClass As Class
>    Dim DebugFile As File
> 
>    ' Debug memory leaks.
>    If Rnd(0, 1000) < 5 Then  ' Shitty timer requiring no variable.
>      If Not Exist(System.User.Home & "/classes.sorted") Then Shell 
> "konsole -e watch \"cat " & System.User.Home & "/classes.sorted\""
>      DebugFile = Open System.User.Home & "/classes" For Write Create
>      For Each hClass In Classes
>        Write #DebugFile, hClass.Count & " " & hClass.Name & gb.CrLf
>      Next
>      Close #DebugFile
>      Shell "sort -g -r " & System.User.Home & "/classes > " & 
> System.User.Home & "/classes.sorted"
>    Endif
> 
> ---
> 
> The results are in, and the server continually increments a class called 
> "Process". The only thing in the codebase that uses that word is this 
> declaration:
> 
> Public PadDevice As Process ' Device to accept gamepad input.
> 
> The client sets this up with:
> 
> PadDevice = Exec ["cat", "/dev/input/js0"] For Read As "Gamepad"
> 
> [...]
>
> I've checked (set breakpoints at all references) and only the client 
> The good news is that I've found an object incrementing indefinitely on 
> the server, confirming my suspicion that there is in fact a memory leak.
> 

Well, keep in mind that you use Shell also to send your statistics to
classes.sorted - in your main *loop*! Even if you are not grabbing the
Process object from the Shell instruction, it gets created. CMIIW, Benoit.

Maybe you can rewrite the code so that:
 - you start a Konsole once (you already do that) but have it monitor
   some FIFO and sort the data coming from that FIFO;
 - open a FIFO and write to it from the Gambas program instead of using
   Shell to sort the lines.

This way you don't create new objects regularly just because you are
printing your statistics.

I have attached a small project which implements this idea. The only
interesting thing in there is the shell script because you have to start
multiple sort processes there to get your output "live". I don't know how
portable the script is to shells other than bash...

Hope this can help you.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: konsole-sort-blocks-0.0.1.tar.gz
Type: application/octet-stream
Size: 5582 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20131031/b4c61634/attachment.obj>