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.

Sign up for GitHub

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

Jump to bottom

CI random failure: invalid memory address or nil pointer dereference: leveldb.(*DB).isClosed(...) #20380

Closed
wxiaoguang opened this issue Jul 15, 2022 · 2 comments · Fixed by #20534
Closed

CI random failure: invalid memory address or nil pointer dereference: leveldb.(*DB).isClosed(...) #20380

wxiaoguang opened this issue Jul 15, 2022 · 2 comments · Fixed by #20534
Labels
type/testing

Comments

@wxiaoguang
Copy link
Contributor

wxiaoguang commented Jul 15, 2022 •
edited
Loading

https://drone.gitea.io/go-gitea/gitea/57643/2/12

(Hmm ... duplicated with #19957)

2022/07/15 07:13:08 ...ueue_channel_test.go:170:func3() [I] Finally terminating
2022/07/15 07:13:08 ...eue/queue_channel.go:154:func1() [W] ChannelQueue:  Terminated before completed flushing
2022/07/15 07:13:08 ...eue/queue_channel.go:154:func1() [W] ChannelQueue: first-channel Terminated before completed flushing
2022/07/15 07:13:08 ...eue/queue_channel.go:154:func1() [W] ChannelQueue: second-channel Terminated before completed flushing
2022/07/15 07:13:08 ...ueue_disk_channel.go:185:func3() [W] [62d11384-3] LevelQueue: second-level shut down before completely flushed
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xc893a1]

goroutine 136 [running]:
github.com/syndtr/goleveldb/leveldb.(*DB).isClosed(...)
	/go/pkg/mod/github.com/syndtr/goleveldb@v1.0.0/leveldb/db_state.go:230
github.com/syndtr/goleveldb/leveldb.(*DB).ok(...)
	/go/pkg/mod/github.com/syndtr/goleveldb@v1.0.0/leveldb/db_state.go:235
github.com/syndtr/goleveldb/leveldb.(*DB).Get(0x0, {0xc000143a98, 0x8, 0x8}, 0xc0003221e8?)
	/go/pkg/mod/github.com/syndtr/goleveldb@v1.0.0/leveldb/db.go:838 +0x81
gitea.com/lunny/levelqueue.(*Queue).RPop(0xc0001f4080)
	/go/pkg/mod/gitea.com/lunny/levelqueue@v0.4.1/queue.go:198 +0x327
code.gitea.io/gitea/modules/queue.(*LevelQueueByteFIFO).Pop(0xc0001b6168, {0x0?, 0x3?})
	/drone/src/modules/queue/queue_disk.go:104 +0x52
code.gitea.io/gitea/modules/queue.(*ByteFIFOQueue).doPop(0xc0003121e0)
	/drone/src/modules/queue/queue_bytefifo.go:299 +0x128
code.gitea.io/gitea/modules/queue.(*ByteFIFOQueue).readToChan(0xc0003121e0)
	/drone/src/modules/queue/queue_bytefifo.go:234 +0x7e5
code.gitea.io/gitea/modules/queue.(*ByteFIFOQueue).Run(0xc0003121e0, 0x10e12a8, 0x10e12b0)
	/drone/src/modules/queue/queue_bytefifo.go:164 +0x413
created by code.gitea.io/gitea/modules/queue.(*PersistableChannelQueue).Run
	/drone/src/modules/queue/queue_disk_channel.go:178 +0x67d
FAIL	code.gitea.io/gitea/modules/queue	0.556s
@zeripath zeripath reopened this Jul 28, 2022
@zeripath
Copy link
Contributor

This still happens and I've finally managed to get round to working out why.

The problem is a bug I added in https://gitea.com/lunny/levelqueue

This will be fixed by https://gitea.com/lunny/levelqueue/pulls/6

Once merged we can go get -u gitea.com/lunny/levelqueue and then merge to fix this.

@lunny
Copy link
Member

lunny commented Jul 29, 2022

This still happens and I've finally managed to get round to working out why.

The problem is a bug I added in https://gitea.com/lunny/levelqueue

This will be fixed by https://gitea.com/lunny/levelqueue/pulls/6

Once merged we can go get -u gitea.com/lunny/levelqueue and then merge to fix this.

That PR merged.

zeripath added a commit to zeripath/gitea that referenced this issue Jul 29, 2022
@zeripath
Update lunny/levelqueue to prevent NPE when reads are performed after…
10ffb30 
… close

go-gitea#20380 reveals that there was a slight bug in the levelqueue code that assumed that
reads and write would not occur after the db is closed. This unfortunately cannot be
assumed, and if a read or write occured this would result in a NPE.

This bug has been fixed in f020868cc2f78a4bb0b110c4c232c74be048453e therefore this
PR updates Gitea to use this.

Fix go-gitea#20380

Signed-off-by: Andrew Thornton <art27@cantab.net>
@zeripath zeripath mentioned this issue Jul 29, 2022
Merged
@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
type/testing
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Update lunny/levelqueue to prevent NPE when reads are performed after close zeripath/gitea
3 participants
@lunny @zeripath @wxiaoguang