2010-01-29 6 views
5

Nous avons rencontré un problème sérieux avec CF9 dans lequel les valeurs de certaines clés de structure peuvent être référencées par d'autres clés, même si ces autres clés ne sont jamais définies. Voir les exemples suivants:Bug dans CF9: valeurs pour les clés struct uniques référencées et écrasées par d'autres clés

Éditer: On dirait que ce n'est pas quelque chose que nos serveurs ont mangé. C'est le ticket de bug d'Adobe 81884: http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#bugId=81884.

Edit: Comme cela a été souligné, Adobe mis la solution: http://kb2.adobe.com/cps/825/cpsid_82547.html

Le résumé de correctif note qu'ils comparaient les valeurs de hachage des noms de variables au lieu de la valeur littérale, pour la vitesse. Je ne sais pas comment cela pourrait accélérer quelque chose, mais la possibilité de collisions de noms (en particulier sur les noms plus courts) aurait dû être évidente. Au moins, ils étaient assez rapides à corriger.

<cfset a = { AO = "foo" } /> 
<cfset b = { AO = "foo", B0 = "bar" } /> 

<cfoutput> 
The following should throw an error. Instead both keys refer to the same value. 
<br />Struct a: <cfdump var="#a#" /> 
<br />a.AO: #a.AO# 
<br />a.B0: #a.B0# 
<hr /> 
The following should show a struct with 2 distinct keys and values. Instead it contains a single key, "AO", with a value of "bar". 
<br />Struct b: <cfdump var="#b#" /> 

Ceci est évidemment un show-bouchon complet pour nous. Je serais curieux de savoir si quelqu'un a rencontré cela ou peut reproduire cela dans son environnement. Pour nous, cela arrive 100% du temps sur Apache/CF9 sous Linux, RH4 et RH5. Nous utilisons l'installation JRun par défaut sur Java 1.6.0_14.

Pour voir l'étendue du problème, nous avons exécuté une boucle rapide pour trouver d'autres séquences de nommage qui sont affectées et trouvé des centaines de correspondances pour les noms de clé de 2 lettres. Une boucle similaire a trouvé plus de conflits dans les noms de 3 lettres.

<cfoutput>Testing a range of affected key combinations. This found hundreds of cases on our platform. Aborting after 50 here.</cfoutput> 
<cfscript> 
teststring = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"; 
stringlen = len(teststring); 
matchesfound = 0; 
matches = ""; 

for (i1 = 1; i1 <= stringlen; i1++) { 
    symbol1 = mid(teststring, i1, 1); 
    for (i2 = 1; i2 <= stringlen; i2++) { 
     teststruct = structnew(); 
     symbol2 = mid(teststring, i2, 1); 
     symbolwhole = symbol1 & symbol2; 
     teststruct[ symbolwhole ] = "a string"; 

     for (q1 = 1; q1 <= stringlen; q1++) { 
      innersymbol1 = mid(teststring, q1, 1); 
      for (q2 = 1; q2 <= stringlen; q2++) { 
       innersymbol2 = mid(teststring, q2, 1); 
       innersymbolwhole = innersymbol1 & innersymbol2; 
       if ((i1 != q1 || i2 != q2) && structkeyexists(teststruct, innersymbolwhole)) { 
        // another affected pair of keys! 
        writeoutput ("<br />#symbolwhole# = #innersymbolwhole#"); 
        if (matchesfound++ > 50) { 
         // we've seen enough 
         abort; 
        } 
       } 
      } 
     } 
    } 
} 
</cfscript> 

Et de modifier à nouveau: Cela n'affecte pas seulement les clés de struct mais aussi les noms dans la portée des variables. Au moins la portée des variables a la présence d'esprit de jeter une erreur, « ne peut pas charger une valeur nulle »:

<cfset test_b0 = "foo" /> 
<cfset test_ao = "bar" /> 
<cfoutput> 
test_b0: #test_b0# 
<br />test_ao: #test_ao# 
</cfoutput> 
+0

Je tiens également à noter que c'est aussi un problème pour les noms contenant une sous-chaîne qui correspond à une mauvaise séquence, donc "whatevernameAO" et "whatevernameB0" entrent en conflit de la même manière. Je ne peux pas croire que nous avons acheté ceci ... –

+0

Avez-vous classé le bug à Adobe? http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html – Henry

+0

J'ai posté sur une page d'Adobe "bug/wish-list", mais il avait une sorte de look "personne à la maison". L'un d'entre nous a peut-être aussi posté sur ce bug-tracker, je vais vérifier. Dans quel environnement avez-vous pu le reproduire? –

Répondre

6

MISE À JOUR: HOTFIX FUITE:http://kb2.adobe.com/cps/825/cpsid_82547.html

Je pense que oui, ceci est un bug, mais voici une solution d'urgence:

<cfset a = createObject("java", "java.util.HashMap").init()> 
<cfset structInsert(a, "AO", "foo") /> 

<cfset b = createObject("java", "java.util.HashMap").init()> 
<cfset structInsert(b,"AO", "foo") /> 
<cfset structInsert(b,"B0", "bar") /> 

<cfoutput> 
The following should throw an error. Instead both keys refer to the same value. 
<br />Struct a: <cfdump var="#a#" /> 
<br />a.AO: #a.AO# 
<br />a.B0: #a.B0# 
<hr /> 

The following should show a struct with 2 distinct keys and values. Instead it contains a single key, "AO", with a value of "bar". 
<br />Struct b: <cfdump var="#b#" /> 
</cfoutput> 

Depuis un struct est un HashMap, vous pouvez toujours utiliser toutes les fonctions de struct dans les FC

Pendant ce temps, s'il vous plaît déposer le bug à: http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html

+0

Merci Henry. Je pensais que tomber dans la couche java pourrait marcher, mais nous espérons migrer de gros vieux monstres de CF8 avec un refactoring minimal. Le rapport de bogue est ici: http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#bugId=81884 Quand je suis entré que je ne l'avais pas réalisé que quelqu'un chez Adobe a pris la rapport que j'ai fait sur un autre formulaire d'inscription et le mettre dans le bug-tracker. Donc, il y a en fait 2 tickets qu'ils peuvent fusionner. –

+0

Confirmé. Ça marche pour moi. – johncblandii

+0

Juste curieux, pourquoi HashMap sur Hashtable? – Leigh

0

Ce que je trouve encore plus étrange est que cela fonctionne:

<cfset b = { AO = "foo", BO = "bar"} /> 
+0

quoi de si particulier à ce sujet? – Henry

+0

si les touches sont AO et B0 cela ne fonctionne pas, mais AO & BO fonctionnent. J'aurais pensé que les clés qui se ressemblent seraient aussi à l'origine des problèmes. –

Questions connexes