Re: [go-nuts] io.CopyN occasionally fails with unexpected EOF on large ranged reads

On Monday, 7 July 2025 at 19:14:49 UTC+1 Kanak Bhatia wrote: Its not networked // Read the data back fmt.Println("Fetching object back using GetObject...") r, err := c.GetObject(context.Background(), bucketName, objectName, minio.GetObjectOptions{}) minio seems very networked to me. Can you ma

[go-nuts] Smart Contracts on GO

Hi Go developers! 👋 I want to introduce you to a way you can use **Go** to write smart contracts and seamlessly connect your existing business or create brand new **Web3** projects using Go. I've created an SDK for this purpose, which you can check out here: 🔧 **SDK** — [https://github.com/vlm

Re: [go-nuts] io.CopyN occasionally fails with unexpected EOF on large ranged reads

I would try your program in a Linux vm. I highly suspect an OS issue. If it works, I would try on a pure Windows 10 VM. On Jul 7, 2025, at 1:25 PM, Kanak Bhatia wrote:I meant windows 11, but i am using wsl internally for everythingOn Mon, 7 Jul 2025, 23:52 Kanak Bhatia,

Re: [go-nuts] io.CopyN occasionally fails with unexpected EOF on large ranged reads

I suspect you maybe have an anti virus software (or something like it) that is messing up by reading/interrupting the process. What OS?On Jul 7, 2025, at 1:14 PM, Kanak Bhatia wrote:Its not networked// Read the data backfmt.Println("Fetching object back using GetObject...")r, err := c.GetObject(

Re: [go-nuts] io.CopyN occasionally fails with unexpected EOF on large ranged reads

I meant windows 11, but i am using wsl internally for everything On Mon, 7 Jul 2025, 23:52 Kanak Bhatia, wrote: > Using windows 11 + wsl > > On Mon, 7 Jul 2025, 23:51 Robert Engels, wrote: > >>  >> I suspect you maybe have an anti virus software (or something like it) >> that is messing up by

Re: [go-nuts] io.CopyN occasionally fails with unexpected EOF on large ranged reads

Using windows 11 + wsl On Mon, 7 Jul 2025, 23:51 Robert Engels, wrote: >  > I suspect you maybe have an anti virus software (or something like it) > that is messing up by reading/interrupting the process. What OS? > > On Jul 7, 2025, at 1:14 PM, Kanak Bhatia wrote: > >  > Its not networked >

Re: [go-nuts] io.CopyN occasionally fails with unexpected EOF on large ranged reads

Its not networked // Read the data back fmt.Println("Fetching object back using GetObject...") r, err := c.GetObject(context.Background(), bucketName, objectName, minio.GetObjectOptions{}) if err != nil { logError(testName, function, args, startTime, "", "GetObject failed", err) return } d

Re: [go-nuts] io.CopyN occasionally fails with unexpected EOF on large ranged reads

What's the source and target, are they networked if so likely a network issue. On Mon, 7 Jul 2025 at 18:12, Kanak Bhatia wrote: > Hi all, > > I'm encountering an intermittent issue while using io.CopyN to copy 129MB > object from reader to writer. > > The problem: > On some iterations, io.CopyN(

[go-nuts] io.CopyN occasionally fails with unexpected EOF on large ranged reads

Hi all, I'm encountering an intermittent issue while using io.CopyN to copy 129MB object from reader to writer. The problem: On some iterations, io.CopyN(dst, src, n) fails with unexpected EOF even though the same logic succeeds in most runs. The failure typically happens after 125–130 MB and

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

On Mon, Jul 7, 2025 at 9:24 AM Robert Engels wrote: > >  > It seems I clearly don’t understand it - based on the example in the > documentation for the 1.25 compiler changes - why would this gave to panic? > You can call methods on nil pointers - so this call is valid - it all depends > on wha

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

Or maybe it is how the proposed solution is worded. “ If this change is affecting your code, the solution is to put the non-nil error check earlier in your code, preferably immediately after the error-generating statement.”This is only the case if the api call does not return valid results in addit

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

It seems I clearly don’t understand it - based on the example in the documentation for the 1.25 compiler changes - why would this gave to panic? You can call methods on nil pointers - so this call is valid - it all depends on what the method does. Eg in this case f.Name() could return a default if

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

On Monday, July 7, 2025 at 8:48:03 AM UTC-7 Robert Engels wrote: This change seems wrong just based on the io.Reader returns of valid bytes and an error. I'm not sure what you are saying. This change (CL 657715) is just about doing (pointer) nil checks where the spec says they should go. The

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

On Mon, Jul 7, 2025, 8:47 AM Robert Engels wrote: > This change seems wrong just based on the io.Reader returns of valid bytes > and an error. An error doesn’t always mean the other return values are > invalid - it is decided by the api method. > I think you are misunderstanding the actual chang

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

This change seems wrong just based on the io.Reader returns of valid bytes and an error. An error doesn’t always mean the other return values are invalid - it is decided by the api method. On Jul 7, 2025, at 10:43 AM, 'Keith Randall' via golang-nuts wrote:See the second paragraph in the compiler

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

See the second paragraph in the compiler section of the go1.25 release notes: https://tip.golang.org/doc/go1.25#compiler The example looks strangely familiar... On Sunday, July 6, 2025 at 1:18:20 AM UTC-7 Brian Candler wrote: > The main example which springs to mind is io.Reader.Read >

[go-nuts] Re: how to update race detector to latest tsan?

I filed https://github.com/golang/go/issues/74487 to track this. On Monday, July 7, 2025 at 4:14:07 PM UTC+2 Jason E. Aten wrote: > Ugh. I don't know why groups removed all the newlines in that paste. Here > it is again with manually inserted newlines: > > jaten@rog /usr $ cd local/dev-go/go/ >

[go-nuts] New field tags in the upcoming json/v2 package

Hi all, I recently wrote about some of the new field tag options that will be offered by Go 1.25's encoding/json/v2 package. Read about it here: https://medium.com/@cheikhhseck/exploring-go-1-25s-json-v2-package-2b83d15a85e3?sk=58ba9fbaaeb807b133a21c7acb363c19 -- You received this message bec

[go-nuts] Re: how to update race detector to latest tsan?

Ugh. I don't know why groups removed all the newlines in that paste. Here it is again with manually inserted newlines: jaten@rog /usr $ cd local/dev-go/go/ jaten@rog /usr/local/dev-go/go (go1.25-goj) $ ls api CONTRIBUTING.md lib PATENTS SECURITY.md VERSION bin doc LICENSE pkg src VERSION~ codere

[go-nuts] Re: how to update race detector to latest tsan?

Ah. I see that racebuild is just a thin wrapper around a shell script. Ok. So I tried to execute that shell script manually. I find a race in that build of the race detector... full irony! jaten@rog /usr $ cd local/dev-go/go/ jaten@rog /usr/local/dev-go/go (go1.25-goj) $ ls api CONTRIBUTING.md

[go-nuts] how to update race detector to latest tsan?

I'm trying to characterize the race-detector/tsan corruption bugs found in https://github.com/golang/go/issues/74019, on the latest pre-release of go1.25 (at b062eb46e8e76ad39029d0c1b13e4eb81c692c20 which is tagged as "*release-branch.go1.25").* I tried to follow the Go src/runtime/race/README in