runtime/race: document and fix "trap when race detected" #23577
Comments
|
/cc @dvyukov |
|
I guess we could use the standard printing routine for the first stack. Race runtime would need to call back to ask for the whole current stack trace. |
|
I can't speak to the breadth of use cases, of course, but for the circumstance that I noticed this, the parameters would only be helpful if provided for both stacks in the conflict. In my particular case, I wanted to know if the calls into my Aside, I am curious about how the race detector is implemented, but I didn't find the text "DATA RACE" in github.com/golang/go. Is there another repository that this lives in? |
|
@object88 thank you for the report and for asking about the runtime race detector. You might find this useful Lines 1 to 7 in 00587e8 and as the doc there says, please take a look at https://github.com/golang/build/tree/master/cmd/racebuild aka package |
odeke-em
changed the title
go test -race
|
Providing arguments for both stacks is infeasible. |
|
Out of curiosity, is that 8 bytes per stack, or 8 bytes per stack frame? Regardless, I hear that there's a very large memory cost involved. Rather than add to the cost of maintaining the parameters, etc., is there a feasible way (generally speaking, not necessarily using what currently exists) to read the stack from another goroutine? |
8 bytes per full stack trace. |
runtime.GoroutineProfile does this. |
Do you mean that the race detector does not cause the program to come to a complete pause across all goroutines, so that even if we were to inspect the other goroutine, it's in all likelihood have changed state to such a degree that we may not get any useful information, or at least not with any consistency? |
|
Generally there is no point in time when both racing goroutines are at these stacks at the same time, so it does not matter if it pauses or not. |
|
I'm a little confused; I wouldn't expect the racing goroutines to have identical stacks. What I have observed is that while they have the same small number of initial stack frames, the execution has diverged at the time of the race. I didn't include the whole data race dump initially for brevity's sake, so perhaps I haven't been clear. Here is a full example: |
|
@dvyukov, is there a way to run the program so it crashes at the point where the race is detected? Then at least someone can run under a debugger and get a stack trace for the live half of the race. |
|
|
They don't. Did I say otherwise somewhere? |
|
No, I misunderstood, my apologies. |
|
It seems like we should:
|
rsc
changed the title
rsc
added
NeedsFix
|
I would like to participate in this work, even if it is just documentation; what's a good way to go about contributing? |
|
The docs for -race at https://golang.org/cmd/go point to https://golang.org/doc/articles/race_detector.html, which does in fact document We should also make sure that it reports the correct stack trace; above, @dvyukov says that it does not. I don't know what's involved there. For general contribution instructions, see https://golang.org/doc/contribute.html. Thanks. |
Race runtime raises SIGABRT inside of itself on partially switched Go stack (see comment on runtime·racecallbackthunk). It maybe hard to unwind from there. The simplest way to achieve this would probably be to call back into Go runtime from race runtime, and then Go runtime can print perfectly valid stack and terminate. |
|
@dvyukov Aside from the fact that the tooling is currently broken, are there any fixes in the upstream race detector that we would want to import or is it relatively stable? |
|
Not urgent, but it would be nice to pull in the fix for #20139. |
|
Nothing particularly important. |
object88 commentedJan 27, 2018
This is not so much a bug, as an ask.
When using the
-raceoption forgo test, I would like to see the arguments that are provided at the call site, down the stack, when a data race is detected. Currently, I only see the methods themselves. If I omit the-raceoption, I can see the data race as reported by a map concurrency problem, and this does include call parameters.In my particular example, I am having trouble with a map that the
go/types#Checkermethod uses. The concurrency issue is happening deep in the Go code, rather than something that I have immediate control over. (Note: I do not think that this is a problem in the Go type checker library at this point; no reason to. I'm sure I'm doing something wrong on my side.) I have many goroutines running a type checker at the same time. If I had parameters on the call stack, I could tell a lot more about the situation that causes the issue.What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
I have not tried with the 1.10 beta.
What operating system and processor architecture are you using (
go env)?What did you do?
Unfortunately, I don't have a small working example of this scenario. I found this while debugging a race condition in my... um, complex program. I can try to create a more minimal example at a later date, if the team thinks it's helpful.
What did you expect to see?
I would like to see the parameters in the call stack. This example from the map's concurrency checker is a great example:
In particular, I can see the parameters to my
processCompletemethod:By seeing the parameters, I can see whether or not my
processCompletemethod is getting called with the same parameters simultaneously.What did you see instead?
I can observe that
processCompletewas invoked, but it's missing context:Without the parameter information, I don't know whether or not the same data is being passed into the method.
The text was updated successfully, but these errors were encountered: