Re: [Valgrind-users] failed in UME with error 22

[Philippe W. <phi...@sk...>]

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:(.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 <phi...@sk...>; Ivo Raisr
> > <iv...@iv...>
> > Cc: Valgrind Users <val...@li...>
> > 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