Smalltalk › Frameworks & Tools › Seaside › Seaside General

Potentially nasty seaside bug.

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

LawsonEnglish

Potentially nasty seaside bug.

I created a simple seaside component that accepts an integer n between
0 and 1000 and returns n factorial.

I invited bunches of people to spam click on the submit button and every
now and then people notice that stray values start appearing in the
entry field, as though sessions were sharing data in some way.

It's running in a (hopefully well sand-boxed) account on my computer:
http://72.200.121.127:8080/SeventhTestComponent

if more than a few people spam click the n factoral button constantly,
stray numbers start to appear, apparently input by someone else in some
other session.

Not sure where to upload the source code, but you can browse the
instance methods from within the page.

Lawson

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli

Re: Potentially nasty seaside bug.

> I invited bunches of people to spam click on the submit button and every now
> and then people notice that stray values start appearing in the entry field,
> as though sessions were sharing data in some way.

Normally that shouldn't happen, unless of course you use shared state.

> It's running in a (hopefully well sand-boxed) account on my computer:
> http://72.200.121.127:8080/SeventhTestComponent

Can't reach it.

> Not sure where to upload the source code, but you can browse the instance
> methods from within the page.

Maybe you can copy and paste the methods into a mail? File-out the
class? Or publish a Monticello package?

Lukas

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

LawsonEnglish

Re: Potentially nasty seaside bug.

On 9/10/10 10:12 PM, Lukas Renggli wrote:

>> I invited bunches of people to spam click on the submit button and every now
>> and then people notice that stray values start appearing in the entry field,
>> as though sessions were sharing data in some way.
> Normally that shouldn't happen, unless of course you use shared state.
>
>> It's running in a (hopefully well sand-boxed) account on my computer:
>> http://72.200.121.127:8080/SeventhTestComponent
> Can't reach it.
>
>> Not sure where to upload the source code, but you can browse the instance
>> methods from within the page.
> Maybe you can copy and paste the methods into a mail? File-out the
> class? Or publish a Monticello package?
>
> Lukas
>

Wasn't sure how to get it into a public monticello respository. Here's

the file-out .st file.

Lawson

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

SeventhTestComponent.st (5K) Download Attachment

Lukas Renggli

Re: Potentially nasty seaside bug.

'Counter' is a (global) class variable, you probably want to make it
an instance variable.

Lukas

On 11 September 2010 07:39, Lawson English <[hidden email]> wrote:

> On 9/10/10 10:12 PM, Lukas Renggli wrote:
>>>
>>> I invited bunches of people to spam click on the submit button and every
>>> now
>>> and then people notice that stray values start appearing in the entry
>>> field,
>>> as though sessions were sharing data in some way.
>>
>> Normally that shouldn't happen, unless of course you use shared state.
>>
>>> It's running in a (hopefully well sand-boxed) account on my computer:
>>> http://72.200.121.127:8080/SeventhTestComponent
>>
>> Can't reach it.
>>
>>> Not sure where to upload the source code, but you can browse the instance
>>> methods from within the page.
>>
>> Maybe you can copy and paste the methods into a mail? File-out the
>> class? Or publish a Monticello package?
>>
>> Lukas
>>
> Wasn't sure how to get it into a public monticello respository. Here's the
> file-out .st file.
>
>
> Lawson
>
>
>
>

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

LawsonEnglish

Re: Potentially nasty seaside bug.

On 9/10/10 10:45 PM, Lukas Renggli wrote:
> 'Counter' is a (global) class variable, you probably want to make it
> an instance variable.
>
>
I was just checking to see how many hits I was getting, total. I could
see it not being a very accurate count, but would it cause the behavior
everyone saw?

Lawson
>

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Bob Arning

Re: Potentially nasty seaside bug.

In reply to this post by LawsonEnglish

If I file that in, inputValue and outputValue are undeclared variables. If that is true on your system, then all users are sharing the same two variables and the behavior you report will happen when the timing of concurrent users' actions is just right.

Cheers,
Bob

SeventhTestComponent>>inputValue(inputValue is Undeclared) SeventhTestComponent>>inputValue:(inputValue is Undeclared) SeventhTestComponent>>outputValue(outputValue is Undeclared) SeventhTestComponent>>outputValue:(outputValue is Undeclared)

On 9/11/10 1:39 AM, Lawson English wrote:

On 9/10/10 10:12 PM, Lukas Renggli wrote:

I invited bunches of people to spam click on the submit button and every now
and then people notice that stray values start appearing in the entry field,
as though sessions were sharing data in some way.

Normally that shouldn't happen, unless of course you use shared state.

It's running in a (hopefully well sand-boxed) account on my computer:
http://72.200.121.127:8080/SeventhTestComponent

Can't reach it.

Not sure where to upload the source code, but you can browse the instance
methods from within the page.

Maybe you can copy and paste the methods into a mail? File-out the
class? Or publish a Monticello package?

Lukas

Wasn't sure how to get it into a public monticello respository. Here's the file-out .st file.

Lawson
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

LawsonEnglish

Re: Potentially nasty seaside bug.

On 9/11/10 2:47 AM, Bob Arning wrote:

