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
> >
> >
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Dmtcp-forum mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dmtcp-forum
