Hi Calvin,
Sorry it took me a little while to get back to this. End of the semester.
Anyway, we've now released DMTCP 2.4.0-rc4. As far as we know,
rc4 should work fine for both 64- and 32-bit Linuxes, and it should
also work for multi-arch:
http://dmtcp.sourceforge.net/FAQ.html#intel32-64
Note also that if you do use 2.4.0-rc4, dmtcp_command is broken in
that version. But I'm assuming you don't need dmtcp_command for these tests.
You said that you'd be willing to re-test and tell us what you're seeing:
a) are there still any bugs specific to the 32-bit Linux only?
b) if not, what are the remaining bugs (that would happen on both
32- and 64-bit Linuxes)?
Thanks very much. This is very helpful.
Best,
- 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 <[email protected]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dmtcp-forum
