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:(.text+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