[Scilab-users] bug when setting gcbo field in a callback function ?

classic Classic list List threaded Threaded
8 messages Options
Antoine Monmayrant Antoine Monmayrant
Reply | Threaded
Open this post in threaded view
|

[Scilab-users] bug when setting gcbo field in a callback function ?

Hi all,

In a callback function, gcbo is a handle to the calling uicontrol.
There are 2 ways to set one of the fields of this handle (let's take
"callback_type" as an example):
     (1)    gcbo.callback_type=-1;
or equivalently
     (2)    set(gcbo, "callback_type",-1);

In theory, both are perfectly equivalent.
In practice however, (1) leads to recurrent issues where gcbo is no
longer a handle, but a structure!

See below  an example script showing the difference:
- two slides with equivalent callback functions funcb1 and funcb2, but
for the different syntactic sugar (1) or (2).
- if you play with the top slider in the figure, everything's fine, gcbo
remains a handle (see output on the console).
- if you play with the bottom slider in the figure, gcbo turns into a
struct (see output on the console).

Needless to say, this kind of issue made my GUI debugging session really
fun.
To make things even more fun, if you "pause" then execute "funcb1()"
step by step, you don't necessarily trigger the bug, it's quite random
and fairly unfrequent.

Can you try to reproduce this bug on your computer?

Cheers,

Antoine


// BUG_gcbo_set.sce //
h=scf();

hs1=uicontrol(h, ...
     "style", "slider", ...
     "tag", "slide1", ...
     "backgroundcolor", [1 1 1], ...
     "value", 0, ...
     "min", -100, ...
     "max", 100, ...
     "sliderstep", [1, 10], ...
     "position", [20,40,200,20], ...
     "constraints", createConstraints("border", "top"), ...
     "callback", "funcb1");

function  funcb1()
     disp(typeof(gcbo));
     gcbo.callback_type=-1;
     disp(typeof(gcbo));
     gcbo.callback_type=0;
endfunction


hs2=uicontrol(h, ...
     "style", "slider", ...
     "tag", "slide1", ...
     "backgroundcolor", [1 1 1], ...
     "value", 0, ...
     "min", -100, ...
     "max", 100, ...
     "sliderstep", [1, 10], ...
     "position", [20,80,200,20], ...
     "constraints", createConstraints("border", "top"), ...
     "callback", "funcb2");

function  funcb2()
     disp(typeof(gcbo));
     set(gcbo, "callback_type",-1);
     disp(typeof(gcbo));
     set(gcbo, "callback_type",0)
endfunction

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: bug when setting gcbo field in a callback function ?

Hello Antoine,

Never trust the life time of gcbo, and first copy the value of gcbo like
this:

function  funcb1()
     h=gcbo
     disp(typeof(h));
     h.callback_type=-1;
     disp(typeof(h));
     h.callback_type=0;
endfunction

With this trick the type of h is always a handle. However, I cannot
explain why the second syntax using set() always works...

S.

Le 28/09/2018 à 21:00, antoine monmayrant a écrit :

> Hi all,
>
> In a callback function, gcbo is a handle to the calling uicontrol.
> There are 2 ways to set one of the fields of this handle (let's take
> "callback_type" as an example):
>     (1)    gcbo.callback_type=-1;
> or equivalently
>     (2)    set(gcbo, "callback_type",-1);
>
> In theory, both are perfectly equivalent.
> In practice however, (1) leads to recurrent issues where gcbo is no
> longer a handle, but a structure!
>
> See below  an example script showing the difference:
> - two slides with equivalent callback functions funcb1 and funcb2, but
> for the different syntactic sugar (1) or (2).
> - if you play with the top slider in the figure, everything's fine,
> gcbo remains a handle (see output on the console).
> - if you play with the bottom slider in the figure, gcbo turns into a
> struct (see output on the console).
>
> Needless to say, this kind of issue made my GUI debugging session
> really fun.
> To make things even more fun, if you "pause" then execute "funcb1()"
> step by step, you don't necessarily trigger the bug, it's quite random
> and fairly unfrequent.
>
> Can you try to reproduce this bug on your computer?
>
> Cheers,
>
> Antoine
>
>
> // BUG_gcbo_set.sce //
> h=scf();
>
> hs1=uicontrol(h, ...
>     "style", "slider", ...
>     "tag", "slide1", ...
>     "backgroundcolor", [1 1 1], ...
>     "value", 0, ...
>     "min", -100, ...
>     "max", 100, ...
>     "sliderstep", [1, 10], ...
>     "position", [20,40,200,20], ...
>     "constraints", createConstraints("border", "top"), ...
>     "callback", "funcb1");
>
> function  funcb1()
>     disp(typeof(gcbo));
>     gcbo.callback_type=-1;
>     disp(typeof(gcbo));
>     gcbo.callback_type=0;
> endfunction
>
>
> hs2=uicontrol(h, ...
>     "style", "slider", ...
>     "tag", "slide1", ...
>     "backgroundcolor", [1 1 1], ...
>     "value", 0, ...
>     "min", -100, ...
>     "max", 100, ...
>     "sliderstep", [1, 10], ...
>     "position", [20,80,200,20], ...
>     "constraints", createConstraints("border", "top"), ...
>     "callback", "funcb2");
>
> function  funcb2()
>     disp(typeof(gcbo));
>     set(gcbo, "callback_type",-1);
>     disp(typeof(gcbo));
>     set(gcbo, "callback_type",0)
> endfunction
>
> _______________________________________________
> users mailing list
> [hidden email]
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 
>

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Antoine Monmayrant Antoine Monmayrant
Reply | Threaded
Open this post in threaded view
|

