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

About fatal error when triggering gc #2

Open
lynin opened this issue Nov 21, 2022 · 1 comment
Open

About fatal error when triggering gc #2

lynin opened this issue Nov 21, 2022 · 1 comment

Comments

@lynin
Copy link

lynin commented Nov 21, 2022

hello, I found a number of errors, which were seems concentrated in the gc of go runtime.

The following is a summary of the error messages:

1 =>
runtime: gp: gp=0xc00041e820, goid=347, gp->atomicstatus=1
runtime:  g:  g=0x1392220, goid=0,  g->atomicstatus=0
fatal error: bad g->status in ready

2 =>
fatal error: casgstatus: waiting for Gwaiting but is Grunnable

When I solved the above problems, the next fatal error came:

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x330 pc=0x1038847]

The error stack is too long, so complete information is not provided here🤔

BTW, The tested go version is 1.19.2 and 1.19.3

Here is my test code:

package itogami_test

import (
	"github.com/alphadose/itogami"
	"runtime/debug"
	"sync"
	"testing"
)

func doing() {
	times := 1000
	size := 100
	task := func(i int) {
		_ = i + 1
	}

	pool := itogami.NewPoolWithFunc(uint64(size), task)

	var wg sync.WaitGroup
	wg.Add(size)

	for i := 0; i < size; i++ {
		go func() {
			for n := 0; n < times; n++ {
				pool.Invoke(n)
			}
			wg.Done()
		}()
	}
	wg.Wait()
}

func TestTriggerGC(t *testing.T) {
	debug.SetMemoryLimit((1 << 20) * 100) // 100m

	for i := 0; i < 100; i++ {
		doing()
	}
}

Hope to get your help, thank you!

@alphadose
Copy link
Owner

@lynin this library is experimental as it tries to schedule and manage goroutines manually as can be seen in this line https://github.com/alphadose/itogami/blob/master/lib_runtime_linkage.go#L160

Scheduling goroutines manually grants better performance than the golang runtime scheduler but it also doesn't play well with golang runtime because of some niche edge cases here and there leading to exceptions and crashes

The first error you posted occurs when a goroutine is scheduled to be ready at the same time a GC occurs leading to an exception in goroutine state
The second error occurs when a lot of goroutines are in waiting state and we do mcall(gosched_m) (runtime.GoSched()) https://github.com/alphadose/itogami/blob/master/pool.go#L50
As for the 3rd issue I am lacking a bit of context without the full error log hence I cannot comment on that

Ultimately this library is just a POC for a better golang scheduler and I have opened an issue for the same in golang core golang/go#53398

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants