Skip to content
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

fix noise log when fallthrough from gofail's if block #19

Closed
wants to merge 1 commit into from
Closed

fix noise log when fallthrough from gofail's if block #19

wants to merge 1 commit into from

Conversation

lysu
Copy link

@lysu lysu commented Mar 13, 2019

how to reproduce

what I do

import "fmt"

func Test() string {
	// gofail: var beFail bool
	// if beFail {
	// 	fmt.Print(1)
	// }
	fmt.Println(2)
	return "ok"
}

and enable gofail and return false by

import (
	gofail "github.com/etcd-io/gofail/runtime"
)

func TestGoFail(t *testing.T) {
	gofail.Enable("github.com/lysu/go-misc/fail/beFail", "return(false)")
	defer gofail.Disable("github.com/lysu/go-misc/fail/beFail")
	t.Log(fail.Test())
}

expect

print 2 and return ok

but got

std log message

failpoint: "github.com/lysu/go-misc/fail/beFail" got value false of type "bool" but expected type "bool"

and print 2 and return ok

what question

generate code after gofail enable will be

func Test() string {
	if vbeFail, __fpErr := __fp_beFail.Acquire(); __fpErr == nil { defer __fp_beFail.Release(); beFail, __fpTypeOK := vbeFail.(bool); if !__fpTypeOK { goto __badTypebeFail}
		if beFail {
			fmt.Print(1)
		}; __badTypebeFail: __fp_beFail.BadType(vbeFail, "bool"); };
	fmt.Println(2)
	return "ok"
}

when beFail as false, it will continue execute __fp_beFail.BadType(vbeFail, "bool"); event if there are no type error.

what I fix

to generate this code:

func Test() string {
	if vbeFail, __fpErr := __fp_beFail.Acquire(); __fpErr == nil { defer __fp_beFail.Release(); beFail, __fpTypeOK := vbeFail.(bool); if !__fpTypeOK { goto __badTypebeFail}
		if beFail {
			fmt.Print(1)
		}; goto __nomockbeFail; __badTypebeFail: __fp_beFail.BadType(vbeFail, "bool"); __nomockbeFail: };
	fmt.Println(2)
	return "ok"
}

@ahrtr
Copy link
Member

ahrtr commented Dec 2, 2022

Sorry for the late response.

This PR looks good to me. Could you please rebase it?

@lysu lysu closed this by deleting the head repository Apr 30, 2023
henrybear327 added a commit to henrybear327/gofail that referenced this pull request Apr 23, 2024
If the code execution flow after the failpoint type conversion doesn't
jump to other parts of the code (e.g. return will change the execution
flow), the __badTypeXXX will be executed, causing irrelevant error
messages to be printed.

For example, the following snippet
```
// gofail: var SomeFuncString string
// log.Println("SomeFuncString", SomeFuncString)
```

will be generated to the following snippet
```
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, we will go to __badTypeSomeFuncString,
thus, printing the following message:
"SomeFuncString" got value Hello_world of type "string" but expected type "string"

Reference:
- demo code https://github.com/henrybear327/gofail-perf-fix-demo/tree/issue/val_error
henrybear327 added a commit to henrybear327/gofail that referenced this pull request Apr 23, 2024
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]>
henrybear327 added a commit to henrybear327/gofail that referenced this pull request May 3, 2024
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]>
henrybear327 added a commit to henrybear327/gofail that referenced this pull request May 10, 2024
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants