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

[antoine monmayrant]

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
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
>