Re: bug when setting gcbo field in a callback function ?

Hello Stéphane,

Well, I tried exactly this trick with mixed results: it kind of works
most of the time, but sometimes it fails.
I did not manage to reproduce the issue with my minimum working example
though.

It's weird, no?
Why would gcbo behave differently than h?

As for why "set" is working, while "gcbo.whatever=something" is failing,
I think it's because something goes wrong when scilab is parsing
"gcbo.whatever=something".
It is as if scilab forgot about the fact that gcbo exists and does what
we expect when creating a struct:
     doesnotexists.whatever=something;
creates a "doesnotexists" struct with one field==something.

Antoine


Le 29/09/2018 à 00:04, Stéphane Mottelet a écrit :

> Hello Antoine,
>
> Never trust the life time of gcbo, and first copy the value of gcbo
> like this:
>
> function  funcb1()
>     h=gcbo
>     disp(typeof(h));
>     h.callback_type=-1;
>     disp(typeof(h));
>     h.callback_type=0;
> endfunction
>
> With this trick the type of h is always a handle. However, I cannot
> explain why the second syntax using set() always works...
>
> S.
>
> Le 28/09/2018 à 21:00, antoine monmayrant a écrit :
>> Hi all,
>>
>> In a callback function, gcbo is a handle to the calling uicontrol.
>> There are 2 ways to set one of the fields of this handle (let's take
>> "callback_type" as an example):
>>     (1)    gcbo.callback_type=-1;
>> or equivalently
>>     (2)    set(gcbo, "callback_type",-1);
>>
>> In theory, both are perfectly equivalent.
>> In practice however, (1) leads to recurrent issues where gcbo is no
>> longer a handle, but a structure!
>>
>> See below  an example script showing the difference:
>> - two slides with equivalent callback functions funcb1 and funcb2,
>> but for the different syntactic sugar (1) or (2).
>> - if you play with the top slider in the figure, everything's fine,
>> gcbo remains a handle (see output on the console).
>> - if you play with the bottom slider in the figure, gcbo turns into a
>> struct (see output on the console).
>>
>> Needless to say, this kind of issue made my GUI debugging session
>> really fun.
>> To make things even more fun, if you "pause" then execute "funcb1()"
>> step by step, you don't necessarily trigger the bug, it's quite
>> random and fairly unfrequent.
>>
>> Can you try to reproduce this bug on your computer?
>>
>> Cheers,
>>
>> Antoine
>>
>>
>> // BUG_gcbo_set.sce //
>> h=scf();
>>
>> hs1=uicontrol(h, ...
>>     "style", "slider", ...
>>     "tag", "slide1", ...
>>     "backgroundcolor", [1 1 1], ...
>>     "value", 0, ...
>>     "min", -100, ...
>>     "max", 100, ...
>>     "sliderstep", [1, 10], ...
>>     "position", [20,40,200,20], ...
>>     "constraints", createConstraints("border", "top"), ...
>>     "callback", "funcb1");
>>
>> function  funcb1()
>>     disp(typeof(gcbo));
>>     gcbo.callback_type=-1;
>>     disp(typeof(gcbo));
>>     gcbo.callback_type=0;
>> endfunction
>>
>>
>> hs2=uicontrol(h, ...
>>     "style", "slider", ...
>>     "tag", "slide1", ...
>>     "backgroundcolor", [1 1 1], ...
>>     "value", 0, ...
>>     "min", -100, ...
>>     "max", 100, ...
>>     "sliderstep", [1, 10], ...
>>     "position", [20,80,200,20], ...
>>     "constraints", createConstraints("border", "top"), ...
>>     "callback", "funcb2");
>>
>> function  funcb2()
>>     disp(typeof(gcbo));
>>     set(gcbo, "callback_type",-1);
>>     disp(typeof(gcbo));
>>     set(gcbo, "callback_type",0)
>> endfunction
>>
>> _______________________________________________
>> users mailing list
>> [hidden email]
>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 
>>
>
> _______________________________________________
> users mailing list
> [hidden email]
> http://lists.scilab.org/mailman/listinfo/users
>

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: bug when setting gcbo field in a callback function ?

