[valgrind] [Bug 368507] valgrind throws std::bad_alloc on memory allocations larger than 34255421416 bytes

[Rhys Kidd]

https://bugs.kde.org/show_bug.cgi?id=368507

--- Comment #13 from Rhys Kidd  ---
Any changes for macOS can come later.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 368507] valgrind throws std::bad_alloc on memory allocations larger than 34255421416 bytes

[Julian Seward]

https://bugs.kde.org/show_bug.cgi?id=368507

Julian Seward  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|CONFIRMED   |RESOLVED

--- Comment #12 from Julian Seward  ---
Closing, for now.  If we need to change the OSX limits later then,
well, fine.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 368507] valgrind throws std::bad_alloc on memory allocations larger than 34255421416 bytes

[Julian Seward]

https://bugs.kde.org/show_bug.cgi?id=368507

Julian Seward  changed:

   What|Removed |Added

 CC||rhysk...@gmail.com

--- Comment #11 from Julian Seward  ---
Solaris and Linux limit increased to 128GB in r16381.  OSX is
so far unchanged.

Rhys, do you want to change OSX too?  I think nothing will break
if OSX isn't changed.  So, as you like.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 368507] valgrind throws std::bad_alloc on memory allocations larger than 34255421416 bytes

[Ivo Raisr]

https://bugs.kde.org/show_bug.cgi?id=368507

Ivo Raisr  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED

--- Comment #10 from Ivo Raisr  ---
Unfortunately I do not have a machine with >32 GB of physical memory where I
can install Solaris and try it out. Solaris does not overcommit when allocating
memory.

Regression tests passed ok.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 368507] valgrind throws std::bad_alloc on memory allocations larger than 34255421416 bytes

[Ivo Raisr]

https://bugs.kde.org/show_bug.cgi?id=368507

Ivo Raisr  changed:

   What|Removed |Added

 Attachment #105549|0   |1
is obsolete||

--- Comment #9 from Ivo Raisr  ---
Created attachment 105561
  --> https://bugs.kde.org/attachment.cgi?id=105561=edit
Proposed fix (so far, Linux and Solaris only)

Solaris changes.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 368507] valgrind throws std::bad_alloc on memory allocations larger than 34255421416 bytes

[Tom Hughes]

https://bugs.kde.org/show_bug.cgi?id=368507

--- Comment #8 from Tom Hughes  ---
Fails at 32Gb without patch:

trying for 31 GB ..
==12078== Warning: set address range perms: large range [0x3960c040,
0x7f960c040) (defined)
  .. OK
==12078== Warning: set address range perms: large range [0x3960c028,
0x7f960c058) (noaccess)
trying for 32 GB ..
allocgig: allocgig.c:15: main: Assertion `p' failed.
==12078== 
==12078== Process terminating with default action of signal 6 (SIGABRT)
==12078==at 0x4E6E428: raise (raise.c:54)
==12078==by 0x4E70029: abort (abort.c:89)
==12078==by 0x4E66BD6: __assert_fail_base (assert.c:92)
==12078==by 0x4E66C81: __assert_fail (assert.c:101)
==12078==by 0x400700: main (in /home/tomh/allocgig)

and at 64Gb with the patch:

trying for 63 GB ..
==14020== Warning: set address range perms: large range [0x10060c4040,
0x1fc60c4040) (defined)
  .. OK
==14020== Warning: set address range perms: large range [0x10060c4028,
0x1fc60c4058) (noaccess)
trying for 64 GB ..
allocgig: allocgig.c:15: main: Assertion `p' failed.
==14020== 
==14020== Process terminating with default action of signal 6 (SIGABRT)
==14020==at 0x4E6E428: raise (raise.c:54)
==14020==by 0x4E70029: abort (abort.c:89)
==14020==by 0x4E66BD6: __assert_fail_base (assert.c:92)
==14020==by 0x4E66C81: __assert_fail (assert.c:101)
==14020==by 0x400700: main (in /home/tomh/allocgig)

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 368507] valgrind throws std::bad_alloc on memory allocations larger than 34255421416 bytes

[Julian Seward]

https://bugs.kde.org/show_bug.cgi?id=368507

--- Comment #7 from Julian Seward  ---
Created attachment 105549
  --> https://bugs.kde.org/attachment.cgi?id=105549=edit
Proposed fix (so far, Linux only)

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 368507] valgrind throws std::bad_alloc on memory allocations larger than 34255421416 bytes

[Julian Seward]

https://bugs.kde.org/show_bug.cgi?id=368507

--- Comment #6 from Julian Seward  ---
Created attachment 105548
  --> https://bugs.kde.org/attachment.cgi?id=105548=edit
test case (allocgig.c)

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 368507] valgrind throws std::bad_alloc on memory allocations larger than 34255421416 bytes

[Julian Seward via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368507

--- Comment #5 from Julian Seward  ---
I had hoped to do this for 3.12.0, but after looking at the #ifdef swamp
in VG_(am_startup) that sets aspacem_maxAddr, I think it is too risky,
because of the number of different cases that need to be verified.
So I'd propose to leave it till after the release.  The number of users
that this will affect is tiny and those that really need it in 3.12.x can
cherry pick the trunk commit into their own custom 3.12.x build, once
we fix it on the trunk.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 368507] valgrind throws std::bad_alloc on memory allocations larger than 34255421416 bytes

[Ivo Raisr via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368507

Ivo Raisr  changed:

   What|Removed |Added

 CC||iv...@ivosh.net

--- Comment #4 from Ivo Raisr  ---
I fully agree.
Server systems these days have even TBs of memory to play with.

In addition to initializing primary map, N_PRIMARY_BITS come into play also in
mc_expensive_sanity_check(). Hopefully it won't be a big deal.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 368507] valgrind throws std::bad_alloc on memory allocations larger than 34255421416 bytes

[Julian Seward via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368507

--- Comment #3 from Julian Seward  ---
The primary_map array, I mean.   I didn't mean the whole 128GB needs to be
zeroed out at startup.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 368507] valgrind throws std::bad_alloc on memory allocations larger than 34255421416 bytes

[Julian Seward via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368507

--- Comment #2 from Julian Seward  ---
In the trunk right now we have N_PRIMARY_BITS = 20, which according to the svn
log makes the maximum usable memory amount be 64G.  That was done at end-Jan
2013 and should surely be in 3.10 and later.

Maybe we should bump this up to 21 bits, hence giving 128G usable memory on
64 bit targets?  It would slow down startup a bit because that array needs to
be
zeroed out, and would soak up a bit more memory, but otherwise seems harmless.
Presumably at some point we can outrun (the ever decelerating) Moore's law
with this game ;-)

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 368507] valgrind throws std::bad_alloc on memory allocations larger than 34255421416 bytes

[Tom Hughes via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368507

Tom Hughes  changed:

   What|Removed |Added

 CC||t...@compton.nu

--- Comment #1 from Tom Hughes  ---
Yes there is a compiled in memory limit imposed by the addressing scheme
valgrind uses for it's shadow memory. See
https://stackoverflow.com/questions/8644234/why-is-valgrind-limited-to-32-gb-on-64-bit-architectures
for more information and how to patch valgrind to allow larger address spaces.

-- 
You are receiving this mail because:
You are watching all bug changes.