If I file that in, inputValue and outputValue are undeclared variables. If that is true on your system, then all users are sharing the same two variables and the behavior you report will happen when the timing of concurrent users' actions is just right.

Cheers,
Bob

SeventhTestComponent>>inputValue(inputValue is Undeclared) SeventhTestComponent>>inputValue:(inputValue is Undeclared) SeventhTestComponent>>outputValue(outputValue is Undeclared) SeventhTestComponent>>outputValue:(outputValue is Undeclared)

Interesting. I deleted those instance variables and forgot to delete the instance var accessors for them. But they do nothing and are simply set to 1 during object initialization and then never referred to again.

I'll recompile without the class var and delete the references to those variables and try again.

BTW, has anyone ever tried selenium? http://seleniumhq.org/ Or is there a subset of these capabilities available in a seaside package somewhere?

L

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

LawsonEnglish

Re: Potentially nasty seaside bug.

On 9/11/10 9:55 AM, Lawson English wrote:
>
>
> Interesting. I deleted those instance variables and forgot to delete
> the instance var accessors for them. But they do nothing and are
> simply set to 1 during object initialization and then never referred
> to again.
Argh, actually I DO use those vars. So added them as instance vars and
trying again.

Is there a way of validating a class without doing a file-out/file-in
sequence?

Lawson
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Bob Arning

Re: Potentially nasty seaside bug.

In reply to this post by LawsonEnglish

I don't understand what you mean by "never referred to again". Your #renderContentOn: incudes this:

html form: [
      html text: 'enter value here: '.
      html textInput
         value: self inputValue;

         callback: [ :value | self handleValue: value].
    html break.
     html text: 'result:'.
      html textArea
         value: self outputValue;
        rows: 10;
        columns: 60.
        html submitButton with: self inputValue asString, ' factorial'.
          ].

which definitely sends #inputValue and #outputValue. And your #handleValue: method sends both #inputValue: and #outputValue:. So maybe it would be good to boil this example down to the bare minimum neeeded to reproduce the problem.

Cheers,
Bob

On 9/11/10 12:55 PM, Lawson English wrote:

On 9/11/10 2:47 AM, Bob Arning wrote:
If I file that in, inputValue and outputValue are undeclared variables. If that is true on your system, then all users are sharing the same two variables and the behavior you report will happen when the timing of concurrent users' actions is just right.

Cheers,
Bob

SeventhTestComponent>>inputValue(inputValue is Undeclared) SeventhTestComponent>>inputValue:(inputValue is Undeclared) SeventhTestComponent>>outputValue(outputValue is Undeclared) SeventhTestComponent>>outputValue:(outputValue is Undeclared)

Interesting. I deleted those instance variables and forgot to delete the instance var accessors for them. But they do nothing and are simply set to 1 during object initialization and then never referred to again.

I'll recompile without the class var and delete the references to those variables and try again.

BTW, has anyone ever tried selenium? http://seleniumhq.org/ Or is there a subset of these capabilities available in a seaside package somewhere?

L

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Bob Arning

Re: Potentially nasty seaside bug.

In reply to this post by LawsonEnglish

Well,

World menu --> do --> Undeclared removeUnreferencedKeys; inspect.

Cheers,
Bob

On 9/11/10 1:01 PM, Lawson English wrote:

On 9/11/10 9:55 AM, Lawson English wrote:

Interesting. I deleted those instance variables and forgot to delete the instance var accessors for them. But they do nothing and are simply set to 1 during object initialization and then never referred to again.

Argh, actually I DO use those vars. So added them as instance vars and trying again.

Is there a way of validating a class without doing a file-out/file-in sequence?

Lawson
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

LawsonEnglish

Re: Potentially nasty seaside bug.

Thanks for everyone's help. That particular behavior seems to have disappeared. quite a few friends spammed it and it seemed to keep up with them. Seaside is a sweet little system.

Lawson

On 9/11/10 10:29 AM, Bob Arning wrote:

Well,

World menu --> do --> Undeclared removeUnreferencedKeys; inspect.

Cheers,
Bob

On 9/11/10 1:01 PM, Lawson English wrote:
On 9/11/10 9:55 AM, Lawson English wrote:

Interesting. I deleted those instance variables and forgot to delete the instance var accessors for them. But they do nothing and are simply set to 1 during object initialization and then never referred to again.

Argh, actually I DO use those vars. So added them as instance vars and trying again.

Is there a way of validating a class without doing a file-out/file-in sequence?

Lawson
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Johan Brichau-2

Re: Potentially nasty seaside bug.

In reply to this post by LawsonEnglish

On 11 Sep 2010, at 18:55, Lawson English wrote:

BTW, has anyone ever tried selenium? http://seleniumhq.org/ Or is there a subset of these capabilities available in a seaside package somewhere?

You can take a look at WebTester on squeaksource. It has an interface to selenium rc.

Johan

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

LawsonEnglish

Re: Potentially nasty seaside bug.

Great thanks.

On 9/11/10 11:21 AM, Johan Brichau wrote:

On 11 Sep 2010, at 18:55, Lawson English wrote:

BTW, has anyone ever tried selenium? http://seleniumhq.org/ Or is there a subset of these capabilities available in a seaside package somewhere?

You can take a look at WebTester on squeaksource. It has an interface to selenium rc.

Johan
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside