On Tue, Apr 28, 2015 at 1:31 PM, Gene Cooperman <g...@ccs.neu.edu> wrote:
> I have now confirmed the problem with ocaml on the local 64-bit > computer of our team (currently Ubuntu 13.10). No doubt, the same bug > would appear on the other computers that we test on. This is good news. > If we can observe it locally, we should have a good chance of fixing it. It seems from the below you are talking about the problem of quitting on receipt of a control-C? Interesting, because this is not a problem I have seen on the 64-bit machine. Only on the 32-bit, and only if I run the interpreter indirectly by typing "ocaml". I wonder what you get if you do "ocamlrun /usr/bin/ocaml" which works for me on the 32-bit machine also (mutatis mutandis for the path of ocaml). The problem I was getting on the 64-bit machine was the occasional segfaults with some checkpointed processes on startup. I assume you have not been getting that at all. I wonder if you have any ideas about why that may be happening on my 64-bit system. > From what I can tell so far, ocaml really tries to defend itself > against the user typing ^C (and maybe from the user sending other signals). Also interesting, since I have not noticed this either. Ocaml called on its own has always responded nicely for me to the control-C. And also, on the 64-bit machine as a restarted checkpointed process, it has worked fine. And even on the 32-bit machine, if I run ocaml as "ocamlrun /usr/bin/ocaml", it works fine. They do say that it is supposed to work like this as well at http://caml.inria.fr/pub/docs/manual-ocaml/toplevel.html: " At any point, the parsing, compilation or evaluation of the " current phrase can be interrupted by pressing ctrl-C (or, more " precisely, by sending the INTR signal to the ocaml process). " The toplevel then immediately returns to the # prompt. > DMTCP tries to support such behavior in a non-invasive way while still > working correctly. Clearly DMTCP is failing to do so in the case of ocaml. I think dmtcp works okay with this (meaning all along, the 2.4 versions. The 2.3 versions have never worked with control-C for me at all, but I assume that is known, and ancient history), certainly at least if ocamlrun is called. But recall I mentioned that if I start a bash shell, then python, then checkpoint, I get bad results too? That suggests to me that when there are two levels of process dmtcp may not do all the right things. And perhaps this is what is happening with invoking ocaml through the bytecode file, since it has to run bash long enough at least to parse the #! line. Perhaps signal propagation is not set up quite right in those cases? > Thanks again for reporting this. (And as I remarked early, we'll > also look at the support for 32-bit O/S's, once we put out rc4. > rc2 and rc3 are known to have problems with a 32-bit O/S.) I will check it out when it is ready. Thanks! ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Dmtcp-forum mailing list Dmtcp-forum@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dmtcp-forum