Le 29/09/2018 à 00:31, antoine monmayrant a écrit :

> Hello Stéphane,
>
> Well, I tried exactly this trick with mixed results: it kind of works
> most of the time, but sometimes it fails.
> I did not manage to reproduce the issue with my minimum working
> example though.
>
> It's weird, no?
> Why would gcbo behave differently than h?
>
> As for why "set" is working, while "gcbo.whatever=something" is
> failing, I think it's because something goes wrong when scilab is
> parsing "gcbo.whatever=something".
> It is as if scilab forgot about the fact that gcbo exists and does
> what we expect when creating a struct:
>     doesnotexists.whatever=something;
> creates a "doesnotexists" struct with one field==something.

This bug exists at least since Scilab 5.3.3 (not tested with older
versions) and is not yet reported.

Samuel

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Antoine Monmayrant Antoine Monmayrant
Reply | Threaded
Open this post in threaded view
|

Re: bug when setting gcbo field in a callback function ?



Le 29/09/2018 à 12:10, Samuel Gougeon a écrit :

> Le 29/09/2018 à 00:31, antoine monmayrant a écrit :
>> Hello Stéphane,
>>
>> Well, I tried exactly this trick with mixed results: it kind of works
>> most of the time, but sometimes it fails.
>> I did not manage to reproduce the issue with my minimum working
>> example though.
>>
>> It's weird, no?
>> Why would gcbo behave differently than h?
>>
>> As for why "set" is working, while "gcbo.whatever=something" is
>> failing, I think it's because something goes wrong when scilab is
>> parsing "gcbo.whatever=something".
>> It is as if scilab forgot about the fact that gcbo exists and does
>> what we expect when creating a struct:
>>     doesnotexists.whatever=something;
>> creates a "doesnotexists" struct with one field==something.
>
> This bug exists at least since Scilab 5.3.3 (not tested with older
> versions) and is not yet reported. u
He, he, I assume that we are all guilty here, right? ;-)
So here it is: http://bugzilla.scilab.org/show_bug.cgi?id=15786
Could some of you try it on their preferred platform/scilab_version and
comment on the bug report accordingly?

I also got this problem (a handle turning into a struct) when updating a
graphic handle field quickly inside a loop.
It's less frequent and I never managed to reproduce the bug in a
deterministic way so I never reported it.
Of course, whenever I faced this bug, trying to pause and run the code
step-by-step does not show any bug.
Could there be some sort of race condition here, like when you access
the handle fields too many times too quickly, scilab does as if the
handle does not exists and interpret your code as the creation of a new
struct with a given field?

Cheers,

Antoine
>
> Samuel
>
> _______________________________________________
> users mailing list
> [hidden email]
> http://lists.scilab.org/mailman/listinfo/users
>

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: bug when setting gcbo field in a callback function ?

Hello Antoine

There are multiple other problems like this one, solved when inserting a pause or a sleep. They are java synchronization problems, likely....

S.

> Le 29 sept. 2018 à 12:47, antoine monmayrant <[hidden email]> a écrit :
>
>
>
>> Le 29/09/2018 à 12:10, Samuel Gougeon a écrit :
>>> Le 29/09/2018 à 00:31, antoine monmayrant a écrit :
>>> Hello Stéphane,
>>>
>>> Well, I tried exactly this trick with mixed results: it kind of works most of the time, but sometimes it fails.
>>> I did not manage to reproduce the issue with my minimum working example though.
>>>
>>> It's weird, no?
>>> Why would gcbo behave differently than h?
>>>
>>> As for why "set" is working, while "gcbo.whatever=something" is failing, I think it's because something goes wrong when scilab is parsing "gcbo.whatever=something".
>>> It is as if scilab forgot about the fact that gcbo exists and does what we expect when creating a struct:
>>>     doesnotexists.whatever=something;
>>> creates a "doesnotexists" struct with one field==something.
>>
>> This bug exists at least since Scilab 5.3.3 (not tested with older versions) and is not yet reported. u
> He, he, I assume that we are all guilty here, right? ;-)
> So here it is: https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15786
> Could some of you try it on their preferred platform/scilab_version and comment on the bug report accordingly?
>
> I also got this problem (a handle turning into a struct) when updating a graphic handle field quickly inside a loop.
> It's less frequent and I never managed to reproduce the bug in a deterministic way so I never reported it.
> Of course, whenever I faced this bug, trying to pause and run the code step-by-step does not show any bug.
> Could there be some sort of race condition here, like when you access the handle fields too many times too quickly, scilab does as if the handle does not exists and interpret your code as the creation of a new struct with a given field?
>
> Cheers,
>
> Antoine
>>
>> Samuel
>>
>> _______________________________________________
>> users mailing list
>> [hidden email]
>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
>>
>
> _______________________________________________
> users mailing list
> [hidden email]
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: bug when setting gcbo field in a callback function ?

