[Chicken-hackers] [PATCH] Avoid spin loop in socket_read() when debug client disconnects
Hi all, Here's a tiny patch that makes the debug server end the program when a client disconnects unexpectedly, i.e. without first sending a terminate signal. Currently, the program will instead go into an infinite loop and burn 100% of a CPU until it's killed. Cheers, Evan >From a93b4d4c6d213f2c04c34f8ff79ea61be6a0262a Mon Sep 17 00:00:00 2001 From: Evan Hanson Date: Thu, 14 Mar 2019 21:42:47 +1300 Subject: [PATCH] Avoid spin loop in socket_read() when debug client disconnects --- dbg-stub.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/dbg-stub.c b/dbg-stub.c index 348a77f6..218d8506 100644 --- a/dbg-stub.c +++ b/dbg-stub.c @@ -159,7 +159,7 @@ socket_read() if(*(input_buffer_top++) == '\n') { *ptr = '\0'; --input_buffer_len; -return 0; +return 1; } if(++off >= RW_BUFFER_SIZE) return -1; /* read-buffer overflow */ @@ -171,6 +171,8 @@ socket_read() if(n == SOCKET_ERROR) return -1; /* read failed */ +if(n == 0) return 0; /* client disconnect */ + input_buffer_len = n; input_buffer_top = input_buffer; } @@ -304,7 +306,11 @@ send_event(int event, C_char *loc, C_char *val, C_char *cloc) send_string_value(cloc); send_string(")\n"); -if(socket_read() < 0) terminate("read failed"); +n = socket_read(); + +if(n < 0) terminate("read failed"); + +if(n == 0) terminate("debugger disconnected"); /* fprintf(stderr, "\n", rw_buffer); */ n = sscanf(rw_buffer, "(%d ", &reply); -- 2.11.0 ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Avoid spin loop in socket_read() when debug client disconnects
> Hi all, > > Here's a tiny patch that makes the debug server end the program when a > client disconnects unexpectedly, i.e. without first sending a terminate > signal. Currently, the program will instead go into an infinite loop and > burn 100% of a CPU until it's killed. > Pushed. Thanks, Evan. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Use vertical space more liberally in some scrutinizer messages
> Hi folks, > > I've just pushed most of these patches, with signoffs, to a branch > called "scrutiny-message-formatting", and I think we should merge it. Thanks for doing this, I've ran the tests and so far things look good. I'm a bit concerned about the verbosity of the warnings. For generated code or for macro expansions, cases like (if #f ...) or (let ((a '(x . y))) (if (pair? a) ...)) will generate lots of output that only applies to trivially optimizable cases. I'm fine with merging the patches but perhaps we should distinguish between true errors (that can't possibly work) and those warnings that apply to valid code but indicate redundancies. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Use vertical space more liberally in some scrutinizer messages
felix.winkelm...@bevuta.com writes: >> Hi folks, >> >> I've just pushed most of these patches, with signoffs, to a branch >> called "scrutiny-message-formatting", and I think we should merge it. > > Thanks for doing this, I've ran the tests and so far things look good. > > I'm a bit concerned about the verbosity of the warnings. For generated > code or for macro expansions, cases like > > (if #f ...) > > or > > (let ((a '(x . y))) > (if (pair? a) ...)) > > will generate lots of output that only applies to trivially optimizable > cases. I'm fine with merging the patches but perhaps we should > distinguish between true errors (that can't possibly work) and > those warnings that apply to valid code but indicate redundancies. > Hi Felix, I totally agree about these two cases. I'd vote for hiding these messages altogether. Even if you're compiling with -verbose. Maybe just show statistics for known predicate calls with statically known results. There's already a statistic for dropped branches. And I agree that the scrutinizer should only show warnings about expressions it knows for sure are wrong. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers