|
From: <sv...@va...> - 2012-03-08 23:42:12
|
philippe 2012-03-08 23:42:05 +0000 (Thu, 08 Mar 2012)
New Revision: 12438
Log:
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.
Modified files:
trunk/coregrind/m_aspacemgr/aspacemgr-linux.c
Modified: trunk/coregrind/m_aspacemgr/aspacemgr-linux.c (+2 -1)
===================================================================
--- trunk/coregrind/m_aspacemgr/aspacemgr-linux.c 2012-03-08 19:17:56 +00:00 (rev 12437)
+++ trunk/coregrind/m_aspacemgr/aspacemgr-linux.c 2012-03-08 23:42:05 +00:00 (rev 12438)
@@ -1661,7 +1661,8 @@
# 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
|