|
From: Catherine M. <Cat...@jp...> - 2006-06-28 20:40:47
|
Hi, I'm running Valgrind 3.2.0 on a linux box running Fedora Core 5 (AMD Opteron CPU's) on a large Fortran code. Valgrind exits early on in the run with the following message: --20872:0:aspacem Valgrind: FATAL: VG_N_SEGMENTS is too low. --20872:0:aspacem Increase it and rebuild. Exiting now. Does this mean that I have to recompile my code, or recompile valgrind? What should the limit be increased to, and what are the instructions for fixing this? Can somebody also provide a simple explanation as to what this message means? Thanks, Catherine ---------------------------------------------------- Catherine Moroney Jet Propulsion Lab, CalTech MailStop 168-414 4800 Oak Grove Drive Pasadena, CA 91109-8099 Phone: 818-393-3392 Fax: 818-393-3134 Email: Cat...@jp... |
|
From: Tom H. <to...@co...> - 2006-06-28 21:55:58
|
In message <e05...@jp...>
Catherine Moroney <Cat...@jp...> wrote:
> I'm running Valgrind 3.2.0 on a linux box running Fedora Core 5 (AMD
> Opteron CPU's)
> on a large Fortran code.
>
> Valgrind exits early on in the run with the following message:
>
> --20872:0:aspacem Valgrind: FATAL: VG_N_SEGMENTS is too low.
> --20872:0:aspacem Increase it and rebuild. Exiting now.
>
> Does this mean that I have to recompile my code, or recompile valgrind?
Recompile valgrind.
> What should the limit be increased to, and what are the
> instructions for fixing this?
It depends on your program how large it needs to be - just try
increasing it until it works.
> Can somebody also provide a simple explanation as to what this
> message means?
That constant (in coregrind/m_aspacemgr/aspacemgr.c) controls the
size of the array used to hold details of each chunk of memory that
is mapped into the process address space.
Unfortunately making that table dynamically sized introduces a
circular problem of having to allocate memory in order to record
what memory is allocated, so it has to be kept as a fixed size
table.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-06-28 22:08:31
|
> Valgrind exits early on in the run with the following message: > > --20872:0:aspacem Valgrind: FATAL: VG_N_SEGMENTS is too low. > --20872:0:aspacem Increase it and rebuild. Exiting now. > > Does this mean that I have to recompile my code, or recompile valgrind? It means you have to recompile V. grep for VG_N_SEGMENTS in coregrind/m_aspacemgr/aspacemgr.c, increase (to 4000 perhaps) and rebuild Valgrind; then try again. J |
|
From: Julian S. <js...@ac...> - 2006-06-28 22:24:55
|
> Can somebody also provide a simple explanation as to what this > message means? Oops. Missed that bit. This constant defines the size of a fixed size table that V uses to keep track of all memory segments in the address space of the process. Roughly, each loaded .so occupies 2 or 3 table entries, and then some (possibly large) number of extras are also used depending on how your program behaves. It's quite unusual for the table to overflow though (2000 different non-mergeable segments is really a lot). J |
|
From: Dennis L. <pla...@pr...> - 2006-07-03 11:09:11
|
Am Mittwoch, den 28.06.2006, 22:55 +0100 schrieb Tom Hughes: > In message <e05...@jp...> > Catherine Moroney <Cat...@jp...> wrote: > That constant (in coregrind/m_aspacemgr/aspacemgr.c) controls the > size of the array used to hold details of each chunk of memory that > is mapped into the process address space. > > Unfortunately making that table dynamically sized introduces a > circular problem of having to allocate memory in order to record > what memory is allocated, so it has to be kept as a fixed size > table. Just a rough guess without knowing what Im talking about: could you maybe have a small fixed table, use it in the beginning and then start dynamically allocating it? greets Dennis |
|
From: Julian S. <js...@ac...> - 2006-07-17 10:49:51
|
On Monday 03 July 2006 12:08, Dennis Lubert wrote: > Am Mittwoch, den 28.06.2006, 22:55 +0100 schrieb Tom Hughes: > > In message <e05...@jp...> > > Catherine Moroney <Cat...@jp...> wrote: > > That constant (in coregrind/m_aspacemgr/aspacemgr.c) controls the > > size of the array used to hold details of each chunk of memory that > > is mapped into the process address space. > > > > Unfortunately making that table dynamically sized introduces a > > circular problem of having to allocate memory in order to record > > what memory is allocated, so it has to be kept as a fixed size > > table. > > Just a rough guess without knowing what Im talking about: could you > maybe have a small fixed table, use it in the beginning and then start > dynamically allocating it? It's a nasty circular problem. The table keeps track of memory segments, including those belonging to our dynamic memory manager. Dynamic memory allocation can require more memory segments to be created. Making this dynamically allocated would give two modules inside V, both of which require the other to be initialised first. That used to be the situation and has been known to cause crashes at startup. (Almost) all other data structures in V are indeed dynamically allocated. J |