Failing on --enable-m32 in CentOS 7 and CentOS 6.6 about dmtcp

[gc00]

... and I see that DMTCP-2.0 does not have any bug here, for CentOS 7. Later, I'll do a git bisect or other strategy to figure out the difference. But I remember that we modified the way we handle wrapper functions somewhere between version 2.0 and the present.

[gc00]

And I've done a preliminary git-bisect. I'll try to refine it further later.

The bug is in this range (for both CentOS 6.6 and CentOS 7):
git log 87ded92..487eef9
12/25/13 to 2/21/14

And here are the summaries of those commits:

bad: [487eef9] Remove JALIB stuff from mtcp/Makefile.in.

git bisect bad 487eef9

good: [87ded92] IPC: Multi-arch support for sendFd/recvFd.

git bisect good 87ded92

[gc00]

The bug is now in the range 1d6c4d1..84601e3 (from 12/25/13 to 2/16/14).

[gc00]

The bug is now in the range ea3c100..ab651cf (from 12/25/13 to 1/20/14).

[gc00]

I found the bug fix affecting standalone launch for m32. I did a bisect by hand in the above range, and that gave me the clue for what was missing. This bug fix (commit 9445ba7 ) affects only standalone m32, and not multi-arch.
This means that we still have a bug during restart when address randomization is turned on. This bug occurs both for m32 standalone and for multi-arch. The standalone case is issue #62 .

[gc00]

For the bug on restart, the bad commit is: dec2c26 This was found by manually doing a git bisect using test/misc/multi-arch.sh at each step. This agrees with the first bad commit found when running under 32-bit Ubuntu 9.10 (using a standard ./configure; make). The commit message is (from 3/16/15):

vDSO cleanup.   
The newer vDSO/vvar sections are mremap()'d to the older vDSO/vvar addresses.

[gc00]

Commits 2cc8e7e and 2cc8e7e fix the two bugs listed here.