Hi,

I'm still trying to make it work.

I've noticed the following strange things in strace output. Shortly after
running the execve system call, when I'm running 32-bit compiled program I
see the following:

14774 getrlimit(RLIMIT_STACK, {rlim_cur=-4286578688, rlim_max=73014444031})
= 0
14774 _sysctl({0x2f7d4b7c4, -16912, (nil), (nil), (nil),
18446671441380573172}) = 0

whereas when running 64-bit program, it looks like that:

14788 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY})
= 0
14788 _sysctl({{CTL_KERN, KERN_VERSION}, 2, 0x7fffffffca50, 34, (nil), 0})
= 0

Seems like when running 32-bit program with 64 dmtcp_checkpoint, even after
it loads the correct dmtcphijack.so file, it can't even get the correct
kernel parameters. I still couldn't figure out why, though.

Do you have any advice?

Please tell me if you find it easier to do it over a phone call as you
initially suggested.

Thanks
--Avi

On Tue, Apr 3, 2012 at 19:19, Gene Cooperman <[email protected]> wrote:

> Hi Kapil,
>    Do you have a chance to look at this more closely?  I'm going to
> be tied up all day.
>
> Best,
> - Gene
>
> On Tue, Apr 03, 2012 at 10:37:08AM +0300, Avi Rosenfeld wrote:
> > Hello,
> >
> > Thanks for the response, Gene.
> >
> > For now I'm just looking for a quick workaround, and if I manage to work
> it
> > out I'll make an effort to find a permanent solution.
> >
> > Here's what I came up with so far:
> >
> > 1.
> > In order to load the correct dmtcphijack.so library, I've overridden the
> > file lookup
> > using jalib::Filesystem::FindHelperUtility in
> dmtcp/src/dmtcp_checkpoint.cpp.
> > Instead, I'm just using:
> >
> > preloadLibs += "dmtcphijack.so";
> >
> > Since both 32-bit and 64-bit libraries are in my path, the correct
> > dmtcphijack is loaded according to the program's compilaton (I've also
> > verified it using strace).
> >
> > 2.
> > My next step was changing the way libmtcp.so is loaded. In order to do
> > that, I've modified the find_and_open_mtcp_so function
> > in dmtcp/src/mtcpinterface.cpp.
> >
> > It's just a quick and dirty solution in which I first try to load the
> > 64-bit version of libmtcp.so (using a hard coded path), and if failed
> > trying to load 32-bit libmtcp.so.
> >
> > 3.
> > Then, I've compiled dmtcp twice: First using the --enable-m32 flag, and
> > then without. I made sure the object files were created in different
> > directories in both cases (lib and lib64).
> >
> > As I said, from looking in strace output, it seems that the correct
> version
> > of dmtcphijack.so is loaded.
> >
> > The problem is that when trying to run a 32-bit compiled program under
> > dmtcp, the program never gets to loading libmtcp.so and crashes with
> > a SIGSEGV (Segmentation fault) after it finished loading all the shared
> > libraries (last one is libgcc_s.so.1).
> >
> > 31361 open("/lib/libgcc_s.so.1", O_RDONLY) = 3
> > 31361 read(3, "\177ELF....
> > .......
> > 31361 set_tid_address(0xf7c61718)       = 31361
> > 31361 rt_sigaction(SIGRTMIN, {0x4f7d56760, [], 0}, NULL, 8) = 0
> > 31361 rt_sigaction(SIGRT_1, {0x10000004f7d56670, [], 0}, NULL, 8) = 0
> > 31361 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
> > 31361 getrlimit(RLIMIT_STACK, {rlim_cur=-4286578688,
> rlim_max=73014444031})
> > = 0
> > 31361 _sysctl({0x2f7d607c4, -16976, (nil), (nil), (nil),
> > 18446671166502752244}) = 0
> > 31361 futex(0xf7d4d4fc, FUTEX_WAKE, 2147483647) = 0
> > 31361 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> >
> > I've also tried the other way around: using a 32-bit compiled binaries,
> and
> > the same thing happened. 32-bit programs ran correctly, and 64-bit
> programs
> > crashed with SIGSEGV.
> >
> > Do you have any idea if I've missed anything?
> >
> > Thanks
> > --Avi
> >
> >
> >
> >
> > On Sun, Apr 1, 2012 at 19:22, Gene Cooperman <[email protected]> wrote:
> >
> > > Hi Avi,
> > >
> > > DMTCP does not have the equivalent of --enable-multilib.  Based on your
> > > e-mail, I guess you've already seen  "./configure --enable-m32" in
> DMTCP.
> > > But as you note, this supports only all processes in 32-bit mode or
> > > all in 64-bit mode.
> > >
> > > In principle, DMTCP could certainly be extended to support multilib.
> > > But this would take some effort.  I don't anticipate us doing it soon,
> > > due to lack of resources.  But we'd be very happy to help someone else
> do
> > > it,
> > > if they wanted to do this extension.
> > >
> > > If you wanted to look into this further, I'd be happy to schedule a
> phone
> > > call with you.
> > >
> > > Best wishes,
> > > - Gene
> > >
> > > On Sun, Apr 01, 2012 at 09:25:12AM +0200, Avi Rosenfeld wrote:
> > > > Hello,
> > > >
> > > > The environment in my workplace include programs compiled both in 64
> and
> > > 32
> > > > bit on all clients. This is mainly for legacy and backward
> compatibility
> > > > reasons.
> > > >
> > > > It is not uncommon, therefore, for certain processes trees to have
> both
> > > 32
> > > > and 64 bit compiled programs. It's making it very hard to checkpoint
> such
> > > > applications, since DMTCP could be compiled to 32 or 64 bit, not
> both.
> > > >
> > > > In BLCR there's a "--enable-multilib" flag that enables building both
> > > > 64-bit and 32-bit libraries at the same time. Is there a way to do
> > > > something similar with DMTCP?
> > > >
> > > > Thanks
> > > > --Avi
> > >
> > > >
> > >
> ------------------------------------------------------------------------------
> > > > This SF email is sponsosred by:
> > > > Try Windows Azure free for 90 days Click Here
> > > > http://p.sf.net/sfu/sfd2d-msazure
> > >
> > > > _______________________________________________
> > > > Dmtcp-forum mailing list
> > > > [email protected]
> > > > https://lists.sourceforge.net/lists/listinfo/dmtcp-forum
> > >
> > >
>
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Dmtcp-forum mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dmtcp-forum

Reply via email to