EXEC : fatal error : too many writes on closed pipe

[marexv]

Hi.

During builds of angular 12 application on a locally hosted jenkins server following error occurs:

  - Generating browser application bundles (phase: setup)...
EXEC : fatal error : too many writes on closed pipe [D:\Jenkins\workspace\....]
  
  goroutine 6 [running]:
  runtime.throw({0x829e2, 0x1e})
  	/usr/local/go/src/runtime/panic.go:1198 +0x7 fp=0x44dec8 sp=0x44dea0 pc=0x12000007
  os.sigpipe()
  	/usr/local/go/src/runtime/os_js.go:143 +0x2 fp=0x44dee0 sp=0x44dec8 pc=0x137c0002
  os.epipecheck(...)
  	/usr/local/go/src/os/file_unix.go:196
  os.(*File).Write(0x40c020, {0x425080, 0x21, 0x40})
  	/usr/local/go/src/os/file.go:184 +0x25 fp=0x44df68 sp=0x44dee0 pc=0x15b70025
  main.runService.func1(0x446190, 0x41ad40)
  	/Users/evan/dev/esbuild/cmd/esbuild/service.go:70 +0x5 fp=0x44dfd0 sp=0x44df68 pc=0x1d560005
  runtime.goexit()
  	/usr/local/go/src/runtime/asm_wasm.s:431 +0x1 fp=0x44dfd8 sp=0x44dfd0 pc=0x13d10001
  created by main.runService
  	/Users/evan/dev/esbuild/cmd/esbuild/service.go:64 +0xe
  
  goroutine 1 [chan receive]:
  syscall.fsCall({0x7612d, 0x4}, {0x475b50, 0x5, 0x5})
  	/usr/local/go/src/syscall/fs_js.go:521 +0x13
  syscall.Read(0x0, {0x4e8000, 0x4000, 0x4000})
  	/usr/local/go/src/syscall/fs_js.go:389 +0xc
  internal/poll.ignoringEINTRIO(...)
  	/usr/local/go/src/internal/poll/fd_unix.go:582
  internal/poll.(*FD).Read(0x444060, {0x4e8000, 0x4000, 0x4000})
  	/usr/local/go/src/internal/poll/fd_unix.go:163 +0x4c
  os.(*File).read(...)
  	/usr/local/go/src/os/file_posix.go:32
  os.(*File).Read(0x40c018, {0x4e8000, 0x4000, 0x4000})
  	/usr/local/go/src/os/file.go:119 +0x10
  main.runService(0x1)
  	/Users/evan/dev/esbuild/cmd/esbuild/service.go:101 +0x23
  main.main()
  	/Users/evan/dev/esbuild/cmd/esbuild/main.go:202 +0x8
  
  goroutine 7 [waiting]:
  runtime.gopark(0x0, 0x0, 0x0, 0x0, 0x1)
  	/usr/local/go/src/runtime/proc.go:366 +0x27
  runtime.handleEvent()
  	/usr/local/go/src/runtime/lock_js.go:250 +0x1b
  runtime.goexit()
  	/usr/local/go/src/runtime/asm_wasm.s:431 +0x1
  
  goroutine 8 [chan receive]:
  main.(*serviceType).sendRequest(0x446190, {0x3aae0, 0x5c8510})
  	/Users/evan/dev/esbuild/cmd/esbuild/service.go:163 +0xd
  main.runService.func2(0x446190)
  	/Users/evan/dev/esbuild/cmd/esbuild/service.go:92 +0x3
  created by main.runService
  	/Users/evan/dev/esbuild/cmd/esbuild/service.go:89 +0x1e

Error occurs in approximately 90% of builds, meaning that build will sporadically end successfully, but I am not able to pinpoint what is the culprit for it. On local machine build works every time. We have increased RAM on build server in order to match capacity of the local machines, but the error is still occurring.

Package.json references latest esbuild: 0.13.4, couple of npm packages are using version: 0.12.29.

Can somebody point me in the right direction regarding this? Thank you!

[evanw]

This error message looks to me like it's saying that the Go child process is still alive and is trying to communicate back to the Node parent process, but the Node parent process has been terminated. Does that sound right? Are you by any chance terminating the Node process early before some esbuild API requests have finished? That might not be it, but I figured I'd ask in case that's what's happening.

[marexv]

