Skip to content

Race in server.Consume between teardown and spawned goroutines #95

@miotte

Description

@miotte

server.Consume spawns sender and Subscribe goroutines that write to returnError and read stopForLoop through heap-escaped pointers, but Consume returns without waiting for them. The goroutines outlive Consume, racing against its writes to returnError and its deferred close+nil of stopForLoop.

Concretely:

  • multiple writers can land on returnError (the spawned goroutines plus the main path) with no synchronization;
  • stopForLoop is closed and nil'd by Consume's defer while the goroutines may still be reading it.

Consume should wait for the spawned goroutines before returning, and stopForLoop should carry the error itself so the main path remains the sole writer of returnError.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workinggoPull requests that update go code

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions