[ic] Update: Re: AddAttr only UserTags sometimes work, sometimes fail

[Chris Keane]

On 4/20/2010 9:08 AM, Chris Keane wrote:
>
> UserTag demotag AddAttr
> userTag demotag Routine <<EOR
> sub
> {
>     my ($opt) = @_;
> ...
>
>
>
> The problem comes when accessing any of the members of the $opt 
> hashref. For the sake of example, let's say that we have an argument 
> to the UserTag called "thing", so the call would be
> [demotag thing=thing_content]
>
> Not all time, but SOMETIMES when I try to access some of the data, 
> even very simply, for example
>
> ::logError("opt thing is ". $opt->{thing});
>
> the tag fails and an error is written to the global error.log:
> demo.html Died in server spawn: Can't use string ("thing_content") as 
> a HASH ref while "strict refs" in use at (tag 'cgi') line 17.
>
> This worked as expected in previous version of IC, and I suspect in 
> later versions (for example, I haven't seen this problem come up on a 
> 5.7.4 server, not that it won't, just haven't seen it).
>
> The weird part is that sometimes it works as I would expect. Then it 
> will fail and consistently fail for some random period of time. Then 
> it will work again.
>
> I can work around the problem by providing an Order to the usertag:
> UserTag demotag Order x
> UserTag demotag AddAttr
> userTag demotag Routine <<EOR
> sub
> {
>     my ($x,$opt) = @_;
>
> Any thoughts or guidance?
>


I've a related  specific symptom but haven't poked through the server 
code yet.

Here's how I call one specific UserTag:
[tmp go][gridding-order max="[scratch max]"
                                     exclude="[scratch exclude]"
                                     evenstart="[scratch evenstart]"
                                     rowsize="[scratch rowsize]"
                                     event="[cgi event]"
                                     class="[wave-param gc_classid]" ][/tmp]
where, for example,  the values end up being max = 999, exclude = 0, 
evenstart = "0", rowsize = 4, event = 20100626 and class = flcc

This is calling a UserTag that starts like this:
UserTag gridding_order Order class event
UserTag gridding_order AddAttr
UserTag gridding_order Routine <<EOR
sub
{
         my ($class, $event, $opt) = @_;
::logError("gridding order args = " . ::uneval_it(\@_));

About half the time this is called, the arguments deposited in the log 
file look like this:
race args = ["flcc","20100626","20100626",{'rowsize' => "4",'evenstart' 
=> "0",'reparse' => "1",'max' => "999",'class' => "flcc",'event' => 
"20100626",'exclude' => "0",},]

So, we end up with class = flcc (good), event = 20100626 (good) and opt 
= 20100626 (bad). Where on earth did that extra 20100626 come from!?!?! 
There's only one arg with that value, event! This produces an error:
  Died in server spawn: Can't use string ("20100626") as a HASH ref 
while "strict refs" in use at (tag 'cgi') line 42
Which is precisely right... when I try to access, say $opt->{anything} 
it fails, because $opt is erroneously a scalar with the value of the 
event in it.

Now, if I reorder the arguments to the tag so that event and class are 
the first two arguments, i.e.
[tmp go][gridding-order event="[cgi event]"
                                     class="[wave-param gc_classid]" ]
                                     max="[scratch max]"
                                     exclude="[scratch exclude]"
                                     evenstart="[scratch evenstart]"
                                     rowsize="[scratch rowsize]"][/tmp]

Then everything seems to work fine. Confusing? Well, it is to me ;)

Note that  UserTags that are completely AddAttr, i.e. everything is 
delivered via $opt have the same problem except that the mysterious 
extra argument can end up being pretty much anything.

Any thoughts?

Chris.