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

[Stéphane Mottelet]

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 <antoine.monmayrant at laas.fr> 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
>>> users at lists.scilab.org
>>> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
>>>
>> _______________________________________________
>> users mailing list
>> users at lists.scilab.org
>> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users