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 alignment in chunkedContentCoder #147

Merged
merged 1 commit into from
Nov 30, 2022
Merged

Fix alignment in chunkedContentCoder #147

merged 1 commit into from
Nov 30, 2022

Conversation

zeripath
Copy link
Contributor

An unaligned atomic bug was unfortunately introduced in #119 because the bytesWritten field was placed at the end of the chunkedContentCoder struct.

This places this after the bytes.Buffers and the bool causing it to be misaligned.

The ideal placement of this variable is not entirely clear but placing it before the progresiveWrite bool should help.

An alternative would be to just place this atomic field at the top of the struct then there would be no risk of it becoming misaligned in future.

I moved a few things around to reduce the size of the struct too but it could be possible to adjust things a little more to make the struct a little smaller.

Signed-off-by: Andrew Thornton art27@cantab.net

An unaligned atomic bug was unfortunately introduced in #119 because the
`bytesWritten` field was placed at the end of the `chunkedContentCoder`
struct.

This places this after the bytes.Buffers and the bool causing it to be
misaligned.

The ideal placement of this variable is not entirely clear but placing
it before the progresiveWrite bool should help.

An alternative would be to just place this atomic field at the top of
the struct then there would be no risk of it becoming misaligned in
future.

I moved a few things around to reduce the size of the struct too but it
could be possible to adjust things a little more to make the struct a
little smaller.

Signed-off-by: Andrew Thornton <art27@cantab.net>
@Thejas-bhat
Copy link
Contributor

Thejas-bhat commented Nov 21, 2022

Thanks you very much @zeripath for raising this bug. I'm not entirely sure about the specifics of the bug over here. However, it looks like the panic message that the user has posted in the issue go-gitea/gitea#21869 shows that the atomic.AddUint64() is the cause of panic.

goroutine 1098 [running]:
runtime/internal/atomic.panicUnaligned()
        /usr/local/go/src/runtime/internal/atomic/unaligned.go:8 +0x2d
runtime/internal/atomic.Xadd64(0x1d210df4, 0x8)
        /usr/local/go/src/runtime/internal/atomic/atomic_386.s:125 +0x11
github.com/blevesearch/zapx/v15.(*chunkedContentCoder).incrementBytesWritten(...)
        /go/pkg/mod/github.com/blevesearch/zapx/v15@v15.3.5/contentcoder.go:114

Now, I also observe that the version of the zapx and bleve used is 15.3.5 and 2.3.4 respectively.

        /go/pkg/mod/github.com/blevesearch/zapx/v15@v15.3.5/new.go:72 +0x18b
github.com/blevesearch/zapx/v15.(*ZapPlugin).New(0x5b887a4, {0x1e00d7a8, 0x1, 0x1})
        /go/pkg/mod/github.com/blevesearch/zapx/v15@v15.3.5/new.go:47 +0x43
github.com/blevesearch/bleve/v2/index/scorch.(*Scorch).Batch(0x1c937000, 0x1f7dea70)
        /go/pkg/mod/github.com/blevesearch/bleve/v2@v2.3.4/index/scorch/scorch.go:411 +0x5ff
github.com/blevesearch/bleve/v2.(*indexImpl).Batch(0x1bb045a0, 0x1e715d40)
        /go/pkg/mod/github.com/blevesearch/bleve/v2@v2.3.4/index_impl.go:309 +0xa0
code.gitea.io/gitea/modules/indexer/bleve.(*FlushingBatch).Flush(0x1adf1dc4)

These releases had the atomic operations in incrementBytesWritten method (which is why I'm assuming its failing). The upcoming release of bleve (2.3.6) will have the zapx tag 15.3.7 which avoids the atomic operations altogether. My thinking is that this issue won't occur when you use 2.3.6. However, if the issue still persists in that release, please go ahead create an issue or a PR (if you've verified a fix for the same) and add me as a reviewer for it.

Thank you!
Thejas

@abhinavdangeti abhinavdangeti merged commit e34dce0 into blevesearch:master Nov 30, 2022
@zeripath zeripath deleted the fix-alignment-chunkedContentCoder branch November 30, 2022 19:57
zeripath added a commit to zeripath/gitea that referenced this pull request Dec 4, 2022
There is an unaligned atomic field in zapx 15.3.5 which should have been fixed in blevesearch/zapx#147

This bug causes issues on 32bit builds.

Update bleve and zapx to account for this.

Fix go-gitea#21957

Signed-off-by: Andrew Thornton <art27@cantab.net>
cj123 added a commit to cj123/zapx that referenced this pull request Feb 17, 2023
Following the fix in blevesearch#147, a 'panic: unaligned 64-bit atomic operation' is
still occurring on some platforms.

As noted in blevesearch#147, this commit implements the alternative fix by placing the
bytesWritten field at the top of the struct. Per the Golang sync/atomic
documentation, on ARM, 386 and 32-bit MIPS systems, this is the reliable
way to prevent these issues.

Signed-off-by: Callum Jones <cj@icj.me>
cj123 added a commit to cj123/zapx that referenced this pull request Feb 17, 2023
Following the fix in blevesearch#147, a 'panic: unaligned 64-bit atomic operation' is
still occurring on some platforms.

As noted in blevesearch#147, this commit implements the alternative fix by placing the
bytesWritten field at the top of the struct. Per the Golang sync/atomic
documentation, on ARM, 386 and 32-bit MIPS systems, this is the reliable
way to prevent these issues.

Signed-off-by: Callum Jones <cj@icj.me>
abhinavdangeti pushed a commit that referenced this pull request Feb 21, 2023
…ms. (#148)

Following the fix in #147, a 'panic: unaligned 64-bit atomic operation' is
still occurring on some platforms.

As noted in #147, this commit implements the alternative fix by placing the
bytesWritten field at the top of the struct. Per the Golang sync/atomic
documentation, on ARM, 386 and 32-bit MIPS systems, this is the reliable
way to prevent these issues.

Signed-off-by: Callum Jones <cj@icj.me>
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

Successfully merging this pull request may close these issues.

3 participants