Another example of such weirdness: consider (fixed) bug #13359. Its
non-regression test fail (at least on my OSX and Linux machines)
systematicaly when run by

--> test_run cacsd bug_13359

When run interactively by

--> exec SCI/modules/cacsd/tests/nonreg_tests/bug_13359.tst

it sometimes succeed and sometimes fail, this completely random.
However, if you insert a sleep line 25

(...)
d1 = datatipCreate(pl, 200);
sleep(10) // line inserted
txt_datatip = d1.text;
assert_checkequal(strindex(txt_datatip(2), "-"), 1);

Then the test, executed by exec SCI/... above, always succeed. However,
even with a bigger duration of sleep, even sleep(1000), then "test_run
cacsd bug_13359" always fail.

S.

Le 29/09/2018 à 13:05, Stéphane Mottelet a écrit :

> Hello Antoine
>
> There are multiple other problems like this one, solved when inserting a pause or a sleep. They are java synchronization problems, likely....
>
> S.
>
>> Le 29 sept. 2018 à 12:47, antoine monmayrant <[hidden email]> a écrit :
>>
>>
>>
>>> Le 29/09/2018 à 12:10, Samuel Gougeon a écrit :
>>>> Le 29/09/2018 à 00:31, antoine monmayrant a écrit :
>>>> Hello Stéphane,
>>>>
>>>> Well, I tried exactly this trick with mixed results: it kind of works most of the time, but sometimes it fails.
>>>> I did not manage to reproduce the issue with my minimum working example though.
>>>>
>>>> It's weird, no?
>>>> Why would gcbo behave differently than h?
>>>>
>>>> As for why "set" is working, while "gcbo.whatever=something" is failing, I think it's because something goes wrong when scilab is parsing "gcbo.whatever=something".
>>>> It is as if scilab forgot about the fact that gcbo exists and does what we expect when creating a struct:
>>>>      doesnotexists.whatever=something;
>>>> creates a "doesnotexists" struct with one field==something.
>>> This bug exists at least since Scilab 5.3.3 (not tested with older versions) and is not yet reported. u
>> He, he, I assume that we are all guilty here, right? ;-)
>> So here it is: https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15786
>> Could some of you try it on their preferred platform/scilab_version and comment on the bug report accordingly?
>>
>> I also got this problem (a handle turning into a struct) when updating a graphic handle field quickly inside a loop.
>> It's less frequent and I never managed to reproduce the bug in a deterministic way so I never reported it.
>> Of course, whenever I faced this bug, trying to pause and run the code step-by-step does not show any bug.
>> Could there be some sort of race condition here, like when you access the handle fields too many times too quickly, scilab does as if the handle does not exists and interpret your code as the creation of a new struct with a given field?
>>
>> Cheers,
>>
>> Antoine
>>> Samuel
>>>
>>> _______________________________________________
>>> users mailing list
>>> [hidden email]
>>> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
>>>
>> _______________________________________________
>> users mailing list
>> [hidden email]
>> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
> _______________________________________________
> users mailing list
> [hidden email]
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: bug when setting gcbo field in a callback function ?

Le 29/09/2018 à 18:16, Stéphane Mottelet a écrit :

> Another example of such weirdness: consider (fixed) bug #13359. Its
> non-regression test fail (at least on my OSX and Linux machines)
> systematicaly when run by
>
> --> test_run cacsd bug_13359
>
> When run interactively by
>
> --> exec SCI/modules/cacsd/tests/nonreg_tests/bug_13359.tst
>
> it sometimes succeed and sometimes fail, this completely random.
> However, if you insert a sleep line 25
>
> (...)
> d1 = datatipCreate(pl, 200);
> sleep(10) // line inserted
> txt_datatip = d1.text;
> assert_checkequal(strindex(txt_datatip(2), "-"), 1);
>
> Then the test, executed by exec SCI/... above, always succeed.
> However, even with a bigger duration of sleep, even sleep(1000), then
> "test_run cacsd bug_13359" always fail.

A follow-up is proposed on dev@ starting at
http://mailinglists.scilab.org/Re-Scilab-users-bug-when-setting-gcbo-field-in-a-callback-function-tp4038626.html

Samuel

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users