You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@arrow.apache.org by "joellubi (via GitHub)" <gi...@apache.org> on 2024/05/08 15:09:40 UTC
[I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
joellubi opened a new issue, #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841
### What happened?
When using both the snowflake driver and the flightsql driver in the same python program, the process crashes with a segmentation violation. Using one of these drivers at the same time as the postgres driver does not cause a crash, which makes it seem like there might be an issue in the common Go memory management of the snowflake and flightsql drivers.
### How can we reproduce the bug?
Minimal Reproduction:
```python
import adbc_driver_flightsql.dbapi
import adbc_driver_snowflake.dbapi
adbc_driver_flightsql.dbapi.connect("grpc+tcp://localhost:8080")
adbc_driver_snowflake.dbapi.connect()
```
Result:
```
[signal SIGSEGV: segmentation violation code=0x1 addr=0x14 pc=0x1636e3c9d]
goroutine 1 [running, locked to thread]:
runtime.throw({0x165155d38?, 0x1c0000061a0?})
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/panic.go:1077 +0x5c fp=0x1c000731e88 sp=0x1c000731e58 pc=0x163713c5c
runtime.sigpanic()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/signal_unix.go:845 +0x3e9 fp=0x1c000731ee8 sp=0x1c000731e88 pc=0x163729fe9
runtime.(*waitq).dequeue(...)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/chan.go:781
runtime.closechan(0x1c000182000)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/chan.go:380 +0x17d fp=0x1c000731f40 sp=0x1c000731ee8 pc=0x1636e3c9d
runtime.main()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:256 +0x28f fp=0x1c000731fe0 sp=0x1c000731f40 pc=0x16371664f
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c000731fe8 sp=0x1c000731fe0 pc=0x1637468c1
goroutine 2 [force gc (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000076fa8 sp=0x1c000076f88 pc=0x163716ace
runtime.goparkunlock(...)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:404
runtime.forcegchelper()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:322 +0xb3 fp=0x1c000076fe0 sp=0x1c000076fa8 pc=0x163716953
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c000076fe8 sp=0x1c000076fe0 pc=0x1637468c1
created by runtime.init.6 in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:310 +0x1a
goroutine 3 [GC sweep wait]:
runtime.gopark(0x1?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000077778 sp=0x1c000077758 pc=0x163716ace
runtime.goparkunlock(...)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:404
runtime.bgsweep(0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgcsweep.go:321 +0xdf fp=0x1c0000777c8 sp=0x1c000077778 pc=0x163702eff
runtime.gcenable.func1()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:200 +0x25 fp=0x1c0000777e0 sp=0x1c0000777c8 pc=0x1636f8025
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0000777e8 sp=0x1c0000777e0 pc=0x1637468c1
created by runtime.gcenable in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:200 +0x66
goroutine 4 [GC scavenge wait]:
runtime.gopark(0x1c00007e000?, 0x1653aa1b8?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000077f70 sp=0x1c000077f50 pc=0x163716ace
runtime.goparkunlock(...)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:404
runtime.(*scavengerState).park(0x16698b740)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgcscavenge.go:425 +0x49 fp=0x1c000077fa0 sp=0x1c000077f70 pc=0x163700749
runtime.bgscavenge(0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgcscavenge.go:658 +0x59 fp=0x1c000077fc8 sp=0x1c000077fa0 pc=0x163700cf9
runtime.gcenable.func2()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:201 +0x25 fp=0x1c000077fe0 sp=0x1c000077fc8 pc=0x1636f7fc5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c000077fe8 sp=0x1c000077fe0 pc=0x1637468c1
created by runtime.gcenable in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:201 +0xa5
goroutine 18 [finalizer wait]:
runtime.gopark(0x198?, 0x1657b6dc0?, 0x1?, 0x7c?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000076620 sp=0x1c000076600 pc=0x163716ace
runtime.runfinq()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mfinal.go:193 +0x107 fp=0x1c0000767e0 sp=0x1c000076620 pc=0x1636f7047
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0000767e8 sp=0x1c0000767e0 pc=0x1637468c1
created by runtime.createfing in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mfinal.go:163 +0x3d
goroutine 19 [GC worker (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000072750 sp=0x1c000072730 pc=0x163716ace
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c0000727e0 sp=0x1c000072750 pc=0x1636f9ba5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0000727e8 sp=0x1c0000727e0 pc=0x1637468c1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 20 [GC worker (idle)]:
runtime.gopark(0xaaf807b9a3a23?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000072f50 sp=0x1c000072f30 pc=0x163716ace
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c000072fe0 sp=0x1c000072f50 pc=0x1636f9ba5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c000072fe8 sp=0x1c000072fe0 pc=0x1637468c1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 34 [GC worker (idle)]:
runtime.gopark(0xaaf807b9a398a?, 0x3?, 0xde?, 0x37?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000508750 sp=0x1c000508730 pc=0x163716ace
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c0005087e0 sp=0x1c000508750 pc=0x1636f9ba5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0005087e8 sp=0x1c0005087e0 pc=0x1637468c1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 21 [GC worker (idle)]:
runtime.gopark(0xaaf807b9a3a29?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000073750 sp=0x1c000073730 pc=0x163716ace
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c0000737e0 sp=0x1c000073750 pc=0x1636f9ba5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0000737e8 sp=0x1c0000737e0 pc=0x1637468c1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 35 [GC worker (idle)]:
runtime.gopark(0x1669be420?, 0x3?, 0xd0?, 0xb5?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000508f50 sp=0x1c000508f30 pc=0x163716ace
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c000508fe0 sp=0x1c000508f50 pc=0x1636f9ba5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c000508fe8 sp=0x1c000508fe0 pc=0x1637468c1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 22 [GC worker (idle)]:
runtime.gopark(0xaaf807b9a36d1?, 0x3?, 0xf3?, 0xff?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000073f50 sp=0x1c000073f30 pc=0x163716ace
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c000073fe0 sp=0x1c000073f50 pc=0x1636f9ba5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c000073fe8 sp=0x1c000073fe0 pc=0x1637468c1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 36 [GC worker (idle)]:
runtime.gopark(0xaaf807b99e23f?, 0x1?, 0x87?, 0xd4?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000509750 sp=0x1c000509730 pc=0x163716ace
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c0005097e0 sp=0x1c000509750 pc=0x1636f9ba5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0005097e8 sp=0x1c0005097e0 pc=0x1637468c1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 23 [GC worker (idle)]:
runtime.gopark(0xaaf807baf3078?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000074750 sp=0x1c000074730 pc=0x163716ace
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c0000747e0 sp=0x1c000074750 pc=0x1636f9ba5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0000747e8 sp=0x1c0000747e0 pc=0x1637468c1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
```
### Environment/Setup
Reproduces with:
```toml
adbc-driver-snowflake = { file = "/path/to/adbc_driver_snowflake-1.0.0-py3-none-macosx_10_15_x86_64.whl" }
adbc-driver-flightsql = { file = "/path/to/adbc_driver_flightsql-1.0.0-py3-none-macosx_10_15_x86_64.whl" }
```
and:
```toml
adbc-driver-snowflake = "^0.11.0"
adbc-driver-flightsql = "^0.11.0"
```
Does NOT reproduce with:
```toml
adbc-driver-snowflake = "^0.10.0"
adbc-driver-flightsql = "^0.10.0"
```
However, as I've tried pushing against various edge cases I have been able to get some segmentation violations with `0.10.0` too, but haven't yet isolated the specific behavior that causes it in that version.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@arrow.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "zeroshade (via GitHub)" <gi...@apache.org>.
zeroshade commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101741262
Since this is a latent issue for quite some time, and at least up to this point it appears that our consumers don't yet tend to have multiple drivers in one process (or if they do, it's not on macos and isn't exhibiting the issue) I'm okay with this not being a release blocker. We're going to have to figure something out, but I think it's fine to release without a fix for this. Maybe we just add something to the documentation to point out the problem for now and note that we're working on it?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "zeroshade (via GitHub)" <gi...@apache.org>.
zeroshade commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2110465105
I'll definitely try to take a look at that sometime this week. It's an interesting idea, I'm just not sure whether or not it'll solve our problem here. If I look closely at our existing implementation, we do utilize `cgo.Handler` to avoid passing Go pointers directly to C. So unless I'm missing something, i'm pretty sure we're already doing this isolation (which may be why we're not seeing issues on other platforms, only on macos?)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "lidavidm (via GitHub)" <gi...@apache.org>.
lidavidm commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101727335
I think we're between a rock and a hard place here.
- C/C++ is not suitable for the Flight SQL driver because of libarrow/Protobuf/gRPC.
- C/C++ is not suitable for the Snowflake driver given gosnowflake is much better supported.
- Rust/C# are not quite there yet. (Also @CurtHagenlocher, would .NET have the same issues as Go above with multiple shared libraries and hence multiple runtimes in one process?)
I think the interim solution would be to build a "combined" driver that has both drivers in one library.
I'm hesitant to hold up the release though since this has been a latent issue for a while.
CC @zeroshade @kou @paleolimbot for opinions on the last part too.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "lidavidm (via GitHub)" <gi...@apache.org>.
lidavidm commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101697315
ok, looks like it does happen under rosetta
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "cocoa-xu (via GitHub)" <gi...@apache.org>.
cocoa-xu commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2102881122
> @cocoa-xu this will also affect BigQuery...it seems both C++ and Go have packaging issues here...
So I tried the following code on my x86_64 macOS and it will have the same crash:
## Minimal Reproduction:
```python3
import adbc_driver_snowflake.dbapi
import adbc_driver_bigquery.dbapi
adbc_driver_snowflake.dbapi.connect()
adbc_driver_bigquery.dbapi.connect()
```
## Result
<details>
<summary>Full logs</summary>
```
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x11 pc=0x1807d413d]
goroutine 1 [running, locked to thread]:
runtime.throw({0x18223ac23?, 0x1c0000061a0?})
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/panic.go:1077 +0x5c fp=0x1c00069be88 sp=0x1c00069be58 pc=0x18080387c
runtime.sigpanic()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/signal_unix.go:845 +0x3e9 fp=0x1c00069bee8 sp=0x1c00069be88 pc=0x180819c09
runtime.(*waitq).dequeue(...)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/chan.go:781
runtime.closechan(0x1c00010e000)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/chan.go:380 +0x15d fp=0x1c00069bf40 sp=0x1c00069bee8 pc=0x1807d413d
runtime.main()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:256 +0x28f fp=0x1c00069bfe0 sp=0x1c00069bf40 pc=0x18080626f
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c00069bfe8 sp=0x1c00069bfe0 pc=0x180836481
goroutine 2 [force gc (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000084fa8 sp=0x1c000084f88 pc=0x1808066ee
runtime.goparkunlock(...)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:404
runtime.forcegchelper()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:322 +0xb3 fp=0x1c000084fe0 sp=0x1c000084fa8 pc=0x180806573
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c000084fe8 sp=0x1c000084fe0 pc=0x180836481
created by runtime.init.6 in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:310 +0x1a
goroutine 3 [GC sweep wait]:
runtime.gopark(0x1?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000085778 sp=0x1c000085758 pc=0x1808066ee
runtime.goparkunlock(...)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:404
runtime.bgsweep(0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgcsweep.go:321 +0xdf fp=0x1c0000857c8 sp=0x1c000085778 pc=0x1807f2b1f
runtime.gcenable.func1()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:200 +0x25 fp=0x1c0000857e0 sp=0x1c0000857c8 pc=0x1807e7c45
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0000857e8 sp=0x1c0000857e0 pc=0x180836481
created by runtime.gcenable in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:200 +0x66
goroutine 4 [GC scavenge wait]:
runtime.gopark(0x1c0000a8000?, 0x18248b280?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000085f70 sp=0x1c000085f50 pc=0x1808066ee
runtime.goparkunlock(...)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:404
runtime.(*scavengerState).park(0x183a704c0)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgcscavenge.go:425 +0x49 fp=0x1c000085fa0 sp=0x1c000085f70 pc=0x1807f0369
runtime.bgscavenge(0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgcscavenge.go:658 +0x59 fp=0x1c000085fc8 sp=0x1c000085fa0 pc=0x1807f0919
runtime.gcenable.func2()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:201 +0x25 fp=0x1c000085fe0 sp=0x1c000085fc8 pc=0x1807e7be5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c000085fe8 sp=0x1c000085fe0 pc=0x180836481
created by runtime.gcenable in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:201 +0xa5
goroutine 18 [finalizer wait]:
runtime.gopark(0x198?, 0x182894fe0?, 0x1?, 0x78?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000084620 sp=0x1c000084600 pc=0x1808066ee
runtime.runfinq()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mfinal.go:193 +0x107 fp=0x1c0000847e0 sp=0x1c000084620 pc=0x1807e6c67
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0000847e8 sp=0x1c0000847e0 pc=0x180836481
created by runtime.createfing in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mfinal.go:163 +0x3d
goroutine 19 [GC worker (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000080750 sp=0x1c000080730 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c0000807e0 sp=0x1c000080750 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0000807e8 sp=0x1c0000807e0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 34 [GC worker (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000488750 sp=0x1c000488730 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c0004887e0 sp=0x1c000488750 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0004887e8 sp=0x1c0004887e0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 20 [GC worker (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000080f50 sp=0x1c000080f30 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c000080fe0 sp=0x1c000080f50 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c000080fe8 sp=0x1c000080fe0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 5 [GC worker (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000086750 sp=0x1c000086730 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c0000867e0 sp=0x1c000086750 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0000867e8 sp=0x1c0000867e0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 21 [GC worker (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000081750 sp=0x1c000081730 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c0000817e0 sp=0x1c000081750 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0000817e8 sp=0x1c0000817e0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 35 [GC worker (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000488f50 sp=0x1c000488f30 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c000488fe0 sp=0x1c000488f50 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c000488fe8 sp=0x1c000488fe0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 22 [GC worker (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000081f50 sp=0x1c000081f30 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c000081fe0 sp=0x1c000081f50 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c000081fe8 sp=0x1c000081fe0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 36 [GC worker (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000489750 sp=0x1c000489730 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c0004897e0 sp=0x1c000489750 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0004897e8 sp=0x1c0004897e0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 23 [GC worker (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000082750 sp=0x1c000082730 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c0000827e0 sp=0x1c000082750 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0000827e8 sp=0x1c0000827e0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 6 [GC worker (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000086f50 sp=0x1c000086f30 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c000086fe0 sp=0x1c000086f50 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c000086fe8 sp=0x1c000086fe0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 24 [GC worker (idle)]:
runtime.gopark(0x1bf65bd919377c?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000082f50 sp=0x1c000082f30 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c000082fe0 sp=0x1c000082f50 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c000082fe8 sp=0x1c000082fe0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 7 [GC worker (idle)]:
runtime.gopark(0x1bf65bd9172ab9?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000087750 sp=0x1c000087730 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c0000877e0 sp=0x1c000087750 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0000877e8 sp=0x1c0000877e0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 50 [GC worker (idle)]:
runtime.gopark(0x1bf65bd91727e7?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000484750 sp=0x1c000484730 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c0004847e0 sp=0x1c000484750 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c0004847e8 sp=0x1c0004847e0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 51 [GC worker (idle)]:
runtime.gopark(0x1bf65bd9172ca8?, 0x0?, 0x0?, 0x0?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000484f50 sp=0x1c000484f30 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c000484fe0 sp=0x1c000484f50 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c000484fe8 sp=0x1c000484fe0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 37 [GC worker (idle)]:
runtime.gopark(0x183aa3220?, 0x1?, 0x5a?, 0x31?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c000489f50 sp=0x1c000489f30 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c000489fe0 sp=0x1c000489f50 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c000489fe8 sp=0x1c000489fe0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
goroutine 38 [GC worker (idle)]:
runtime.gopark(0x1bf65bd919248e?, 0x1?, 0xf8?, 0x7d?, 0x0?)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:398 +0xce fp=0x1c00048a750 sp=0x1c00048a730 pc=0x1808066ee
runtime.gcBgMarkWorker()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1295 +0xe5 fp=0x1c00048a7e0 sp=0x1c00048a750 pc=0x1807e97c5
runtime.goexit()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/asm_amd64.s:1650 +0x1 fp=0x1c00048a7e8 sp=0x1c00048a7e0 pc=0x180836481
created by runtime.gcBgMarkStartWorkers in goroutine 1
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/mgc.go:1219 +0x1c
```
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "MichalStrehovsky (via GitHub)" <gi...@apache.org>.
MichalStrehovsky commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2108871073
> There would also need to be a way to dynamically register with a shared ADBC driver manager in-memory, because in this scenario there wouldn't be native entry points available for the drivers.
FWIW, C# without AOT compilation could use something like [DNNE](https://github.com/AaronRobinsonMSFT/DNNE) to create the native entrypoints. DNNE allows building native libraries with proper exports. Behind the scenes, the native library uses the .NET runtime hosting APIs to activate the runtime and call into managed code.
> EDIT: if you follow the links from that reply, you get a pretty sobering picture about the viability of loading multiple mid-to-heavy weight runtimes into the same process. I guess it's back to Rust, then ;).
As a sidenote, these problems are not unique to mid-to-heavy weight runtimes. Any time one loads a dynamic library with a different memory allocator, these problems can show up. They only don't show up if everyone agrees on using malloc/free from the same C runtime library. As soon as libraries start being fancy and each brings their own tcmalloc/jemalloc/whatever (and they often are), you now have multiple heaps with their own heuristics for expanding/giving memory back to the OS. (E.g. I don't know how Rust manages memory, but it's very likely each Rust DLL would have its own heap as well).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "lidavidm (via GitHub)" <gi...@apache.org>.
lidavidm commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2103611932
```
runtime.throw({0x18223ac23?, 0x1c0000061a0?})
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/panic.go:1077 +0x5c fp=0x1c00069be88 sp=0x1c00069be58 pc=0x18080387c
runtime.sigpanic()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/signal_unix.go:845 +0x3e9 fp=0x1c00069bee8 sp=0x1c00069be88 pc=0x180819c09
runtime.(*waitq).dequeue(...)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/chan.go:781
runtime.closechan(0x1c00010e000)
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/chan.go:380 +0x15d fp=0x1c00069bf40 sp=0x1c00069bee8 pc=0x1807d413d
runtime.main()
/Users/runner/hostedtoolcache/go/1.21.8/x64/src/runtime/proc.go:256 +0x28f fp=0x1c00069bfe0 sp=0x1c00069bf40 pc=0x18080626f
runtime.goexit()
/Users/runner/ho
```
`runtime.closechan(0x1c00010e000)` -> this is `close(main_init_done)` in the source. `main_init_done` is a global. I wonder if this is somehow getting shared between the runtimes on this platform?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "lidavidm (via GitHub)" <gi...@apache.org>.
lidavidm commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101728952
FWIW, the issue above also seems to indicate it can only be reproduced on amd64 macOS.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "CurtHagenlocher (via GitHub)" <gi...@apache.org>.
CurtHagenlocher commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2110576740
> (E.g. I don't know how Rust manages memory, but it's very likely each Rust DLL would have its own heap as well).
When you're building a DLL, the allocator in Rust defaults to using malloc on Unix platforms and HeapAlloc on Windows.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "lidavidm (via GitHub)" <gi...@apache.org>.
lidavidm commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101714617
However, debugging under rosetta is not working great as lldb appears to get stuck/execution appears to be extremely slow.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "lidavidm (via GitHub)" <gi...@apache.org>.
lidavidm commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101721566
I do also see that there are public symbols in the driver from cgo et al
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "lidavidm (via GitHub)" <gi...@apache.org>.
lidavidm commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101725021
https://github.com/golang/go/issues/65050
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "lidavidm (via GitHub)" <gi...@apache.org>.
lidavidm commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101687545
I don't get this (macOS aarch64) when building from main.
```
>>> import adbc_driver_flightsql.dbapi
>>> import adbc_driver_snowflake.dbapi
>>>
>>> adbc_driver_flightsql.dbapi.connect("grpc+tcp://localhost:8080")
/Users/lidavidm/Code/arrow-adbc/python/adbc_driver_manager/adbc_driver_manager/dbapi.py:307: Warning: Cannot disable autocommit; conn will not be DB-API 2.0 compliant
warnings.warn(
<adbc_driver_manager.dbapi.Connection object at 0x13cb4cb50>
>>> adbc_driver_snowflake.dbapi.connect()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/lidavidm/Code/arrow-adbc/python/adbc_driver_snowflake/adbc_driver_snowflake/dbapi.py", line 120, in connect
conn = adbc_driver_manager.AdbcConnection(db, **(conn_kwargs or {}))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "adbc_driver_manager/_lib.pyx", line 681, in adbc_driver_manager._lib.AdbcConnection.__init__
File "adbc_driver_manager/_lib.pyx", line 237, in adbc_driver_manager._lib.check_error
adbc_driver_manager.OperationalError: IO: 260000: account is empty
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "lidavidm (via GitHub)" <gi...@apache.org>.
lidavidm commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2102764177
I wonder, are you able to get a backtrace from lldb? Under rosetta it appears the Go runtime fails to initialize entirely (it appears to get stuck holding a lock) so I wasn't able to do so from an M1 machine.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "zeroshade (via GitHub)" <gi...@apache.org>.
zeroshade commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101769559
@paleolimbot depending on how R loads the module and it's dependencies, it might not be an issue with the static libs. If you load a bunch of static lib libraries, depending on how they are built, you might be able to only pull in one copy of the Go runtime. Potentially
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "joellubi (via GitHub)" <gi...@apache.org>.
joellubi commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101814609
I agree with moving forward with the release. Would it make sense to delay the 1.0.0 release until this is resolved, and instead release as 0.12.0?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "paleolimbot (via GitHub)" <gi...@apache.org>.
paleolimbot commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2102695586
I can reproduce this in R as well (but only on my very old x86 laptop):
```r
library(adbcdrivermanager)
flightsql <- adbc_database_init(
adbcflightsql::adbcflightsql(),
uri = "grpc+tcp://localhost:8080"
)
snowflake <- adbc_database_init(adbcsnowflake::adbcsnowflake())
```
I tried adding linker flags to suppress CGO symbols:
```
-Wl,-exported_symbol,_adbcflightsql_c_flightsql -Wl,-exported_symbol,_R_init_adbcflightsql
-Wl,-exported_symbol,_adbcsnowflake_c_adbcsnowflake -Wl,-exported_symbol,_R_init_adbcsnowflake
```
...and checked `nm --extern-only src/*.so` to make sure it worked, but I still get a crash.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "lidavidm (via GitHub)" <gi...@apache.org>.
lidavidm commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2105375548
One other nuclear option is to spawn a sacrificial process for each driver that loads the driver and communicates with the main process over some sort of IPC/shared memory, which at least for the data parts should be relatively OK as Arrow's shared memory support shapes up
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "paleolimbot (via GitHub)" <gi...@apache.org>.
paleolimbot commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2110532634
> why we're not seeing issues on other platforms, only on macos?
It's worth checking `clang` + libc++ on x86 linux, too (e.g., `docker run --rm ghcr.io/r-hub/containers/clang18`). It is a pretty exotic platform to find in the wild but would rule out if this is a MacOS problem or a clang/libc++ problem.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "zeroshade (via GitHub)" <gi...@apache.org>.
zeroshade commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101820430
@joellubi I don't think it's necessary to delay the 1.0.0 release of the couple of drivers we're doing so for. Since the issue is currently effectively limited to just amd64 Macos and in the most common use cases, users are more likely to be switching between drivers rather than using multiple drivers at the same time. With the doc update saying it's a known issue, I'm fine with moving forward as is.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "paleolimbot (via GitHub)" <gi...@apache.org>.
paleolimbot commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2102795356
Sure!
The non-lldbd backtrace from the R snippet above is:
<details>
```
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x16a pc=0x15319f145]
goroutine 1 gp=0x1c0000061c0 m=0 mp=0x15651e260 [running, locked to thread]:
runtime.throw({0x154c57751?, 0x153201786?})
/usr/local/go/src/runtime/panic.go:1023 +0x5c fp=0x1c000887e98 sp=0x1c000887e68 pc=0x1531d0b9c
runtime.sigpanic()
/usr/local/go/src/runtime/signal_unix.go:865 +0x3e9 fp=0x1c000887ef8 sp=0x1c000887e98 pc=0x1531e8b29
runtime.(*waitq).dequeue(...)
/usr/local/go/src/runtime/chan.go:794
runtime.closechan(0x1c000110000)
/usr/local/go/src/runtime/chan.go:380 +0x1c5 fp=0x1c000887f50 sp=0x1c000887ef8 pc=0x15319f145
runtime.main()
/usr/local/go/src/runtime/proc.go:260 +0x271 fp=0x1c000887fe0 sp=0x1c000887f50 pc=0x1531d3671
runtime.goexit({})
/usr/local/go/src/runtime/asm_amd64.s:1695 +0x1 fp=0x1c000887fe8 sp=0x1c000887fe0 pc=0x1532069e1
goroutine 2 gp=0x1c000006c40 m=nil [force gc (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/usr/local/go/src/runtime/proc.go:402 +0xce fp=0x1c000084fa8 sp=0x1c000084f88 pc=0x1531d3ace
runtime.goparkunlock(...)
/usr/local/go/src/runtime/proc.go:408
runtime.forcegchelper()
/usr/local/go/src/runtime/proc.go:326 +0xb3 fp=0x1c000084fe0 sp=0x1c000084fa8 pc=0x1531d3953
runtime.goexit({})
/usr/local/go/src/runtime/asm_amd64.s:1695 +0x1 fp=0x1c000084fe8 sp=0x1c000084fe0 pc=0x1532069e1
created by runtime.init.6 in goroutine 1
/usr/local/go/src/runtime/proc.go:314 +0x1a
goroutine 3 gp=0x1c000007180 m=nil [GC sweep wait]:
runtime.gopark(0x1?, 0x0?, 0x0?, 0x0?, 0x0?)
/usr/local/go/src/runtime/proc.go:402 +0xce fp=0x1c000085780 sp=0x1c000085760 pc=0x1531d3ace
runtime.goparkunlock(...)
/usr/local/go/src/runtime/proc.go:408
runtime.bgsweep(0x1c000050070)
/usr/local/go/src/runtime/mgcsweep.go:318 +0xdf fp=0x1c0000857c8 sp=0x1c000085780 pc=0x1531bf69f
runtime.gcenable.gowrap1()
/usr/local/go/src/runtime/mgc.go:203 +0x25 fp=0x1c0000857e0 sp=0x1c0000857c8 pc=0x1531b3f85
runtime.goexit({})
/usr/local/go/src/runtime/asm_amd64.s:1695 +0x1 fp=0x1c0000857e8 sp=0x1c0000857e0 pc=0x1532069e1
created by runtime.gcenable in goroutine 1
/usr/local/go/src/runtime/mgc.go:203 +0x66
goroutine 4 gp=0x1c000007340 m=nil [GC scavenge wait]:
runtime.gopark(0x10000?, 0x154eb6c20?, 0x0?, 0x0?, 0x0?)
/usr/local/go/src/runtime/proc.go:402 +0xce fp=0x1c000085f78 sp=0x1c000085f58 pc=0x1531d3ace
runtime.goparkunlock(...)
/usr/local/go/src/runtime/proc.go:408
runtime.(*scavengerState).park(0x15651c1c0)
/usr/local/go/src/runtime/mgcscavenge.go:425 +0x49 fp=0x1c000085fa8 sp=0x1c000085f78 pc=0x1531bd029
runtime.bgscavenge(0x1c000050070)
/usr/local/go/src/runtime/mgcscavenge.go:658 +0x59 fp=0x1c000085fc8 sp=0x1c000085fa8 pc=0x1531bd5d9
runtime.gcenable.gowrap2()
/usr/local/go/src/runtime/mgc.go:204 +0x25 fp=0x1c000085fe0 sp=0x1c000085fc8 pc=0x1531b3f25
runtime.goexit({})
/usr/local/go/src/runtime/asm_amd64.s:1695 +0x1 fp=0x1c000085fe8 sp=0x1c000085fe0 pc=0x1532069e1
created by runtime.gcenable in goroutine 1
/usr/local/go/src/runtime/mgc.go:204 +0xa5
goroutine 18 gp=0x1c000104700 m=nil [finalizer wait]:
runtime.gopark(0x1c000084648?, 0x1531a71a5?, 0xa8?, 0x1?, 0x1c0000061c0?)
/usr/local/go/src/runtime/proc.go:402 +0xce fp=0x1c000084620 sp=0x1c000084600 pc=0x1531d3ace
runtime.runfinq()
/usr/local/go/src/runtime/mfinal.go:194 +0x107 fp=0x1c0000847e0 sp=0x1c000084620 pc=0x1531b2fc7
runtime.goexit({})
/usr/local/go/src/runtime/asm_amd64.s:1695 +0x1 fp=0x1c0000847e8 sp=0x1c0000847e0 pc=0x1532069e1
created by runtime.createfing in goroutine 1
/usr/local/go/src/runtime/mfinal.go:164 +0x3d
goroutine 19 gp=0x1c0001056c0 m=nil [GC worker (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/usr/local/go/src/runtime/proc.go:402 +0xce fp=0x1c000080750 sp=0x1c000080730 pc=0x1531d3ace
runtime.gcBgMarkWorker()
/usr/local/go/src/runtime/mgc.go:1310 +0xe5 fp=0x1c0000807e0 sp=0x1c000080750 pc=0x1531b6065
runtime.goexit({})
/usr/local/go/src/runtime/asm_amd64.s:1695 +0x1 fp=0x1c0000807e8 sp=0x1c0000807e0 pc=0x1532069e1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/usr/local/go/src/runtime/mgc.go:1234 +0x1c
goroutine 34 gp=0x1c000182000 m=nil [GC worker (idle)]:
runtime.gopark(0x5792f439807?, 0x3?, 0xb2?, 0x20?, 0x0?)
/usr/local/go/src/runtime/proc.go:402 +0xce fp=0x1c000188750 sp=0x1c000188730 pc=0x1531d3ace
runtime.gcBgMarkWorker()
/usr/local/go/src/runtime/mgc.go:1310 +0xe5 fp=0x1c0001887e0 sp=0x1c000188750 pc=0x1531b6065
runtime.goexit({})
/usr/local/go/src/runtime/asm_amd64.s:1695 +0x1 fp=0x1c0001887e8 sp=0x1c0001887e0 pc=0x1532069e1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/usr/local/go/src/runtime/mgc.go:1234 +0x1c
goroutine 35 gp=0x1c0001821c0 m=nil [GC worker (idle)]:
runtime.gopark(0x5792f45e8d5?, 0x3?, 0xd8?, 0x9?, 0x0?)
/usr/local/go/src/runtime/proc.go:402 +0xce fp=0x1c000188f50 sp=0x1c000188f30 pc=0x1531d3ace
runtime.gcBgMarkWorker()
/usr/local/go/src/runtime/mgc.go:1310 +0xe5 fp=0x1c000188fe0 sp=0x1c000188f50 pc=0x1531b6065
runtime.goexit({})
/usr/local/go/src/runtime/asm_amd64.s:1695 +0x1 fp=0x1c000188fe8 sp=0x1c000188fe0 pc=0x1532069e1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/usr/local/go/src/runtime/mgc.go:1234 +0x1c
goroutine 20 gp=0x1c000105880 m=nil [GC worker (idle)]:
runtime.gopark(0x5792f4283d8?, 0x0?, 0x0?, 0x0?, 0x0?)
/usr/local/go/src/runtime/proc.go:402 +0xce fp=0x1c000080f50 sp=0x1c000080f30 pc=0x1531d3ace
runtime.gcBgMarkWorker()
/usr/local/go/src/runtime/mgc.go:1310 +0xe5 fp=0x1c000080fe0 sp=0x1c000080f50 pc=0x1531b6065
runtime.goexit({})
/usr/local/go/src/runtime/asm_amd64.s:1695 +0x1 fp=0x1c000080fe8 sp=0x1c000080fe0 pc=0x1532069e1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/usr/local/go/src/runtime/mgc.go:1234 +0x1c
goroutine 5 gp=0x1c000007880 m=nil [GC worker (idle)]:
runtime.gopark(0x156581540?, 0x1?, 0xc9?, 0x3b?, 0x0?)
/usr/local/go/src/runtime/proc.go:402 +0xce fp=0x1c000086750 sp=0x1c000086730 pc=0x1531d3ace
runtime.gcBgMarkWorker()
/usr/local/go/src/runtime/mgc.go:1310 +0xe5 fp=0x1c0000867e0 sp=0x1c000086750 pc=0x1531b6065
runtime.goexit({})
/usr/local/go/src/runtime/asm_amd64.s:1695 +0x1 fp=0x1c0000867e8 sp=0x1c0000867e0 pc=0x1532069e1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/usr/local/go/src/runtime/mgc.go:1234 +0x1c
goroutine 21 gp=0x1c000105a40 m=nil [GC worker (idle)]:
runtime.gopark(0x5792f42850a?, 0x3?, 0xa1?, 0x3?, 0x0?)
/usr/local/go/src/runtime/proc.go:402 +0xce fp=0x1c000081750 sp=0x1c000081730 pc=0x1531d3ace
runtime.gcBgMarkWorker()
/usr/local/go/src/runtime/mgc.go:1310 +0xe5 fp=0x1c0000817e0 sp=0x1c000081750 pc=0x1531b6065
runtime.goexit({})
/usr/local/go/src/runtime/asm_amd64.s:1695 +0x1 fp=0x1c0000817e8 sp=0x1c0000817e0 pc=0x1532069e1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/usr/local/go/src/runtime/mgc.go:1234 +0x1c
goroutine 6 gp=0x1c000007a40 m=nil [GC worker (idle)]:
runtime.gopark(0x5792f424754?, 0x0?, 0x0?, 0x0?, 0x0?)
/usr/local/go/src/runtime/proc.go:402 +0xce fp=0x1c000086f50 sp=0x1c000086f30 pc=0x1531d3ace
runtime.gcBgMarkWorker()
/usr/local/go/src/runtime/mgc.go:1310 +0xe5 fp=0x1c000086fe0 sp=0x1c000086f50 pc=0x1531b6065
runtime.goexit({})
/usr/local/go/src/runtime/asm_amd64.s:1695 +0x1 fp=0x1c000086fe8 sp=0x1c000086fe0 pc=0x1532069e1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/usr/local/go/src/runtime/mgc.go:1234 +0x1c
goroutine 36 gp=0x1c000182380 m=nil [GC worker (idle)]:
runtime.gopark(0x156581540?, 0x3?, 0x83?, 0x84?, 0x0?)
/usr/local/go/src/runtime/proc.go:402 +0xce fp=0x1c000189750 sp=0x1c000189730 pc=0x1531d3ace
runtime.gcBgMarkWorker()
/usr/local/go/src/runtime/mgc.go:1310 +0xe5 fp=0x1c0001897e0 sp=0x1c000189750 pc=0x1531b6065
runtime.goexit({})
/usr/local/go/src/runtime/asm_amd64.s:1695 +0x1 fp=0x1c0001897e8 sp=0x1c0001897e0 pc=0x1532069e1
created by runtime.gcBgMarkStartWorkers in goroutine 1
/usr/local/go/src/runtime/mgc.go:1234 +0x1c
zsh: abort R
```
</details>
The visual version of what pops up in VSCode when I attach a debugger and trigger the crash:
<img width="449" alt="Screenshot 2024-05-09 at 11 34 34 AM" src="https://github.com/apache/arrow-adbc/assets/10995762/91ba8231-b0ad-447f-8b3f-20331a17a825">
The result of `bt all`:
<details>
```
bt all
thread #1, queue = 'com.apple.main-thread'
frame #0: 0x00007fff203b6cbe libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff203e9e49 libsystem_pthread.dylib`_pthread_cond_wait + 1298
frame #2: 0x0000000159b55830 adbcsnowflake.so`runtime.pthread_cond_wait_trampoline.abi0 at sys_darwin_amd64.s:470
frame #3: 0x0000000159b536bd adbcsnowflake.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #4: 0x0000000159b3f0fe adbcsnowflake.so`runtime.libcCall at sys_libc.go:49
frame #5: 0x0000000159b3eeae adbcsnowflake.so`runtime.pthread_cond_wait.abi0 at sys_darwin.go:507
frame #6: 0x0000000159b1acef adbcsnowflake.so`runtime.semasleep at os_darwin.go:71
frame #7: 0x0000000159af2432 adbcsnowflake.so`runtime.notesleep at lock_sema.go:183
frame #8: 0x0000000159b25813 adbcsnowflake.so`runtime.stoplockedm at proc.go:1761
frame #9: 0x0000000159b27b3a adbcsnowflake.so`runtime.schedule at proc.go:3847
frame #10: 0x0000000159b2818c adbcsnowflake.so`runtime.park_m at proc.go:4036
frame #11: 0x0000000159b5198e adbcsnowflake.so`runtime.mcall at asm_amd64.s:458
frame #12: 0x0000000159b20ace adbcsnowflake.so`runtime.gopark at proc.go:402
frame #13: 0x0000000159aec7df adbcsnowflake.so`runtime.chanrecv at chan.go:583
frame #14: 0x0000000159aec3f2 adbcsnowflake.so`runtime.chanrecv1 at chan.go:442
frame #15: 0x0000000159aea7db adbcsnowflake.so`runtime.cgocallbackg1 at cgocall.go:380
frame #16: 0x0000000159aea536 adbcsnowflake.so`runtime.cgocallbackg at cgocall.go:322
frame #17: 0x0000000159b561c9 adbcsnowflake.so`runtime.cgocallbackg.abi0 at <autogenerated>:1
frame #18: 0x0000000159b537ac adbcsnowflake.so`runtime.cgocallback.abi0 at asm_amd64.s:1079
frame #19: 0x0000000159b6ac61 adbcsnowflake.so`crosscall2 at asm_amd64.s:43
thread #2
frame #0: 0x00007fff203b6b92 libsystem_kernel.dylib`__semwait_signal + 10
frame #1: 0x00007fff20336c1a libsystem_c.dylib`nanosleep + 196
frame #2: 0x000000011135358a cli.so`clic_thread_func(arg=<unavailable>) at thread.c:37:5 [opt]
frame #3: 0x00007fff203e98fc libsystem_pthread.dylib`_pthread_start + 224
frame #4: 0x00007fff203e5443 libsystem_pthread.dylib`thread_start + 15
thread #3
frame #0: 0x00007fff203b6cbe libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff203e9e49 libsystem_pthread.dylib`_pthread_cond_wait + 1298
frame #2: 0x0000000111e3b8d0 adbcflightsql.so`runtime.pthread_cond_wait_trampoline.abi0 at sys_darwin_amd64.s:470
frame #3: 0x0000000111e3977d adbcflightsql.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #4: 0x0000000111e254fe adbcflightsql.so`runtime.libcCall at sys_libc.go:49
frame #5: 0x0000000111e252ae adbcflightsql.so`runtime.pthread_cond_wait.abi0 at sys_darwin.go:507
frame #6: 0x0000000111e013af adbcflightsql.so`runtime.semasleep at os_darwin.go:71
frame #7: 0x0000000111dd93b2 adbcflightsql.so`runtime.notesleep at lock_sema.go:183
frame #8: 0x0000000111e0b50c adbcflightsql.so`runtime.stopm at proc.go:1761
frame #9: 0x0000000111e0c01e adbcflightsql.so`runtime.startlockedm at proc.go:3054
frame #10: 0x0000000111e0e10a adbcflightsql.so`runtime.schedule at proc.go:3914
frame #11: 0x0000000111e0eff8 adbcflightsql.so`runtime.goexit0 at proc.go:4181
frame #12: 0x0000000111e37a4e adbcflightsql.so`runtime.mcall at asm_amd64.s:458
frame #13: 0x0000000111e0efbd adbcflightsql.so`runtime.goexit1 at proc.go:4175
frame #14: 0x0000000111e39aa6 adbcflightsql.so`runtime.goexit.abi0 at asm_amd64.s:1696
thread #4
frame #0: 0x00007fff203b6cbe libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff203e9e7f libsystem_pthread.dylib`_pthread_cond_wait + 1352
frame #2: 0x0000000111e3b8f4 adbcflightsql.so`runtime.pthread_cond_timedwait_relative_np_trampoline.abi0 at sys_darwin_amd64.s:477
frame #3: 0x0000000111e3977d adbcflightsql.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #4: 0x0000000111e254fe adbcflightsql.so`runtime.libcCall at sys_libc.go:49
frame #5: 0x0000000111e2530e adbcflightsql.so`runtime.pthread_cond_timedwait_relative_np.abi0 at sys_darwin.go:517
frame #6: 0x0000000111e01450 adbcflightsql.so`runtime.semasleep at os_darwin.go:65
frame #7: 0x0000000111dd9548 adbcflightsql.so`runtime.notetsleep_internal at lock_sema.go:234
frame #8: 0x0000000111dd96ff adbcflightsql.so`runtime.notetsleep at lock_sema.go:285
frame #9: 0x0000000111e132e6 adbcflightsql.so`runtime.sysmon at proc.go:6001
frame #10: 0x0000000111e09c73 adbcflightsql.so`runtime.mstart1 at proc.go:1729
frame #11: 0x0000000111e09bca adbcflightsql.so`runtime.mstart0 at proc.go:1686
frame #12: 0x0000000111e379c5 adbcflightsql.so`runtime.mstart.abi0 at asm_amd64.s:394
frame #13: 0x00000001124fa1e3 adbcflightsql.so`crosscall1 + 20
frame #14: 0x00000001124f9c84 adbcflightsql.so`threadentry + 68
frame #15: 0x00007fff203e98fc libsystem_pthread.dylib`_pthread_start + 224
frame #16: 0x00007fff203e5443 libsystem_pthread.dylib`thread_start + 15
thread #5
frame #0: 0x00007fff203b6cbe libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff203e9e49 libsystem_pthread.dylib`_pthread_cond_wait + 1298
frame #2: 0x0000000111e3b8d0 adbcflightsql.so`runtime.pthread_cond_wait_trampoline.abi0 at sys_darwin_amd64.s:470
frame #3: 0x0000000111e3977d adbcflightsql.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #4: 0x0000000111e254fe adbcflightsql.so`runtime.libcCall at sys_libc.go:49
frame #5: 0x0000000111e252ae adbcflightsql.so`runtime.pthread_cond_wait.abi0 at sys_darwin.go:507
frame #6: 0x0000000111e013af adbcflightsql.so`runtime.semasleep at os_darwin.go:71
frame #7: 0x0000000111dd93b2 adbcflightsql.so`runtime.notesleep at lock_sema.go:183
frame #8: 0x0000000111e0b50c adbcflightsql.so`runtime.stopm at proc.go:1761
frame #9: 0x0000000111e0d07f adbcflightsql.so`runtime.findRunnable at proc.go:3512
frame #10: 0x0000000111e0e151 adbcflightsql.so`runtime.schedule at proc.go:3868
frame #11: 0x0000000111e0e72c adbcflightsql.so`runtime.park_m at proc.go:4036
frame #12: 0x0000000111e37a4e adbcflightsql.so`runtime.mcall at asm_amd64.s:458
frame #13: 0x0000000111e0706e adbcflightsql.so`runtime.gopark at proc.go:402
frame #14: 0x0000000111de66a7 adbcflightsql.so`runtime.runfinq at mfinal.go:194
frame #15: 0x0000000111e39aa1 adbcflightsql.so`runtime.goexit.abi0 at asm_amd64.s:1695
thread #6
frame #0: 0x00007fff203b6cbe libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff203e9e49 libsystem_pthread.dylib`_pthread_cond_wait + 1298
frame #2: 0x0000000111e3b8d0 adbcflightsql.so`runtime.pthread_cond_wait_trampoline.abi0 at sys_darwin_amd64.s:470
frame #3: 0x0000000111e3977d adbcflightsql.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #4: 0x0000000111e254fe adbcflightsql.so`runtime.libcCall at sys_libc.go:49
frame #5: 0x0000000111e252ae adbcflightsql.so`runtime.pthread_cond_wait.abi0 at sys_darwin.go:507
frame #6: 0x0000000111e013af adbcflightsql.so`runtime.semasleep at os_darwin.go:71
frame #7: 0x0000000111dd93b2 adbcflightsql.so`runtime.notesleep at lock_sema.go:183
frame #8: 0x0000000111e0b50c adbcflightsql.so`runtime.stopm at proc.go:1761
frame #9: 0x0000000111e0d07f adbcflightsql.so`runtime.findRunnable at proc.go:3512
frame #10: 0x0000000111e0e151 adbcflightsql.so`runtime.schedule at proc.go:3868
frame #11: 0x0000000111e0e72c adbcflightsql.so`runtime.park_m at proc.go:4036
frame #12: 0x0000000111e37a4e adbcflightsql.so`runtime.mcall at asm_amd64.s:458
frame #13: 0x0000000111e0706e adbcflightsql.so`runtime.gopark at proc.go:402
frame #14: 0x0000000111df0709 adbcflightsql.so`runtime.(*scavengerState).park at proc.go:408
frame #15: 0x0000000111df0c9c adbcflightsql.so`runtime.bgscavenge at mgcscavenge.go:653
frame #16: 0x0000000111de7605 adbcflightsql.so`runtime.gcenable.gowrap2 at mgc.go:204
frame #17: 0x0000000111e39aa1 adbcflightsql.so`runtime.goexit.abi0 at asm_amd64.s:1695
thread #7
frame #0: 0x00007fff203b6cbe libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff203e9e49 libsystem_pthread.dylib`_pthread_cond_wait + 1298
frame #2: 0x0000000111e3b8d0 adbcflightsql.so`runtime.pthread_cond_wait_trampoline.abi0 at sys_darwin_amd64.s:470
frame #3: 0x0000000111e3977d adbcflightsql.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #4: 0x0000000111e254fe adbcflightsql.so`runtime.libcCall at sys_libc.go:49
frame #5: 0x0000000111e252ae adbcflightsql.so`runtime.pthread_cond_wait.abi0 at sys_darwin.go:507
frame #6: 0x0000000111e013af adbcflightsql.so`runtime.semasleep at os_darwin.go:71
frame #7: 0x0000000111dd93b2 adbcflightsql.so`runtime.notesleep at lock_sema.go:183
frame #8: 0x0000000111e0b50c adbcflightsql.so`runtime.stopm at proc.go:1761
frame #9: 0x0000000111e0d07f adbcflightsql.so`runtime.findRunnable at proc.go:3512
frame #10: 0x0000000111e0e151 adbcflightsql.so`runtime.schedule at proc.go:3868
frame #11: 0x0000000111e09cad adbcflightsql.so`runtime.mstart1 at proc.go:1736
frame #12: 0x0000000111e09bca adbcflightsql.so`runtime.mstart0 at proc.go:1686
frame #13: 0x0000000111e379c5 adbcflightsql.so`runtime.mstart.abi0 at asm_amd64.s:394
frame #14: 0x00000001124fa1e3 adbcflightsql.so`crosscall1 + 20
frame #15: 0x00000001124f9c84 adbcflightsql.so`threadentry + 68
frame #16: 0x00007fff203e98fc libsystem_pthread.dylib`_pthread_start + 224
frame #17: 0x00007fff203e5443 libsystem_pthread.dylib`thread_start + 15
thread #8
frame #0: 0x00007fff203b6cbe libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff203e9e49 libsystem_pthread.dylib`_pthread_cond_wait + 1298
frame #2: 0x0000000111e3b8d0 adbcflightsql.so`runtime.pthread_cond_wait_trampoline.abi0 at sys_darwin_amd64.s:470
frame #3: 0x0000000111e3977d adbcflightsql.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #4: 0x0000000111e254fe adbcflightsql.so`runtime.libcCall at sys_libc.go:49
frame #5: 0x0000000111e252ae adbcflightsql.so`runtime.pthread_cond_wait.abi0 at sys_darwin.go:507
frame #6: 0x0000000111e013af adbcflightsql.so`runtime.semasleep at os_darwin.go:71
frame #7: 0x0000000111dd93b2 adbcflightsql.so`runtime.notesleep at lock_sema.go:183
frame #8: 0x0000000111e0b3f1 adbcflightsql.so`runtime.templateThread at proc.go:2760
frame #9: 0x0000000111e09c73 adbcflightsql.so`runtime.mstart1 at proc.go:1729
frame #10: 0x0000000111e09bca adbcflightsql.so`runtime.mstart0 at proc.go:1686
frame #11: 0x0000000111e379c5 adbcflightsql.so`runtime.mstart.abi0 at asm_amd64.s:394
frame #12: 0x00000001124fa1e3 adbcflightsql.so`crosscall1 + 20
frame #13: 0x00000001124f9c84 adbcflightsql.so`threadentry + 68
frame #14: 0x00007fff203e98fc libsystem_pthread.dylib`_pthread_start + 224
frame #15: 0x00007fff203e5443 libsystem_pthread.dylib`thread_start + 15
* thread #9, stop reason = EXC_BAD_ACCESS (code=1, address=0x11)
* frame #0: 0x0000000159aec0fd adbcsnowflake.so`runtime.closechan at chan.go:781
frame #1: 0x0000000159b20671 adbcsnowflake.so`runtime.main at proc.go:260
frame #2: 0x0000000159b539e1 adbcsnowflake.so`runtime.goexit.abi0 at asm_amd64.s:1695
thread #10
frame #0: 0x00007fff203b6b92 libsystem_kernel.dylib`__semwait_signal + 10
frame #1: 0x00007fff20336c1a libsystem_c.dylib`nanosleep + 196
frame #2: 0x00007fff20336b14 libsystem_c.dylib`usleep + 53
frame #3: 0x0000000159b5556b adbcsnowflake.so`runtime.usleep_trampoline.abi0 at sys_darwin_amd64.s:320
frame #4: 0x0000000159b536bd adbcsnowflake.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #5: 0x0000000159b3f0fe adbcsnowflake.so`runtime.libcCall at sys_libc.go:49
frame #6: 0x0000000159b3e886 adbcsnowflake.so`runtime.usleep.abi0 at sys_darwin.go:302
frame #7: 0x0000000159b2cc25 adbcsnowflake.so`runtime.sysmon at proc.go:5965
frame #8: 0x0000000159b236d3 adbcsnowflake.so`runtime.mstart1 at proc.go:1729
frame #9: 0x0000000159b2362a adbcsnowflake.so`runtime.mstart0 at proc.go:1686
frame #10: 0x0000000159b51905 adbcsnowflake.so`runtime.mstart.abi0 at asm_amd64.s:394
frame #11: 0x000000015b56f603 adbcsnowflake.so`crosscall1 + 20
frame #12: 0x000000015b56f0a4 adbcsnowflake.so`threadentry + 68
frame #13: 0x00007fff203e98fc libsystem_pthread.dylib`_pthread_start + 224
frame #14: 0x00007fff203e5443 libsystem_pthread.dylib`thread_start + 15
thread #11
frame #0: 0x00007fff203b6cbe libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff203e9e49 libsystem_pthread.dylib`_pthread_cond_wait + 1298
frame #2: 0x0000000159b55830 adbcsnowflake.so`runtime.pthread_cond_wait_trampoline.abi0 at sys_darwin_amd64.s:470
frame #3: 0x0000000159b536bd adbcsnowflake.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #4: 0x0000000159b3f0fe adbcsnowflake.so`runtime.libcCall at sys_libc.go:49
frame #5: 0x0000000159b3eeae adbcsnowflake.so`runtime.pthread_cond_wait.abi0 at sys_darwin.go:507
frame #6: 0x0000000159b1acef adbcsnowflake.so`runtime.semasleep at os_darwin.go:71
frame #7: 0x0000000159af2432 adbcsnowflake.so`runtime.notesleep at lock_sema.go:183
frame #8: 0x0000000159b24f6c adbcsnowflake.so`runtime.stopm at proc.go:1761
frame #9: 0x0000000159b26adf adbcsnowflake.so`runtime.findRunnable at proc.go:3512
frame #10: 0x0000000159b27bb1 adbcsnowflake.so`runtime.schedule at proc.go:3868
frame #11: 0x0000000159b2818c adbcsnowflake.so`runtime.park_m at proc.go:4036
frame #12: 0x0000000159b5198e adbcsnowflake.so`runtime.mcall at asm_amd64.s:458
frame #13: 0x0000000159b20ace adbcsnowflake.so`runtime.gopark at proc.go:402
frame #14: 0x0000000159b03065 adbcsnowflake.so`runtime.gcBgMarkWorker at mgc.go:1310
frame #15: 0x0000000159b539e1 adbcsnowflake.so`runtime.goexit.abi0 at asm_amd64.s:1695
thread #12
frame #0: 0x00007fff203b6cbe libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff203e9e49 libsystem_pthread.dylib`_pthread_cond_wait + 1298
frame #2: 0x0000000159b55830 adbcsnowflake.so`runtime.pthread_cond_wait_trampoline.abi0 at sys_darwin_amd64.s:470
frame #3: 0x0000000159b536bd adbcsnowflake.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #4: 0x0000000159b3f0fe adbcsnowflake.so`runtime.libcCall at sys_libc.go:49
frame #5: 0x0000000159b3eeae adbcsnowflake.so`runtime.pthread_cond_wait.abi0 at sys_darwin.go:507
frame #6: 0x0000000159b1acef adbcsnowflake.so`runtime.semasleep at os_darwin.go:71
frame #7: 0x0000000159af2432 adbcsnowflake.so`runtime.notesleep at lock_sema.go:183
frame #8: 0x0000000159b24f6c adbcsnowflake.so`runtime.stopm at proc.go:1761
frame #9: 0x0000000159b26adf adbcsnowflake.so`runtime.findRunnable at proc.go:3512
frame #10: 0x0000000159b27bb1 adbcsnowflake.so`runtime.schedule at proc.go:3868
frame #11: 0x0000000159b2818c adbcsnowflake.so`runtime.park_m at proc.go:4036
frame #12: 0x0000000159b5198e adbcsnowflake.so`runtime.mcall at asm_amd64.s:458
frame #13: 0x0000000159b20ace adbcsnowflake.so`runtime.gopark at proc.go:402
frame #14: 0x0000000159b0c69f adbcsnowflake.so`runtime.bgsweep at proc.go:408
frame #15: 0x0000000159b00f85 adbcsnowflake.so`runtime.gcenable.gowrap1 at mgc.go:203
frame #16: 0x0000000159b539e1 adbcsnowflake.so`runtime.goexit.abi0 at asm_amd64.s:1695
thread #13
frame #0: 0x00007fff203b6cbe libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff203e9e49 libsystem_pthread.dylib`_pthread_cond_wait + 1298
frame #2: 0x0000000159b55830 adbcsnowflake.so`runtime.pthread_cond_wait_trampoline.abi0 at sys_darwin_amd64.s:470
frame #3: 0x0000000159b536bd adbcsnowflake.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #4: 0x0000000159b3f0fe adbcsnowflake.so`runtime.libcCall at sys_libc.go:49
frame #5: 0x0000000159b3eeae adbcsnowflake.so`runtime.pthread_cond_wait.abi0 at sys_darwin.go:507
frame #6: 0x0000000159b1acef adbcsnowflake.so`runtime.semasleep at os_darwin.go:71
frame #7: 0x0000000159af2432 adbcsnowflake.so`runtime.notesleep at lock_sema.go:183
frame #8: 0x0000000159b24f6c adbcsnowflake.so`runtime.stopm at proc.go:1761
frame #9: 0x0000000159b26adf adbcsnowflake.so`runtime.findRunnable at proc.go:3512
frame #10: 0x0000000159b27bb1 adbcsnowflake.so`runtime.schedule at proc.go:3868
frame #11: 0x0000000159b2818c adbcsnowflake.so`runtime.park_m at proc.go:4036
frame #12: 0x0000000159b5198e adbcsnowflake.so`runtime.mcall at asm_amd64.s:458
frame #13: 0x0000000159b20ace adbcsnowflake.so`runtime.gopark at proc.go:402
frame #14: 0x0000000159b03065 adbcsnowflake.so`runtime.gcBgMarkWorker at mgc.go:1310
frame #15: 0x0000000159b539e1 adbcsnowflake.so`runtime.goexit.abi0 at asm_amd64.s:1695
thread #14
frame #0: 0x00007fff203b6cbe libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff203e9e49 libsystem_pthread.dylib`_pthread_cond_wait + 1298
frame #2: 0x0000000159b55830 adbcsnowflake.so`runtime.pthread_cond_wait_trampoline.abi0 at sys_darwin_amd64.s:470
frame #3: 0x0000000159b536bd adbcsnowflake.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #4: 0x0000000159b3f0fe adbcsnowflake.so`runtime.libcCall at sys_libc.go:49
frame #5: 0x0000000159b3eeae adbcsnowflake.so`runtime.pthread_cond_wait.abi0 at sys_darwin.go:507
frame #6: 0x0000000159b1acef adbcsnowflake.so`runtime.semasleep at os_darwin.go:71
frame #7: 0x0000000159af2432 adbcsnowflake.so`runtime.notesleep at lock_sema.go:183
frame #8: 0x0000000159b24e51 adbcsnowflake.so`runtime.templateThread at proc.go:2760
frame #9: 0x0000000159b236d3 adbcsnowflake.so`runtime.mstart1 at proc.go:1729
frame #10: 0x0000000159b2362a adbcsnowflake.so`runtime.mstart0 at proc.go:1686
frame #11: 0x0000000159b51905 adbcsnowflake.so`runtime.mstart.abi0 at asm_amd64.s:394
frame #12: 0x000000015b56f603 adbcsnowflake.so`crosscall1 + 20
frame #13: 0x000000015b56f0a4 adbcsnowflake.so`threadentry + 68
frame #14: 0x00007fff203e98fc libsystem_pthread.dylib`_pthread_start + 224
frame #15: 0x00007fff203e5443 libsystem_pthread.dylib`thread_start + 15
thread #15
frame #0: 0x00007fff203b6cbe libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff203e9e49 libsystem_pthread.dylib`_pthread_cond_wait + 1298
frame #2: 0x0000000159b55830 adbcsnowflake.so`runtime.pthread_cond_wait_trampoline.abi0 at sys_darwin_amd64.s:470
frame #3: 0x0000000159b536bd adbcsnowflake.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #4: 0x0000000159b3f0fe adbcsnowflake.so`runtime.libcCall at sys_libc.go:49
frame #5: 0x0000000159b3eeae adbcsnowflake.so`runtime.pthread_cond_wait.abi0 at sys_darwin.go:507
frame #6: 0x0000000159b1acef adbcsnowflake.so`runtime.semasleep at os_darwin.go:71
frame #7: 0x0000000159af2432 adbcsnowflake.so`runtime.notesleep at lock_sema.go:183
frame #8: 0x0000000159b24f6c adbcsnowflake.so`runtime.stopm at proc.go:1761
frame #9: 0x0000000159b26adf adbcsnowflake.so`runtime.findRunnable at proc.go:3512
frame #10: 0x0000000159b27bb1 adbcsnowflake.so`runtime.schedule at proc.go:3868
frame #11: 0x0000000159b2818c adbcsnowflake.so`runtime.park_m at proc.go:4036
frame #12: 0x0000000159b5198e adbcsnowflake.so`runtime.mcall at asm_amd64.s:458
frame #13: 0x0000000159b20ace adbcsnowflake.so`runtime.gopark at proc.go:402
frame #14: 0x0000000159b03065 adbcsnowflake.so`runtime.gcBgMarkWorker at mgc.go:1310
frame #15: 0x0000000159b539e1 adbcsnowflake.so`runtime.goexit.abi0 at asm_amd64.s:1695
thread #16
frame #0: 0x00007fff203b6cbe libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff203e9e49 libsystem_pthread.dylib`_pthread_cond_wait + 1298
frame #2: 0x0000000159b55830 adbcsnowflake.so`runtime.pthread_cond_wait_trampoline.abi0 at sys_darwin_amd64.s:470
frame #3: 0x0000000159b536bd adbcsnowflake.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #4: 0x0000000159b3f0fe adbcsnowflake.so`runtime.libcCall at sys_libc.go:49
frame #5: 0x0000000159b3eeae adbcsnowflake.so`runtime.pthread_cond_wait.abi0 at sys_darwin.go:507
frame #6: 0x0000000159b1acef adbcsnowflake.so`runtime.semasleep at os_darwin.go:71
frame #7: 0x0000000159af2432 adbcsnowflake.so`runtime.notesleep at lock_sema.go:183
frame #8: 0x0000000159b24f6c adbcsnowflake.so`runtime.stopm at proc.go:1761
frame #9: 0x0000000159b26adf adbcsnowflake.so`runtime.findRunnable at proc.go:3512
frame #10: 0x0000000159b27bb1 adbcsnowflake.so`runtime.schedule at proc.go:3868
frame #11: 0x0000000159b2818c adbcsnowflake.so`runtime.park_m at proc.go:4036
frame #12: 0x0000000159b5198e adbcsnowflake.so`runtime.mcall at asm_amd64.s:458
frame #13: 0x0000000159b20ace adbcsnowflake.so`runtime.gopark at proc.go:402
frame #14: 0x0000000159b03065 adbcsnowflake.so`runtime.gcBgMarkWorker at mgc.go:1310
frame #15: 0x0000000159b539e1 adbcsnowflake.so`runtime.goexit.abi0 at asm_amd64.s:1695
thread #17
frame #0: 0x00007fff203b6cbe libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff203e9e49 libsystem_pthread.dylib`_pthread_cond_wait + 1298
frame #2: 0x0000000159b55830 adbcsnowflake.so`runtime.pthread_cond_wait_trampoline.abi0 at sys_darwin_amd64.s:470
frame #3: 0x0000000159b536bd adbcsnowflake.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #4: 0x0000000159b3f0fe adbcsnowflake.so`runtime.libcCall at sys_libc.go:49
frame #5: 0x0000000159b3eeae adbcsnowflake.so`runtime.pthread_cond_wait.abi0 at sys_darwin.go:507
frame #6: 0x0000000159b1acef adbcsnowflake.so`runtime.semasleep at os_darwin.go:71
frame #7: 0x0000000159af2432 adbcsnowflake.so`runtime.notesleep at lock_sema.go:183
frame #8: 0x0000000159b24f6c adbcsnowflake.so`runtime.stopm at proc.go:1761
frame #9: 0x0000000159b26adf adbcsnowflake.so`runtime.findRunnable at proc.go:3512
frame #10: 0x0000000159b27bb1 adbcsnowflake.so`runtime.schedule at proc.go:3868
frame #11: 0x0000000159b2818c adbcsnowflake.so`runtime.park_m at proc.go:4036
frame #12: 0x0000000159b5198e adbcsnowflake.so`runtime.mcall at asm_amd64.s:458
frame #13: 0x0000000159b20ace adbcsnowflake.so`runtime.gopark at proc.go:402
frame #14: 0x0000000159b03065 adbcsnowflake.so`runtime.gcBgMarkWorker at mgc.go:1310
frame #15: 0x0000000159b539e1 adbcsnowflake.so`runtime.goexit.abi0 at asm_amd64.s:1695
thread #18
frame #0: 0x00007fff203b6cbe libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fff203e9e49 libsystem_pthread.dylib`_pthread_cond_wait + 1298
frame #2: 0x0000000159b55830 adbcsnowflake.so`runtime.pthread_cond_wait_trampoline.abi0 at sys_darwin_amd64.s:470
frame #3: 0x0000000159b536bd adbcsnowflake.so`runtime.asmcgocall.abi0 at asm_amd64.s:946
frame #4: 0x0000000159b3f0fe adbcsnowflake.so`runtime.libcCall at sys_libc.go:49
frame #5: 0x0000000159b3eeae adbcsnowflake.so`runtime.pthread_cond_wait.abi0 at sys_darwin.go:507
frame #6: 0x0000000159b1acef adbcsnowflake.so`runtime.semasleep at os_darwin.go:71
frame #7: 0x0000000159af2432 adbcsnowflake.so`runtime.notesleep at lock_sema.go:183
frame #8: 0x0000000159b24f6c adbcsnowflake.so`runtime.stopm at proc.go:1761
frame #9: 0x0000000159b25a7e adbcsnowflake.so`runtime.startlockedm at proc.go:3054
frame #10: 0x0000000159b27b6a adbcsnowflake.so`runtime.schedule at proc.go:3914
frame #11: 0x0000000159b2818c adbcsnowflake.so`runtime.park_m at proc.go:4036
frame #12: 0x0000000159b5198e adbcsnowflake.so`runtime.mcall at asm_amd64.s:458
frame #13: 0x0000000159b20ace adbcsnowflake.so`runtime.gopark at proc.go:402
frame #14: 0x0000000159b03065 adbcsnowflake.so`runtime.gcBgMarkWorker at mgc.go:1310
frame #15: 0x0000000159b539e1 adbcsnowflake.so`runtime.goexit.abi0 at asm_amd64.s:1695
```
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "zeroshade (via GitHub)" <gi...@apache.org>.
zeroshade commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2112701370
If you're trying to use the drivers from Go, then it's unlikely to be related to this issue. Can you file a new issue for that SIGSEV?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "zeroshade (via GitHub)" <gi...@apache.org>.
zeroshade commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2129546034
Just to keep everyone apprised here, I'm gonna try posting in the #cgo and #darkarts channels on the Gopher slack to see if anyone might know of a workaround or other way to avoid this crash. Even though it is still not optimal to end up with multiple copies of the Go runtime in a single process, it would still be good to at least get it to not crash.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "joellubi (via GitHub)" <gi...@apache.org>.
joellubi commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2110414431
I've been doing some research into this and came across the following library: [gopy](https://github.com/go-python/gopy/tree/master). It's meant to generate and compile CGO and CPython extensions from a Go package. What's specifically interesting about it is the unique-handler approach it uses to avoid passing Go pointers directly to C. There's a brief description in the README and the actual handler implementation is in [handler.go](https://github.com/go-python/gopy/blob/master/gopyh/handle.go).
I'm still wrapping my head around what a specific implementation would look like, but I wonder if we could adopt a similar approach to isolate pointers within their respective Go runtimes. The actual memory we do want to share (arrays) should be allocated in C anyway via the CGO Mallocator, and with an approach like this all Go pointers are only accessed within the Go runtime via stub methods that delegate the actions to be done.
It's not super obvious how it does all this just by looking at the source code, but if you look at the code generated by running the "command line example" in the readme it makes the mechanism clearer.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "lidavidm (via GitHub)" <gi...@apache.org>.
lidavidm commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101719008
@zeroshade is there a problem perhaps with having two copies of the go runtime in one process?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "lidavidm (via GitHub)" <gi...@apache.org>.
lidavidm commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101690804
It also doesn't reproduce with the 0.11.0 wheels so this appears to be a macOS x64 issue, which is going to be difficult to debug as I only have an aarch64 machine.
Are you able to reproduce it on any other platforms?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "paleolimbot (via GitHub)" <gi...@apache.org>.
paleolimbot commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101759003
I agree that it is not a release blocker...the improvements to the individual drivers are (in my opinion) important to release whilst we improve the situation for using multiple drivers in one process. I do have an x86 mac locally that I might be use to iterate on some of this...in R we're using the c-static build mode instead of the c-shared one (but I assume we would have the same issue there).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "cocoa-xu (via GitHub)" <gi...@apache.org>.
cocoa-xu commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2102807656
> @cocoa-xu this will also affect BigQuery...it seems both C++ and Go have packaging issues here...
It appears to be so...
I have an x86_64 macOS so please let me know if there're anything I can help @lidavidm
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "cocoa-xu (via GitHub)" <gi...@apache.org>.
cocoa-xu commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2104542042
> I guess it's back to Rust, then ;).
Not quite sure if this is related, but it seems that we don't have an official port of gRPC for Rust yet: https://github.com/grpc/grpc/issues/9316
There're some open source gRPC wrappers used in production, but I'm not sure if they can be loaded from different shared libraries without issues like this, or [the similar issue with C++](https://github.com/apache/arrow-adbc/pull/1717#issuecomment-2051257836).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "zeroshade (via GitHub)" <gi...@apache.org>.
zeroshade commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2100881165
Wow, that's really odd. My first thought to ask here is whether or not this reproduces on a non-Mac platform or if this is specific to MacOS?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "lidavidm (via GitHub)" <gi...@apache.org>.
lidavidm commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101718299
Actually under lldb the process just hangs forever, even if we only import/use a single driver. So that won't help.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "lidavidm (via GitHub)" <gi...@apache.org>.
lidavidm commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2101727693
@cocoa-xu this will also affect BigQuery...it seems both C++ and Go have packaging issues here...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "CurtHagenlocher (via GitHub)" <gi...@apache.org>.
CurtHagenlocher commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2104489039
> would .NET have the same issues as Go above with multiple shared libraries and hence multiple runtimes in one process?
No, but see [https://github.com/dotnet/runtime/discussions/102048](https://github.com/dotnet/runtime/discussions/102048)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "CurtHagenlocher (via GitHub)" <gi...@apache.org>.
CurtHagenlocher commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2104805522
> we don't have an official port of gRPC for Rust yet
Wow, I definitely didn't expect that. It looks like Tonic is fairly widely used, though. Apparently, there's no shortage of reasons for why it's so hard to move away from C as an implementation language.
As a thought experiment, let's say that we wanted to implement a bunch of drivers in some (uniform) non-C language and then consume them via the C API from Python.
For Go, the implication is that all the Go drivers would need to be bundled into a single cgo-based dynamic library in order to ensure no conflicts between them. It also implies that there could be problems trying to load any non-ADBC extension which also happened to be implemented in Go.
For C# with AOT compilation, there wouldn't be direct conflicts between the individual drivers, but there would be an increasingly heavy burden in terms of thread and address space consumption. The larger problem would be that a lot of existing code doesn't work with AOT compilation. This seems to cover a good chunk of what's needed to connect to BigQuery. The resource consumption issue could also be resolved by bundling all the drivers together into a single dynamic library.
For Java and for C# without AOT compilation, it would require the user to have the corresponding runtime installed on their machine. All the drivers implemented in those languages could then be dynamically loaded into that runtime and would share a single set of runtime features like the garbage collector. They could then also share dependencies for an overall smaller footprint -- but of course this has the corresponding drawback that isolation between dependencies is more difficult. There would also need to be a way to dynamically register with a shared ADBC driver manager in-memory, because in this scenario there wouldn't be native entry points available for the drivers.
Feel free to add your favorite language to the list... .
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] go/adbc/driver/snowflake+flightsql: Memory access violation when both are used in Python [arrow-adbc]
Posted by "ukclivecox (via GitHub)" <gi...@apache.org>.
ukclivecox commented on issue #1841:
URL: https://github.com/apache/arrow-adbc/issues/1841#issuecomment-2112642350
FYI: I'd like to use DuckDB and Postgres ADBC drivers in Go. Not sure its connected but on testing I get a SIGSEV also on reading from a query result. So +1 from me if this can be supported.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org