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

Reply via email to