Hi, thank you. I will try to investigate whether jenkins terminates cmd build step to soon, and moves on to the next one. Meanwhile we were able to solve problem by using powershell build step instead of cmd in combination with yarn instead of npm.

[evanw]

I'm going to close this issue since it's currently unactionable and can't be fixed. I'm happy to reopen it if more information is provided. Glad to hear you were able to solve your problem.

[metalwings]

Just for the record: I had the same issue. Completely identical error.
Was building my project in a self-hosted GitLab Runner with the official node:16.13.1-alpine Docker Image

Upgrading from 1 vCPU 2 GB RAM to 2 vCPU 4 GB RAM solved the issue for now.

[evanw]

I just encountered this too, so now I have more information. I think this is a bug with Go itself: golang/go#59099.

[jmwolfe]

I am also seeing this in a teamcity.com (CLOUD) build on a windows agent. We recently moved to the cloud implementation from an on-premise one, and now we are seeing this error when msbuild launches a node process (a target specified in the .csproj file) to build out the Angular 14 application. It happens randomly on various servers that are very well equipped with memory and CPU. I might try using ngbuild.cmd instead of this:

node --max-old-space-size=8192 ../node_modules/@angular/cli/bin/ng build --configuration production --aot --progress

I can confirm that it appears that the node command IS successfully completing, as the normal emitted summary info appears at the end. Does appear that node is terminating before some spawned go process completes. Perhaps this long trace will help:

- Generating browser application bundles (phase: setup)...

goroutine 6 [running]:
runtime.throw({0x89809, 0x1e})
  runtime/panic.go:992 +0x7 fp=0x43aee0 sp=0x43aeb8 pc=0x120d0007
os.sigpipe()
  runtime/os_js.go:142 +0x2 fp=0x43aef8 sp=0x43aee0 pc=0x13750002
os.epipecheck(...)
  os/file_unix.go:195
os.(*File).Write(0x40c020, {0x47c780, 0x21, 0x40})
  os/file.go:184 +0x27 fp=0x43af80 sp=0x43aef8 pc=0x15a00027
main.runService.func1()
  github.com/evanw/esbuild/cmd/esbuild/service.go:114 +0xa fp=0x43afe0 sp=0x43af80 pc=0x1d91000a
runtime.goexit()
  runtime/asm_wasm.s:401 +0x1 fp=0x43afe8 sp=0x43afe0 pc=0x13c30001
created by main.runService
  github.com/evanw/esbuild/cmd/esbuild/service.go:108 +0x13

goroutine 1 [semacquire]:
sync.runtime_Semacquire(0x44a3a0)
  runtime/sema.go:56 +0x2
sync.(*WaitGroup).Wait(0x44a398)
  sync/waitgroup.go:136 +0x11
main.runService(0x1)
  github.com/evanw/esbuild/cmd/esbuild/service.go:177 +0x40

goroutine 7 [waiting]:
runtime.gopark(0x0, 0x0, 0x0, 0x0, 0x1)
  runtime/proc.go:361 +0x27
runtime.handleEvent()
  runtime/lock_js.go:249 +0x1b
runtime.goexit()
  runtime/asm_wasm.s:401 +0x1

goroutine 8 [chan receive]:
main.(*serviceType).sendRequest(0x44a380, {0x3d220, 0x59a390})
  github.com/evanw/esbuild/cmd/esbuild/service.go:203 +0xe
main.runService.func2()
  github.com/evanw/esbuild/cmd/esbuild/service.go:132 +0x3
created by main.runService
  github.com/evanw/esbuild/cmd/esbuild/service.go:129 +0x28
 Browser application bundle generation complete.
 Browser application bundle generation complete.
- Generating index html...
 Index html generation complete.

Initial Chunk Files | Names         |   Raw Size | Estimated Transfer Size
vendor.js           | vendor        |    1.60 MB |               324.59 kB
main.js             | main          |  298.32 kB |                50.96 kB
styles.css          | styles        |  208.87 kB |                25.02 kB
polyfills.js        | polyfills     |   34.37 kB |                11.09 kB
runtime.js          | runtime       | 1006 bytes |               562 bytes

| Initial Total |    2.13 MB |               412.22 kB

Build at: 2023-11-13T16:04:05.742Z - Hash: 3bd49e42fc4d05d9 - Time: 94894ms```

HTH

[Zxilly]

https://go-review.googlesource.com/c/go/+/614935 has been merged, should consider update the behavior when we moved to Go 1.24 .