 |
GeneralStonewall
Magician
Joined: 02 Feb 2004
Posts: 364
Location: USA
|
 Posted: Sat Sep 26, 2009 8:59 am
[3.10a] BUG: Issue with multiple sessions & Identical IDs
|
I'm having issues running two sessions at once and I can't seem to fix it. I've tried completely uninstalling and reinstalling cmud, deleting my session layouts, and starting just with the exported xml files.
I start from CMud and open up my session; It connects. I go to the sessions drop-down menu and open up another; It connects. But when I go to my first session, open up the settings, and select the window for that session, it has the package for my new session listed under 'List of packages enabled for this window.' That's just the first thing that I've noticed is odd. Now I start having issues with trigger / button IDs, I can't enable/disable a portion of my triggers with #t+/t- and I can't use %btncol on some of my buttons. This is happening in both sessions, but only with the triggers/buttons that are in both sessions. What's interesting though is the buttons/triggers that aren't responding are the triggers/buttons that I can't reference by ID in one session are the ones that I can in the other and vice-versa.
EDIT:
I've managed to duplicate this, the problem doesn't seem to effect triggers in the root class. Create 2 sessions, open both, and then import the following xml. Open up the settings and use the trigsoff and trigson aliases. What "should" happens is that only about half of them will respond in the first session, and the other half in the second session.
| Code: |
<?xml version="1.0" encoding="ISO-8859-1" ?>
<cmud>
<class name="folder">
<trigger name="trig1" priority="10"/>
<trigger name="trig2" priority="10"/>
<trigger name="trig3" priority="10"/>
<trigger name="trig4" priority="10"/>
<trigger name="trig5" priority="10"/>
<trigger name="trig6" priority="10"/>
<trigger name="trig7" priority="10"/>
<trigger name="trig8" priority="10"/>
<trigger name="trig9" priority="10"/>
<trigger name="trig10" priority="10"/>
<trigger name="trig11" priority="10"/>
<trigger name="trig12" priority="10"/>
<trigger name="trig13" priority="10"/>
<trigger name="trig14" priority="10"/>
<trigger name="trig15" priority="10"/>
<trigger name="trig16" priority="10"/>
<trigger name="trig17" priority="10"/>
<trigger name="trig18" priority="10"/>
<trigger name="trig19" priority="10"/>
<trigger name="trig20" priority="10"/>
<alias name="trigson">
<value>#t+ trig1
#t+ trig2
#t+ trig3
#t+ trig4
#t+ trig5
#t+ trig6
#t+ trig7
#t+ trig8
#t+ trig9
#t+ trig10
#t+ trig11
#t+ trig12
#t+ trig13
#t+ trig14
#t+ trig15
#t+ trig16
#t+ trig17
#t+ trig18
#t+ trig19
#t+ trig20</value>
</alias>
<alias name="trigsoff">
<value>#t- trig1
#t- trig2
#t- trig3
#t- trig4
#t- trig5
#t- trig6
#t- trig7
#t- trig8
#t- trig9
#t- trig10
#t- trig11
#t- trig12
#t- trig13
#t- trig14
#t- trig15
#t- trig16
#t- trig17
#t- trig18
#t- trig19
#t- trig20</value>
</alias>
</class>
</cmud> |
|
|
|
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Mon Sep 28, 2009 12:02 am
|
Did you remove the second session from the first's list of enabled packages? Having the second session enabled in the first would cause the problem you are seeing.
|
|
|
|
|
GeneralStonewall
Magician
Joined: 02 Feb 2004
Posts: 364
Location: USA
|
Posted: Mon Sep 28, 2009 3:40 am
|
Yes, I did. It's not that it's effecting triggers in other packages, some just don't work by ID, period. Test it.
|
|
|
|
|
Tech
GURU
Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA
|
Posted: Mon Sep 28, 2009 2:23 pm
|
Confirmed that there is a bug here.
I think the scoping rules dictate that the current session should be exhausted before checking the other session for the variable reference. I also wouldn't expect the the partial processing that we see here. |
|
_________________
Asati di tempari! |
 |
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Sep 28, 2009 4:03 pm
|
Wow, that's one of the weirdest bugs I have ever seen! I have no idea what is causing this, but it seems pretty serious to me. I verified that it works fine with just one session, but not with two sessions.
But this tells me that there is some sort of serious bug in doing a lookup of settings by ID name somewhere.
At least I was able to reproduce this with your example code. Thanks very much for posting the specific script. I should be able to use that to track down the problem. I'll get this fixed for the next beta version. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Oct 20, 2009 9:15 pm
|
OK, this bug was NASTY!
There was a bug in the low-level database index search routine that was not looking at the proper database field when creating a list of matching names.
When CMUD searches for a generic name, like "#T- trig1" it looks in a database index for all records of the name "trig1" within any package. To do this, CMUD calls the database "FindKey" routine to return the *first* matching result. Then it looks in adjacent records in the index to find the rest of the records with the same name (they are adjacent in the index because the index is sorted by the IDName field).
However, when looking for matching adjacent entries, CMUD was comparing to the FULL NAME field instead of the ID NAME field. In the above example, the Full Name (Pattern) of each trigger is empty. So it was only returning the first located record in the database. Depending upon how the database hashes it's records, this first record could be in the "test1" package, or it could be in the "test2" package...it's random.
I fixed this so that it properly compares the IDName and the FullName to the correct values and now it works fine.
This bug would only happen if the matching records were stored within a subfolder of the package. This is because CMUD has a fast hash table of settings within a specific class folder, and only when this fast hash fails (setting within a subfolder), then it calls the more generic database search routine mentioned above.
This bug does not require separate *packages*. This same bug could occur if the same trigger ID was stored within a different folder within the same package too. And it only effected settings where the ID Name and the Full Name can be different (triggers, buttons, events).
That makes the bug a bit obscure, which is why it's not effecting everybody. But it's also so obscure that it could be the cause of all sorts of mysterious problems people might be having with lots of duplicate ID names for their settings.
Anyway, it's fixed now for v3.11. |
|
|
|
|
Tech
GURU
Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA
|
Posted: Wed Oct 21, 2009 3:31 am
|
Dang Zugg... it looks like you went on a bug fixing tear today!!! Keep up the awesome work. We thank you.
|
|
_________________
Asati di tempari! |
|
|
|
|
|
|
