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 <[email protected]>; Ivo Raisr
> <[email protected]>
> Cc: Valgrind Users <[email protected]>
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
