The reason we allocate everything statically is safety. What about you, Ivo, any other hints on creating space for this executable?
This seems a limitation of Valgrind, should I create a bug report? It's a software limit, while the limit should be the hardware, right? João M. S. Silva > -----Original Message----- > From: Philippe Waroquiers [mailto:philippe.waroqui...@skynet.be] > Sent: 22 de fevereiro de 2018 06:34 > To: SILVA João <joao.si...@altran.com>; Ivo Raisr <iv...@ivosh.net> > Cc: Valgrind Users <valgrind-users@lists.sourceforge.net> > Subject: Re: [Valgrind-users] failed in UME with error 22 > > I would suggest to stop doing such huge static allocations, > and replace these huge static allocations by dynamic allocation > done at elaboration time. > This should give you several benefits: > * you should be able to run under Valgrind without the below problems > * you will get additional verifications/safety net when running under > valgrind, as valgrind does not check static data as well as > dynamic data. > * you can at startup decide on how much memory you use, without the > need > to recompile. > > If your coding standard strictly forbids dynamic allocation even at > elaboration > time, then use e.g. gnatprep to have 2 modes: > * a static data version > * a dynamic version > (the changes to switch between the 2 versions should be limited to the > variable declarations, thanks to the compiler using implicit .all > > > Apart of the above, I have no idea what the below linker error means, > and how to fix it. > > Philippe > > > On Wed, 2018-02-21 at 12:11 +0000, SILVA João wrote: > > Hi again, > > > > Our program now seems to have enlarged and now occupies: > > > > valgrind: mmap(0xa2d000, 2154274816) failed in UME with error 22 > (Invalid argument). > > valgrind: this can be caused by executables with very large text, data > or bss segments. > > > > However, I cannot relocate it anymore: > > > > $ grep 0x7f000000 configure.ac > > valt_load_address_pri_norml="0x7f000000" > > valt_load_address_pri_norml="0x7f000000" > > valt_load_address_pri_norml="0x7f000000" > > valt_load_address_pri_norml="0x7f000000" > > valt_load_address_sec_norml="0x7f000000" > > > > This value, 0x7f000000, is too much: > > > > ../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a- > m_mallocfree.o): In function `sanity_check_malloc_arena': > > > /home/AltranUK/jsilva.fs/src/valgrind/coregrind/m_mallocfree.c:1321:(.te > xt+0xe19): additional relocation overflows omitted from the output > > collect2: error: ld returned 1 exit status > > make[3]: *** [memcheck-amd64-linux] Error 1 > > > > Is there an alternative to create more space for the program? > > > > Thanks. > > > > João M. S. Silva > > > > > -----Original Message----- > > > From: Silva João > > > Sent: 10 de dezembro de 2017 21:10 > > > To: Philippe Waroquiers <philippe.waroqui...@skynet.be>; Ivo Raisr > > > <iv...@ivosh.net> > > > Cc: Valgrind Users <valgrind-users@lists.sourceforge.net> > > > Subject: RE: [Valgrind-users] failed in UME with error 22 > > > > > > Then you have to understand what this task is doing. > > > Isn't the backtrace pointing at what the code is doing and what this > > > read could be ? > > > Look at the file descriptor on which it is reading and see what this > fd > > > is ? > > > Is it a real file ? (unlikely to be blocking then) > > > Is it a pipe ? A tcp/ip connection ? > > > Use lsof if you cannot determine in gdb what this fd is for. > > > > > > [JMSS] It's a file. After I added some prints for debugging, the > main > > > thread seem to get unblocked (?) > > > > > > This can be false positive of course, and of course, this can be a > true > > > positive :). > > > With only an address, no access to the code, no backtrace, no > > > reproducer, > > > there is not much feedback we can give. > > > > > > Let me just tell that at my work, we have added for helgrind a few > > > suppression > > > entries related to the 'low level implementation of the gnat > runtime', > > > to > > > suppress false positive created by the low level inner working of > the > > > runtime. > > > > > > To see what you case is, the minimum needed would be the stack > traces of > > > the error msg. > > > > > > In summary, at this point, it looks like you have to debug your > > > application > > > when running under valgrind, and then you might determine if what > you > > > see > > > is a real application bug, or a valgrind bug/limitation e.g. in the > > > valgrind > > > scheduler/signal handling/syscall handling or whatever. > > > > > > At this state, without further info, let's assume you have > > > an application bug :) > > > > > > [JMSS] Yes, I think that we are now able to debug the application. > It > > > seems to run under nulgrind, helgrind and memcheck, so it should be > > > "good" to go. > > > > > > [JMSS] I'll try to provide the patch for the configuration now. > > > > > > João M. S. Silva ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
