Obscure bug with srfi-18, mailbox and coops

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Obscure bug with srfi-18, mailbox and coops

Théo Cavignac
Thank you your awesome reactivity !

> Is this a different error, or caused by the problem you observed?

I don't really know to be honest. This is the bug I am really tracking
and I don't know if it come from a logical error in the code or if it
come from the other bug I described before. The thing is that other
bug appear randomly. Right now on my local repo I got scheduler using
slot one-shot in place of slot workers (same kind of bug than in my
previous mail but with a different slot).

As I said this is a work in progress and there is definitely more bugs
in my code but the problem I described is the most weird and prevent
me from going forward.

> This is just a guess, but I think it just may be the case you are using the slot before it has been initialized (see build-cache in coops.scm).

I don't think the slots are uninitialized because sometimes the slot
used instead of another contains class instance. Still I would like to
try but I am not sure how to proceed to inject options in building
coops. Is it something like this :
CSC_OPTIONS='-disable-interrupts' chicken-install coops

_______________________________________________
Chicken-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/chicken-users
Reply | Threaded
Open this post in threaded view
|

Re: Obscure bug with srfi-18, mailbox and coops

Théo Cavignac

Unfortunatly it did not fixed the bug to add -disable-interrupts. I still have this class of bug spawning here and there with different instances and different slots.

Is there a way I could protect slot access from race conditions directly in my code so that I identify the bug ?

On 28/08/2019 16:46, [hidden email] wrote:


        
This is just a guess, but I think it just may be the case you are using the slot before it has been initialized (see build-cache in coops.scm).
After poking a bit, there seems indeed be a thread-safety issue when 
lookup up object slots, I'm not sure if this is the case here.

I don't think the slots are uninitialized because sometimes the slot
used instead of another contains class instance. Still I would like to
try but I am not sure how to proceed to inject options in building
coops. Is it something like this :
CSC_OPTIONS='-disable-interrupts' chicken-install coops
The easiest solution is to "chicken-install -r coops", cd to coops,
and add (csc-options "-disable-interrupts") to the "coops" extension
properties, then say "chicken-install" inside that directory.


felix


_______________________________________________
Chicken-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/chicken-users
Reply | Threaded
Open this post in threaded view
|

Re: Obscure bug with srfi-18, mailbox and coops

Théo Cavignac
Erratum: I think it did fix the bug, I just misunderstood a different error. Is this modification of coops config viable for upstream or should I find a way to grant thread safety in my own code ?

On Wed, Aug 28, 2019 at 6:17 PM Théo Cavignac <[hidden email]> wrote:

Unfortunatly it did not fixed the bug to add -disable-interrupts. I still have this class of bug spawning here and there with different instances and different slots.

Is there a way I could protect slot access from race conditions directly in my code so that I identify the bug ?

On 28/08/2019 16:46, [hidden email] wrote:


        
This is just a guess, but I think it just may be the case you are using the slot before it has been initialized (see build-cache in coops.scm).
After poking a bit, there seems indeed be a thread-safety issue when 
lookup up object slots, I'm not sure if this is the case here.

I don't think the slots are uninitialized because sometimes the slot
used instead of another contains class instance. Still I would like to
try but I am not sure how to proceed to inject options in building
coops. Is it something like this :
CSC_OPTIONS='-disable-interrupts' chicken-install coops
The easiest solution is to "chicken-install -r coops", cd to coops,
and add (csc-options "-disable-interrupts") to the "coops" extension
properties, then say "chicken-install" inside that directory.


felix


_______________________________________________
Chicken-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/chicken-users
Reply | Threaded
Open this post in threaded view
|

Re: Obscure bug with srfi-18, mailbox and coops

felix.winkelmann
In reply to this post by Théo Cavignac
> Unfortunatly it did not fixed the bug to add -disable-interrupts. I still
> have this class of bug spawning here and there with different instances and
> different slots.
>
> Is there a way I could protect slot access from race conditions directly in
> my code so that I identify the bug ?
>

I fear you will have to implement some form of locking inside coops.
It's crude, but may be helpful to figure out the location of the problem.
I can provide a patch, if you are willing to wait a little - I should be
able to come up with something tomorrow.


felix


_______________________________________________
Chicken-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/chicken-users
Reply | Threaded
Open this post in threaded view
|

Re: Obscure bug with srfi-18, mailbox and coops

felix.winkelmann
In reply to this post by Théo Cavignac
> Erratum: I think it did fix the bug, I just misunderstood a different
> error. Is this modification of coops config viable for upstream or should I
> find a way to grant thread safety in my own code ?
>

Oh! Excellent. I think disabling interrupts is correct - the code
actually assumes context-switches will not occur inside coops internals
in various places.

I will tag a new version with interrupts disabled, so that one will be identical
to the one you use.


felix


_______________________________________________
Chicken-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/chicken-users
Reply | Threaded
Open this post in threaded view
|

Re: Obscure bug with srfi-18, mailbox and coops

megane
In reply to this post by Théo Cavignac

Théo Cavignac <[hidden email]> writes:

> Erratum: I think it did fix the bug, I just misunderstood a different
> error. Is this modification of coops config viable for upstream or should I
> find a way to grant thread safety in my own code ?
>

Great!

I see Felix is going to add the -disable-interrupts flag to the coops
egg.

However, you may still need to compile your code that defines
coops thigs with -disable-interrupts. There are some macros in coops
that define complex functions. Those may still be non-thread safe.

_______________________________________________
Chicken-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/chicken-users
Reply | Threaded
Open this post in threaded view
|

Re: Obscure bug with srfi-18, mailbox and coops

Théo Cavignac
Thank you a lot for your help Megane and Felix, you really saved my project (I nearly abandoned it).
I will add disable-interrupts to my egg file.
Hopefully this project will be publishable soon !


On Wed, Aug 28, 2019 at 7:42 PM megane <[hidden email]> wrote:

Théo Cavignac <[hidden email]> writes:

> Erratum: I think it did fix the bug, I just misunderstood a different
> error. Is this modification of coops config viable for upstream or should I
> find a way to grant thread safety in my own code ?
>

Great!

I see Felix is going to add the -disable-interrupts flag to the coops
egg.

However, you may still need to compile your code that defines
coops thigs with -disable-interrupts. There are some macros in coops
that define complex functions. Those may still be non-thread safe.

_______________________________________________
Chicken-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/chicken-users
Reply | Threaded
Open this post in threaded view
|

Re: Obscure bug with srfi-18, mailbox and coops

felix.winkelmann
In reply to this post by megane
>
> Théo Cavignac <[hidden email]> writes:
>
> > Erratum: I think it did fix the bug, I just misunderstood a different
> > error. Is this modification of coops config viable for upstream or should I
> > find a way to grant thread safety in my own code ?
> >
>
> Great!
>
> I see Felix is going to add the -disable-interrupts flag to the coops
> egg.
>
> However, you may still need to compile your code that defines
> coops thigs with -disable-interrupts. There are some macros in coops
> that define complex functions. Those may still be non-thread safe.

The macros are all defining forms or used internally (mostly the
sinister "build-cache"), so I don't see a need for that.

But, will all things multithreaded, you can of course never be sure...


felix


_______________________________________________
Chicken-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/chicken-users