-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
failpoint delete may block on "defer Release" #14
Comments
@heyitsanthony How about removing Before raftDropHeartbeatLabel: /* gofail-label */
for {
m, err := dec.decode()
if err != nil {
cr.mu.Lock()
cr.close()
cr.mu.Unlock()
return err
}
if vraftDropHeartbeat, __fpErr := __fp_raftDropHeartbeat.Acquire(); __fpErr == nil {
defer __fp_raftDropHeartbeat.Release()
_, __fpTypeOK := vraftDropHeartbeat.(struct{})
if !__fpTypeOK {
goto __badTyperaftDropHeartbeat
}
continue raftDropHeartbeatLabel
__badTyperaftDropHeartbeat:
__fp_raftDropHeartbeat.BadType(vraftDropHeartbeat, "struct{}")
} After raftDropHeartbeatLabel: /* gofail-label */
for {
m, err := dec.decode()
if err != nil {
cr.mu.Lock()
cr.close()
cr.mu.Unlock()
return err
}
if vraftDropHeartbeat, __fpErr := __fp_raftDropHeartbeat.Acquire(); __fpErr == nil {
- defer __fp_raftDropHeartbeat.Release()
_, __fpTypeOK := vraftDropHeartbeat.(struct{})
if !__fpTypeOK {
goto __badTyperaftDropHeartbeat
}
continue raftDropHeartbeatLabel
__badTyperaftDropHeartbeat:
__fp_raftDropHeartbeat.BadType(vraftDropHeartbeat, "struct{}")
} |
@gyuho it's important for current delete semantics: // gofail: var crash struct{}
// panic("crash") if the lock isn't held for the duration of the fp, then it's possible an inflight fp will crash the program after the delete is ack'd. One option is to have something like func a() {
ctx, cancel := context.WithTimeout(context.Background(), 10 * time.Second)
go f(ctx)
}
func f(ctx context.Context) {
// gofail-go: var waitForDone struct{}
// <-ctx.Done()
...
} |
Eventually I removed the lock for each failpoint. When the server(runtime) processes a http request, it acquires the global write lock. This prevents all failpoints from being triggered. It ensures the server(runtime) doesn't panic due to any failpoints during processing the HTTP request. It may be inefficient, but correctness is more important than efficiency. Usually users will not enable too many failpoints at a |
Fully agree with the decision. |
Resolved in #38 |
If failpoint is injected within for-loop, lock may never be released. And delete call would block.
#13 (comment)
The text was updated successfully, but these errors were encountered: