Avoid __badType label being executed when the failpoint execution flow is not diverted and the type conversion is successful #66
Conversation
|
Thank you @henrybear327 for the PR, I will be reviewing it shortly. |
|
/assign |
henrybear327
force-pushed
the
fix/bad_type_issues
branch
from
dd1c4f3
to
f0353a7
Compare
Gentle ping :) I have also rebased it against the latest commit! |
|
Hey @henrybear327 👋 |
due to the source repo being deleted by the author, I can only reproduce
the commits again)
If the code execution flow after the failpoint type conversion doesn't
jump to other parts of the code, the `__badType` will be executed,
causing irrelevant error messages to be printed.
For example, consider the following snippet
```go
// gofail: var SomeFuncString string
// log.Println("SomeFuncString", SomeFuncString)
```
It will be generated into the following snippet
```go
if vSomeFuncString, __fpErr := __fp_SomeFuncString.Acquire(); __fpErr == nil {
SomeFuncString, __fpTypeOK := vSomeFuncString.(string)
if !__fpTypeOK {
goto __badTypeSomeFuncString
}
log.Println("SomeFuncString", SomeFuncString)
__badTypeSomeFuncString:
__fp_SomeFuncString.BadType(vSomeFuncString, "string")
}
```
As you can see, because `log.println` doesn't jump to other parts of the
code, after printing the log, the code will continue to execute
`__badTypeSomeFuncString`, thus, printing the following message:
`"SomeFuncString" got value Hello_world of type "string" but expected type "string"`
The solution is to add a `__nomock` label, in the case of type
conversion succeeded, thus the `__badType` label won't be executed.
Reference:
- demo code https://github.com/henrybear327/gofail-perf-fix-demo/tree/issue/val_error
Signed-off-by: Chun-Hung Tseng <[email protected]>
…ommit Signed-off-by: Chun-Hung Tseng <[email protected]>
henrybear327
force-pushed
the
fix/bad_type_issues
branch
from
e82b260
to
eab9819
Compare
Thanks @ArkaSaha30 for spotting this! Updated as requested! |
|
Thank you @henrybear327 . |
|
Thanks for resurrect the PR #19, please also update the examples in https://github.com/etcd-io/gofail/blob/master/doc/design.md#generated-code |
|
It would be great if you can add a test in https://github.com/etcd-io/gofail/blob/master/code/rewrite_test.go to verify the generated code is expected. |
…l commit Signed-off-by: Chun-Hung Tseng <[email protected]>
The generated code is updated! :) Thanks @ahrtr for spotting this missed update! |
Signed-off-by: Chun-Hung Tseng <[email protected]>
henrybear327
force-pushed
the
fix/bad_type_issues
branch
from
ad2e0dd
to
5f671c7
Compare
@ahrtr I manually added the generated output to |
Revive #19 (as the PR is closed due to the source repo being deleted by the author, I can only reproduce the commits again)
If the code execution flow after the failpoint type conversion doesn't jump to other parts of the code, the
__badTypewill be executed, causing irrelevant error messages to be printed.For example, consider the following snippet
It will be generated into the following snippet
As you can see, because
log.printlndoesn't jump to other parts of the code, after printing the log, the code will continue to execute__badTypeSomeFuncString, thus, printing the following message:"SomeFuncString" got value Hello_world of type "string" but expected type "string"The solution is to add a
__nomocklabel, in the case of type conversion succeeded, thus the__badTypelabel won't be executed.Reference: