[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x804907c]

[ddulesov]

on linux x86-32 platform get panic

sync/atomic.LoadUint64(0x1888b77c, 0x1, 0x101)
        /tmp/go/src/sync/atomic/asm_386.s:159 +0xb
gopkg.in/rana/ora%2ev4.(*Rset).Len(0x1888b720, 0x83773a8)
        /go/src/gopkg.in/rana/ora.v4/rset.go:122 +0x26

Rset.index field is not alignment on 64-bit boundary on x86
this issue explained https://golang.org/pkg/sync/atomic/#pkg-note-BUG

to reproduce bug

package main
import (
        "fmt"
        "sync/atomic"
)
type R struct {
        b       byte
        index  int64
}
func (r *R) bugtest(){
        atomic.AddInt64(&r.index, 1)
}
func main(){
        r := &R{index: -1}
        atomic.AddInt64(&r.index, 1)
        fmt.Printf("result %d", r.index)

        r.bugtest()
        fmt.Printf("result %d", r.index)
}

[tgulacsi]

Can you try to move Rset.index to the first position (before sync.Mutex)? If that works, I'll do it everywhere. ddulesov <notifications@github.com> ezt írta (időpont: 2017. ápr. 12., Sze, 16:53):

…

on linux x86-32 platform get panic sync/atomic.LoadUint64(0x1888b77c, 0x1, 0x101) /tmp/go/src/sync/atomic/asm_386.s:159 +0xbgopkg.in/rana/ora%2ev4.(*Rset).Len(0x1888b720, 0x83773a8) /go/src/gopkg.in/rana/ora.v4/rset.go:122 +0x26 Rset.index field is not alignment on 64-bit boundary on x86 this issue explained https://golang.org/pkg/sync/atomic/#pkg-note-BUG to reproduce bug package main import ( "fmt" "sync/atomic" ) type R struct { b byte index int64 } func (r *R) bugtest(){ atomic.AddInt64(&r.index, 1) } func main(){ r := &R{index: -1} atomic.AddInt64(&r.index, 1) fmt.Printf("result %d", r.index) r.bugtest() fmt.Printf("result %d", r.index) } — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#185>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPoSuLqFgDghTTojiRowfP8IYzBWBxPks5rvOVugaJpZM4M7ihK> .

[ddulesov]

it is not robust solution . go compiler can't give a guarantee that the hole Rset object wil always be aligned by 64-bit boundary on x86 platform. Also it can rearange fields in its inner structure . Why no use uint32 for index field and therefore 32-bit atomic operations?

…

On Wed, Apr 12, 2017 at 7:12 PM, Tamás Gulácsi ***@***.***> wrote: Can you try to move Rset.index to the first position (before sync.Mutex)? If that works, I'll do it everywhere. ddulesov ***@***.***> ezt írta (időpont: 2017. ápr. 12., Sze, 16:53): > on linux x86-32 platform get panic > > sync/atomic.LoadUint64(0x1888b77c, 0x1, 0x101) > /tmp/go/src/sync/atomic/asm_386.s:159 +0xbgopkg.in/rana/ora%2ev4.(* Rset).Len(0x1888b720, 0x83773a8) > /go/src/gopkg.in/rana/ora.v4/rset.go:122 +0x26 > > Rset.index field is not alignment on 64-bit boundary on x86 > this issue explained https://golang.org/pkg/sync/atomic/#pkg-note-BUG > > to reproduce bug > > package main > import ( > "fmt" > "sync/atomic" > ) > type R struct { > b byte > index int64 > } > func (r *R) bugtest(){ > atomic.AddInt64(&r.index, 1) > } > func main(){ > r := &R{index: -1} > atomic.AddInt64(&r.index, 1) > fmt.Printf("result %d", r.index) > > r.bugtest() > fmt.Printf("result %d", r.index) > } > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#185>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/ AAPoSuLqFgDghTTojiRowfP8IYzBWBxPks5rvOVugaJpZM4M7ihK> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#185 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AaF3WhaB8g9VCzMzKFSAgsEXdirdYODbks5rvPgEgaJpZM4M7ihK> .

[tgulacsi]

Using uint32 is enough, no field rearrange is needed? Maybe we can live with index turning around after 4 mrd rows. ddulesov <notifications@github.com> ezt írta (időpont: 2017. ápr. 13., Cs 8:37):

…

it is not robust solution . go compiler can't give a guarantee that the hole Rset object wil always be aligned by 64-bit boundary on x86 platform. Also it can rearange fields in its inner structure . Why no use uint32 for index field and therefore 32-bit atomic operations? On Wed, Apr 12, 2017 at 7:12 PM, Tamás Gulácsi ***@***.***> wrote: > Can you try to move Rset.index to the first position (before sync.Mutex)? > If that works, I'll do it everywhere. > > > ddulesov ***@***.***> ezt írta (időpont: 2017. ápr. 12., > Sze, > 16:53): > > > on linux x86-32 platform get panic > > > > sync/atomic.LoadUint64(0x1888b77c, 0x1, 0x101) > > /tmp/go/src/sync/atomic/asm_386.s:159 +0xbgopkg.in/rana/ora%2ev4.(* > Rset).Len(0x1888b720, 0x83773a8) > > /go/src/gopkg.in/rana/ora.v4/rset.go:122 +0x26 > > > > Rset.index field is not alignment on 64-bit boundary on x86 > > this issue explained https://golang.org/pkg/sync/atomic/#pkg-note-BUG > > > > to reproduce bug > > > > package main > > import ( > > "fmt" > > "sync/atomic" > > ) > > type R struct { > > b byte > > index int64 > > } > > func (r *R) bugtest(){ > > atomic.AddInt64(&r.index, 1) > > } > > func main(){ > > r := &R{index: -1} > > atomic.AddInt64(&r.index, 1) > > fmt.Printf("result %d", r.index) > > > > r.bugtest() > > fmt.Printf("result %d", r.index) > > } > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub > > <#185>, or mute the thread > > <https://github.com/notifications/unsubscribe-auth/ > AAPoSuLqFgDghTTojiRowfP8IYzBWBxPks5rvOVugaJpZM4M7ihK> > > . > > > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#185 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AaF3WhaB8g9VCzMzKFSAgsEXdirdYODbks5rvPgEgaJpZM4M7ihK > > . > — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#185 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPoSjKXF9B2zjhhAPxYY_m9C6Vd78beks5rvcKlgaJpZM4M7ihK> .

[ddulesov]

Maybe we can live with index turning around after 4 mrd rows

oci library operate with ub4 (4 byte) data length. so resulting recordset can't be more then max( ub4_type ) as for me. I replace Rset.index with int32 and call atomic.AddInt32. It works on my linux x86. golang specification https://golang.org/ref/spec#Package_unsafe doesn't give clear aboute field order and alignment on any platform. but int32 should be always 32-bit aligned on x86 arch On Thu, Apr 13, 2017 at 9:52 AM, Tamás Gulácsi <notifications@github.com> wrote:

…

Using uint32 is enough, no field rearrange is needed? Maybe we can live with index turning around after 4 mrd rows. ddulesov ***@***.***> ezt írta (időpont: 2017. ápr. 13., Cs 8:37): > it is not robust solution . go compiler can't give a guarantee that the > hole Rset object wil always be aligned by 64-bit boundary on x86 platform. > Also it can rearange fields in its inner structure . Why no use uint32 for > index field and therefore 32-bit atomic operations? > > > > On Wed, Apr 12, 2017 at 7:12 PM, Tamás Gulácsi ***@***.*** > > wrote: > > > Can you try to move Rset.index to the first position (before sync.Mutex)? > > If that works, I'll do it everywhere. > > > > > > ddulesov ***@***.***> ezt írta (időpont: 2017. ápr. 12., > > Sze, > > 16:53): > > > > > on linux x86-32 platform get panic > > > > > > sync/atomic.LoadUint64(0x1888b77c, 0x1, 0x101) > > > /tmp/go/src/sync/atomic/asm_386.s:159 +0xbgopkg.in/rana/ora%2ev4.(* > > Rset).Len(0x1888b720, 0x83773a8) > > > /go/src/gopkg.in/rana/ora.v4/rset.go:122 +0x26 > > > > > > Rset.index field is not alignment on 64-bit boundary on x86 > > > this issue explained https://golang.org/pkg/sync/ atomic/#pkg-note-BUG > > > > > > to reproduce bug > > > > > > package main > > > import ( > > > "fmt" > > > "sync/atomic" > > > ) > > > type R struct { > > > b byte > > > index int64 > > > } > > > func (r *R) bugtest(){ > > > atomic.AddInt64(&r.index, 1) > > > } > > > func main(){ > > > r := &R{index: -1} > > > atomic.AddInt64(&r.index, 1) > > > fmt.Printf("result %d", r.index) > > > > > > r.bugtest() > > > fmt.Printf("result %d", r.index) > > > } > > > > > > — > > > You are receiving this because you are subscribed to this thread. > > > Reply to this email directly, view it on GitHub > > > <#185>, or mute the thread > > > <https://github.com/notifications/unsubscribe-auth/ > > AAPoSuLqFgDghTTojiRowfP8IYzBWBxPks5rvOVugaJpZM4M7ihK> > > > . > > > > > > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub > > <#185 (comment)>, or mute > > the thread > > < > https://github.com/notifications/unsubscribe-auth/ AaF3WhaB8g9VCzMzKFSAgsEXdirdYODbks5rvPgEgaJpZM4M7ihK > > > > . > > > > — > You are receiving this because you modified the open/close state. > > > Reply to this email directly, view it on GitHub > <#185 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe- auth/AAPoSjKXF9B2zjhhAPxYY_m9C6Vd78beks5rvcKlgaJpZM4M7ihK> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#185 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AaF3WiXQh5rZ2eYsZO4wDd6HfC4Nm9qzks5rvcZBgaJpZM4M7ihK> .