On Thu, May 12, 2016 at 09:01:43PM -0400, Calvin Ostrum wrote: > > More on this problem which I have been looking > at for a full day. > > I figured that given all the changes that have been > recently made to the wrapper-manufacturing code, it > would not make too much sense to try to find a problem > in the old code. > > So I grabbed the 3.0 master and tired it. As I mentioned > it also had an infinite loop but apparently a much smaller tighter > one.
Interesting! So, it seems like we missed out on some corner case. Could you please share the stack trace? Also, is it easy to isolate it to a simple test case that you could share with us? It'll be easy to debug if we can reproduce it locally. > > As I understand it, the idea is that code with names like > _real_free ultimately gets associated withe the genuine > free in glibc2 (I dind't examine exactly how) and then the > user's program calls your free which does what it has to to keep > track of things, and then passes the call on. That's the idea, more or less. The _real_* calls go the next layer/library in the search order. It could be the next plugin library or the libc or the kernel. > > But it simply looks like on my system, the wrapper- > free is not actually calling the real-free, or if it > does, that itself soon calls the wrapper-free in turn. > A few print statements I placed in the code indicated > clearly that the wrapper-free gets to a point > where it never returns from its call to the > real-free. > > So, to test, I simply commented out everything in the > wrapper-free, thinking that if free is used > sensibly, this might actually "work" for > a little while since the freed stuff would > simply become uncollectable garbage. > > And, it did work. In fact, I was able to > load 40,000 lines of dense ocaml into an > interactive ocaml, checkpoint it, and then start > it up and continue on. The image of the > saved process was 93M compared to 71M for > the same thing saved with an earlier version > on a system where that version worked. Could you try with `dmtcp_launch --disable-alloc-plugin`? Does that help? It's not the final solution, of course, but I just want to isolate and do sanity tests. > > What do you think I should do next? I don't > understand the code of course, but hopefully > there is something I can do to help. Since > this appears only to happen on my one machine, > maybe there is something I could look at there. > It is like somehow the glib library is not > being dynamically linked in at the right time, > perhaps some environment variables are off > or not set correctly. > > Too tired now but tomorrow I will build it > again with the code back in the wrapper- > free, and save a stack trace in gdb to send on. > > Another thing now is this version seems to be > back for me to where some earlier versions were, > which is that cntrl-c is not passed back to > the program for it to handle it, but causes > the program to simply terminate, which is not what > one wants for an interactive shell. Aha! We seem to have regressed on a few things. Is it easy to point to the version where it worked? If not, could you provide us with a simple test case to reproduce it locally? > > > ------------------------------------------------------------------------------ > Mobile security can be enabling, not merely restricting. Employees who > bring their own devices (BYOD) to work are irked by the imposition of MDM > restrictions. Mobile Device Manager Plus allows you to control only the > apps on BYO-devices by containerizing them, leaving personal data untouched! > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j > _______________________________________________ > Dmtcp-forum mailing list > Dmtcp-forum@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dmtcp-forum ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ Dmtcp-forum mailing list Dmtcp-forum@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dmtcp-forum
