Hi Calvin,
This is to confirm for the full dmtcp-forum that on simple tests
of ocaml, using DMTCP 2.4.0-rc4, the ctrl-c problem is not appearing now.
We understand that you haven't yet done any complex testing with ipc and
other features. Thank you for the feedback, and let us know if you do
see additional issues.
[ For others on the forum, DMTCP 2.4.0-rc4 still has some minor
mis-features. I would recommend waiting at least for rc5 (due
next week) or the full release, if you don't need these fixes
immediately. ]
Best wishes,
- Gene
On Tue, Apr 28, 2015 at 01:56:53PM -0400, Calvin Ostrum wrote:
> 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
