Finally understood why an outer on inner on a 32 bit application

is failing on a 64 bit host.

The bug might or might not be related to some
errors "failed in UME with error 22"
(such as bug https://bugs.kde.org/show_bug.cgi?id=138424).

The bug is: when aspacem_maxAddr is very close to the upper limit,
and aspacem_minAddr is somewhat not close to 0, then
the computation of
   aspacem_vStart = VG_PGROUNDUP((aspacem_minAddr + aspacem_maxAddr + 1) / 2);
can overflow.
The vStart value will then silently wrap around.
(please, give me my Ada language back :).

When overflowing, vStart will then be below the client cStart.
At least when running outer on inner on a 32 bit application on
a 64 bit system, this was causing strange problems.

I suppose that on a 64 bit system, a 32 bit application can use more
of the 4 Gb, and then the max address is higher and can more easily
overflow than on a 32 bit system.

Tested on f12/x86, debian6/amd64 (bi-arch).
+ run a few outer on inner x86 regression tests : these were all failing
and are now succesfully running.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12438

diff --git a/coregrind/m_aspacemgr/aspacemgr-linux.c b/coregrind/m_aspacemgr/aspacemgr-linux.c
index a7c7e9209c89ee682940eabe74d367f31141b774..9980501b52243528fe5388d700b729eb6a26d3eb 100644 (file)
--- a/coregrind/m_aspacemgr/aspacemgr-linux.c
+++ b/coregrind/m_aspacemgr/aspacemgr-linux.c
@@ -1661,7 +1661,8 @@ Addr VG_(am_startup) ( Addr sp_at_startup )
 #  endif
 
    aspacem_cStart = aspacem_minAddr; // 64M
-   aspacem_vStart = VG_PGROUNDUP((aspacem_minAddr + aspacem_maxAddr + 1) / 2);
+   aspacem_vStart = VG_PGROUNDUP(aspacem_minAddr 
+                                 + (aspacem_maxAddr - aspacem_minAddr + 1) / 2);
 #  ifdef ENABLE_INNER
    aspacem_vStart -= 0x10000000; // 256M
 #  endif