[Simulavr-devel] Re: [bug #13680] new MirrorNet in Pin causes memory leak

[Oleg Batrashev]

Hi,

I think this does not eliminates the problem, but makes application more
buggy :(

First this breaks C++ logic, because instance in C++ does not know if it
is on the heap or stack. We cannot assume only one variant.

Second it does not help with memory leak. The problem is in local
variables, assignment operator and copy constructor (the last one is,
possibly, never called in simulavrxx).
1) When local Pin variable is created (during calculations of
analogValue or anything), then Pin desctructor is called, but MirrorNet
isnt destroyed.
2) Pointer is copied when assignment or copy constructor work, so one
instance of MirrorNet may be lost, another may be deleted twice.

After defining my "operator=" and inserting "delete connectedTo" to all
necessary places I solved memory leak problem. I dont like my solution,
because it relies too much on 'speciality' of MirrorNet.

What is my vision of Pin (no final soultion, just thoughts):
Pin has 2 forms:
  real object - end of wire which is connected to some net, port, device
  calculation object - we are only interested in analogValue, ...
values of it when doing calculations

So from this point assignment operator and copy contructor should copy
only analogValue (some other value as well?). Copy constructor must also
initialize other values to 0 (or we get segmentation fault when
deleting). Destructors must also do something. No 'special' objects
inside Pin, instead lets check connectedTo for 0 when using it.

Im still trying to figure out good solution that wont break your
programs. It would be much more easier to do if you provide more TCL
examples or even tests.

Oleg

Klaus Rudolph wrote:

> Update of bug #13680 (project simulavr):
>
>                  Status:                    None => In Progress            
>             Assigned to:                    None => zfrdh                  
>
>    _______________________________________________________
>
> Follow-up Comment #1:
>
> Thanks for your report.
>
> The problem is fixed on my local copy simply by 
> calling delete(this) in the Delete function. As
> protection against unwanted users which could not know
> about this "side effect" I have declared Delete as private
> and make Pin::RegisterNet a friend.
>
> connectedTo is also now a private.
>
> Making a "delete this" call is allways a bit misterious code.
> If you could not agree with this solution lets discuss
> the problem for a better solution.
>