Re: [tkined] Memory corruption with TCL 8.0.4 and Scotty 2.1.10 on

Judah Greenblatt (judah@bbt.com)
Wed, 19 May 1999 10:35:56 -0400

Juergen:

I did figure out what was going on here.
It is a variant of the "object goes away while I'm not looking"
problem. The commit binding for fooItem could, under some
circumstances, remove itself from the instance tree.
The commit binding for fooFunc was then called for a
non-existant MIB instance and died. The solution was
to delay the removal until "after idle". Works like a charm.

Is there any particular reason that bindings are called from
the bottom of the instance tree up, instead of from the top
down? There are quite a few times I would want to have the
generic functionality performed before the instance-specific stuff.
Also, it would allow "get" bindings at higher levels in the
MIB tree to create instances at the lower levels before the
existance of those entries was checked.

Juergen Schoenwaelder wrote:
>
> >>>>> Judah Greenblatt writes:
>
> Judah> Symptom:
>
> Judah> I have a binding like: $session bind fooEntry commit {fooFunc
> Judah> fooEntry %i} $session instance fooItem.1.2 myArray(fooItem.1.2)
> Judah> XX
>
> Judah> when the agent receives a set request for MIB entry fooItem.1.2
> Judah> (where fooItem is a child of fooEntry in the mib), fooFunc is
> Judah> called: fooFunc fooEntry xxfooBar fooBletch where "fooBar" and
> Judah> "fooBletch" are other columns in table fooEntry.
>
> Judah> It looks like the varBind for fooItem.1.2 has become corrupted
> Judah> inside scotty at the point that the Scotty internal call to the
> Judah> mib binding substitutes %i.
>
> Judah> This happens repeatable at a certain point in a large test
> Judah> script, but no place else. The only thing I am doing in that
> Judah> test script that is odd is there are a large number of "after
> Judah> idle" events queued up (perhaps 20 or 30).
>
> I have no idea. Please try to come up with a stripped down version of
> a script which triggers this bug. I have doubts that it has anything
> to do with the number of after handlers. But you never know...
>

-- 
Judah Greenblatt	judah@bbt.com     919-405-4716
BroadBand Technologies, Durham, NC
--
!! This message is brought to you via the `tkined & scotty' mailing list.
!! Please do not reply to this message to unsubscribe. To subscribe or
!! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>.
!! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.