FS#12609 - [Valgrind] says "aspacem Valgrind: FATAL: VG_N_SEGMENTS is too low. Increase it and rebuild."

Attached to Project: Arch Linux
Opened by Paweł Paprota (yagood) - Monday, 29 December 2008, 08:32 GMT
Last edited by Allan McRae (Allan) - Wednesday, 17 June 2009, 11:34 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Allan McRae (Allan)
Architecture i686
Severity Low
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

I'm using valgrind with my application and today I stumbled upon the following problem:

--16997-- Reading syms from /usr/lib/python2.6/lib-dynload/time.so (0x4077000)
--16997-- Reading syms from /usr/lib/python2.6/lib-dynload/strop.so (0x407C000)
--16997-- Reading syms from /usr/lib/python2.6/lib-dynload/cStringIO.so (0x4082000)
--16997-- Reading syms from /usr/lib/python2.6/lib-dynload/_functools.so (0x4086000)
--16997-- Reading syms from /usr/lib/python2.6/lib-dynload/_collections.so (0x4089000)
--16997-- Reading syms from /usr/lib/python2.6/lib-dynload/operator.so (0x6554000)
--16997-- Reading syms from /usr/lib/python2.6/lib-dynload/_socket.so (0x665C000)
--16997-- Reading syms from /usr/lib/python2.6/lib-dynload/_ssl.so (0x6669000)
--16997-- Reading syms from /usr/lib/libssl.so.0.9.8 (0x668C000)
--16997-- Reading syms from /usr/lib/libcrypto.so.0.9.8 (0x66CF000)
--16997:0:aspacem Valgrind: FATAL: VG_N_SEGMENTS is too low.
--16997:0:aspacem Increase it and rebuild. Exiting now.

The solution seems to be rebuilding Valgrind with said constant increased.

See http://www.nabble.com/VG_N_SEGMENTS-too-low%2C-valgrind-fails-td5092366.html for more info.

Additional info:
* valgrind 3.3.1-3 from extra
This task depends upon

Closed by  Allan McRae (Allan)
Wednesday, 17 June 2009, 11:34 GMT
Reason for closing:  Won't fix
Additional comments about closing:  See final comment
Comment by Dan McGee (toofishes) - Wednesday, 31 December 2008, 03:37 GMT
I'm not so certain we need to do this in our shipped package, as I'm guessing they pick a pretty sane default and that thread alludes that you shouldn't usually need to increase it. ABS might serve you best here.

Does this happen for every python program, or only what you were debugging?
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 31 May 2009, 05:15 GMT
this is still a problem with the latest valgrind-3.4.1-3?
Comment by Roman Kyrylych (Romashka) - Sunday, 14 June 2009, 22:14 GMT
Author of the report haven't responded for more than 3 months. I suggest closing this.
Comment by Paweł Paprota (yagood) - Monday, 15 June 2009, 06:54 GMT
  • Field changed: Percent Complete (100% → 0%)
Sorry for not responding - please reopen this as I managed to reproduce it with up-to-date Arch.
Comment by Allan McRae (Allan) - Monday, 15 June 2009, 06:59 GMT
Can you also respond to Dan's initial query about the frequency of this occurring? And also, did you try rebuilding with the constant increased and how much of an increase was needed in your case?
Comment by Allan McRae (Allan) - Monday, 15 June 2009, 07:13 GMT
Looking into this further, it is really not something we want to fix. This is the size of a static array used to store the details of each bit of memory assigned. Increasing this will result in a big chunk of overhead for the vast majority of cases where this works (as the upstream default is already quite large).

I think this has to be a case of the user needing to rebuild from ABS to satisfy their very specific need from this package.

Loading...