That was it! We had two different variable declarations for yytext, one as char* the other as char[size]. Thank you so much Quinn! I would suggest for the linker to provide a more explicit error message ;-)

Thanks for your help! So, is your client/server app one app? Or two? two And is the server running locally as well? Or just the client? During the scenario, the server is on another machine. Is the client/server app related to the file server? Not at all. Actually we could reproduce the error by copying from a dmg file previously downloaded on the client machine. So the file server is not involved. Also, what version of macOS is this? We tested on macOS 15.4 and 15.5. And do you see any crash reports generated at the time you see this error? We didn't checked. We will. I’m not sure where you got EBROKENPIPE from. The error I’d expect to see when you write to a disconnected socket [1] is EPIPE (32). Right, sorry it's EPIPE(32). Actually we are using openssl + libuv. ssl_write returns error EPIPE(32), we can also get SSL_ERROR_ZERO_RETURN(6) which I think can also be the result of an EPIPE. Today we got a different log in console during the error (19813 is our tcp port): default 14:01:38.571568+0100 kernel tcp drop outgoing [:53637<->:19813] interface: en0 (skipped: 23) so_gencnt: 163620 t_state: CLOSED process: 4D:9220 t_state: CLOSED so_error: 0 reason: NECP default 14:01:38.571602+0100 kernel tcp_connection_summary (tcp_drop:1263)[:53637<->:19813] interface: en0 (skipped: 23) so_gencnt: 163620 t_state: CLOSED process: 4D:9220 Duration: 346.780 sec Conn_Time: 0.006 sec bytes in/out: 2886/421 pkts in/out: 9/5 pkt rxmit: 0 ooo pkts: 0 dup bytes in: 0 ACKs delayed: 0 delayed ACKs sent: 0 rtt: 6.000 ms rttvar: 2.125 ms base rtt: 4 ms so_error: 60 svc/tc: 0 flow: 0x9e4027db default 14:01:38.571619+0100 kernel tcp_connection_summary [:53637<->:19813] interface: en0 (skipped: 23) so_gencnt: 163620 t_state: CLOSED process: 4D:9220 flowctl: 0us (0x) SYN in/out: 1/1 FIN in/out: 0/0 RST in/out: 0/0 AccECN (client/server): Disabled/Disabled I see "reason: NECP", but is it the cause or just a notification from NECP? I'm also puzzled about so_error:60 (ETIMEDOUT) because we are using non blocking sockets with libuv, and we don't use the SO_SNDTIMEO socket option. Note: most our machines have crowdstrike and rapid7 but we got the error on macs without. We couldn't isolate the exact conditions for this error to occur. On some mac the symptoms disappeared when we upgraded from macOS 15.4 to 15.5. But some other macs with 15.5 still show the error. This seems related to the local network privacy permissions: for the error to occur one condition seems to be that the other client.app we copy, which has the same bundle id but a different macho uuid, must not have been authorised yet for local network.