##// END OF EJS Templates
chg: handle EOF reading data block...
chg: handle EOF reading data block We recently discovered a case in production that chg uses 100% CPU and is trying to read data forever: recvfrom(4, "", 1814012019, 0, NULL, NULL) = 0 Using gdb, apparently readchannel() got wrong data. It was reading in an infinite loop because rsize == 0 does not exit the loop, while the server process had ended. (gdb) bt #0 ... in recv () at /lib64/libc.so.6 #1 ... in readchannel (...) at /usr/include/bits/socket2.h:45 #2 ... in readchannel (hgc=...) at hgclient.c:129 #3 ... in handleresponse (hgc=...) at hgclient.c:255 #4 ... in hgc_runcommand (hgc=..., args=<optimized>, argsize=<optimized>) #5 ... in main (argc=...486922636, argv=..., envp=...) at chg.c:661 (gdb) frame 2 (gdb) p *hgc $1 = {sockfd = 4, pid = 381152, ctx = {ch = 108 'l', data = 0x7fb05164f010 "st):\nTraceback (most recent call last):\n" "Traceback (most recent call last):\ne", maxdatasize = 1814065152," " datasize = 1814064225}, capflags = 16131} This patch addresses the infinite loop issue by detecting continuously empty responses and abort in that case. Note that datasize can be translated to ['l', ' ', 'l', 'a']. Concatenate datasize and data, it forms part of "Traceback (most recent call last):". This may indicate a server-side channeledoutput issue. If it is a race condition, we may want to use flock to protect the channels.

File last commit:

r23934:975c4fc4 stable
r29602:4fc4b8cc default
Show More
hg.bat
19 lines | 475 B | application/x-msdownload | BatchLexer
@echo off
rem Windows Driver script for Mercurial
setlocal
set HG=%~f0
rem Use a full path to Python (relative to this script) if it exists,
rem as the standard Python install does not put python.exe on the PATH...
rem Otherwise, expect that python.exe can be found on the PATH.
rem %~dp0 is the directory of this script
if exist "%~dp0..\python.exe" (
"%~dp0..\python" "%~dp0hg" %*
) else (
python "%~dp0hg" %*
)
endlocal
exit /b %ERRORLEVEL%