Re: [go-nuts] Re: Preventing SIGBUS errors when memmove-ing an unsafe.Pointer to multiple destinations

2020-06-10 Thread Keith Randall
On Wed, Jun 10, 2020 at 4:15 AM Viktor Kojouharov wrote: > Thanks Ian. Adding to that allocation to cover the element size did the > trick. Out of curiosity, the momery allocated by mallocgc is still tracked > by the gc, right? > A brief look at the code seems to indicate that this is the case,

Re: [go-nuts] Re: Preventing SIGBUS errors when memmove-ing an unsafe.Pointer to multiple destinations

2020-06-10 Thread Viktor Kojouharov
Thanks Ian. Adding to that allocation to cover the element size did the trick. Out of curiosity, the momery allocated by mallocgc is still tracked by the gc, right? A brief look at the code seems to indicate that this is the case, but I don't know how the gc works. On Monday, June 8, 2020 at

Re: [go-nuts] Re: Preventing SIGBUS errors when memmove-ing an unsafe.Pointer to multiple destinations

2020-06-08 Thread Ian Lance Taylor
On Mon, Jun 8, 2020 at 10:44 AM Viktor Kojouharov wrote: > > The full code can be seen in this diff: > > https://github.com/urandom/go/commit/d10ccdd907dac690bfcb31df1115ce1508775458 > > The just of it is, I've added an extra field to a struct (the chan) of type > unsafe.Pointer. The value is

Re: [go-nuts] Re: Preventing SIGBUS errors when memmove-ing an unsafe.Pointer to multiple destinations

2020-06-07 Thread keith . randall
Showing us some code would really help. It's hard to understand what you are doing from this brief description. Also, where does the SIGBUS occur? What pc, and what address? What types are you passing as the first argument to typedmemmove? Where did you get them from? This is a fine question

Re: [go-nuts] Re: Preventing SIGBUS errors when memmove-ing an unsafe.Pointer to multiple destinations

2020-06-07 Thread Michael Jones
Thank you. I now officially know that I don’t understand. Sorry. On Sun, Jun 7, 2020 at 7:54 AM Viktor Kojouharov wrote: > The pointer is being copied via typedmemmove, which itself calls memmove, > which, according to its documentation, copies bytes from the source to the > destination. Not

Re: [go-nuts] Re: Preventing SIGBUS errors when memmove-ing an unsafe.Pointer to multiple destinations

2020-06-07 Thread Viktor Kojouharov
The pointer is being copied via typedmemmove, which itself calls memmove, which, according to its documentation, copies bytes from the source to the destination. Not sure why that would be impossible, considering it does work for some code (the source pointer preserves its data) Not sure what

Re: [go-nuts] Re: Preventing SIGBUS errors when memmove-ing an unsafe.Pointer to multiple destinations

2020-06-07 Thread Michael Jones
Do you mean that you have a problem with the value of the pointer? That is "copying the pointer." This seems impossible. Attempting to access through a pointer copied via unsafe is (generally) inviting doom, and seems highly possible. The instant the last pointer to that data goes out of scope

[go-nuts] Re: Preventing SIGBUS errors when memmove-ing an unsafe.Pointer to multiple destinations

2020-06-07 Thread Viktor Kojouharov
p.s. should such questions be posted in golang-dev, since it deals with runtime internals? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to