Insteon: Delete Orphan Links (Audit) Freezes Up

[krkeegan]

Not a whole lot of details. But Delete Orphan Links (Audit) just froze up on me. I have seen this before and don't know what causes it.

In this most recent event, I scanned all links, scanned a few devices directly, and then performed Delete Orphan Links (Audit). The log shows the following entries:

04/02/2013 11:41:49 Running: PLM AUDIT - delete orphan links
04/02/2013 11:41:49 [Insteon::ALDB_PLM] #### NOW BEGINNING DELETE ORPHAN LINKS ####
04/02/2013 11:41:49 [Insteon::ALDB_i1] Nothing else to do for $f_fm_lt_ma after deleting 0 links

but nothing else. All other commands continue to work, but I cannot perform the delete orphans (audit) without restarting MH.

[krkeegan]

Caught an error this time:

tie_events eval error: Can't use an undefined value as an ARRAY reference at /usr/local/mh3/bin/../lib/Insteon/AllLinkDatabase.pm line 2008, line 11.

Line 2008 of ALD.pm is:
my $num_in_queue = @{$$self{delete_queue}};

[krkeegan]

This appears to occur when reload code is called and then AUDIT Delete Orphans is called thereafter.

[krkeegan]

Ahh, finally found it. Kind of.

I was using "Force Reload Code" rather than "Reload Code" Forced causes the above error, while normal reload does not. This likely has something to do with something being cleared out by forced reload and an init call that is not getting repeated in a forced reload.

To repeat the error:

1. Shutdown MH completely
2. Start MH
3. Run Forced Reload Code
4. Run Audit Delete Orphans
   You will get "Can't use an undefined value as an ARRAY reference" error

Other variations:

1. Shutdown MH completely
2. Start MH
3. Run Audit Delete Orphans
4. Run Forced Reload Code
5. Run Audit Delete Orphans
   This time, only your first device will be mentioned and then Delete Orphans will end without an error.

I am disinclined to track this unique error down at the moment.

[mstovenour]

Kevin,

There was at least one fix that I submitted that affected the save/restore of the aldb data. You might try again after merging in that fix.

Sincerely,

Michael

From: krkeegan [mailto:[email protected]]
Sent: Monday, February 11, 2013 12:18 PM
To: hollie/misterhouse
Subject: Re: [misterhouse] Insteon: Delete Orphan Links (Audit) Freezes Up (#57)

This appears to occur when reload code is called and then AUDIT Delete Orphans is called thereafter.

—
Reply to this email directly or view it on GitHub #57 (comment) .

https://github.com/notifications/beacon/Nvoh7bM6g31WX2NN_lw41fARMyqrboy0NjvPNEeabVf8nn6pk_Z6A6to7M4rD8_I.gif

[krkeegan]

Holy crap, I finally solved this one.

The "Force Reload code" voice command rereads all user code whether the file changed or not. The "Reload code" voice command only rereads that code which has changed.

Whenever the insteon.mht file is reread, each of the objects is recreated and most of the initial startup commands are rerun. The issue arose because the $PLM object was recreated, but the object reference retrieved by BaseObject::active_interface() was not updated. As a result, there were basically two "versions" of the PLM object in memory which would lead to variables being set in the first one but not the second one. When the code later tried to read the variable from the second "version" things would go badly.

The problem came down to a quirk in the code all the way down in the InsteonManager. Previously when adding a BaseInterface it only be set as the active_interface if the active_interface had not been set before. Now whenever a BaseInterface is added, it is set as the active_interface.

So far, I have not seen any adverse effects from my change. The only issue I can see is that having two PLMs defined in MH may lead to issues. So that should be avoided. If anyone knows of a situation in which two would be needed, please let me know.

This obscure bug likely caused a number of issues beyond what I was able to reproduce.

[peloy]

This is fantastic, Kevin! Thanks for chasing this down.

Cheers!

Eloy Paris.-

On 05/23/2013 08:49 PM, Kevin Robert Keegan wrote:

Holy crap, I finally solved this one.

The "Force Reload code" voice command rereads all user code whether the
file changed or not. The "Reload code" voice command only rereads that
code which has changed.

Whenever the insteon.mht file is reread, each of the objects is
recreated and most of the initial startup commands are rerun. The issue
arose because the $PLM object was recreated, but the object reference
retrieved by BaseObject::active_interface() was not updated. As a
result, there were basically two "versions" of the PLM object in memory
which would lead to variables being set in the first one but not the
second one. When the code later tried to read the variable from the
second "version" things would go badly.

The problem came down to a quirk in the code all the way down in the
InsteonManager. Previously when adding a BaseInterface it only be set as
the active_interface if the active_interface had not been set before.
Now whenever a BaseInterface is added, it is set as the active_interface.

So far, I have not seen any adverse effects from my change. The only
issue I can see is that having two PLMs defined in MH may lead to
issues. So that should be avoided. If anyone knows of a situation in
which two would be needed, please let me know.

This obscure bug likely caused a number of issues beyond what I was able
to reproduce.

—
Reply to this email directly or view it on GitHub
#57 (comment).