If this is an embedded system do you actually have enough memory to use valgrind on it - your program will use at least twice the normal amount of memory when running under memcheck.

If you do then are you linking your code to run at some specific address - that is the sort of thing I can imagine you might do on an embedded system and it can cause problems if it clashes with the address space layout valgrind uses.

At the end of the day there is some incompatibility between the mmap calls you are trying to do and the memory layout your program has when running under valgrind (which is different to when running normally) and you will need to try and understand the nature of that difference in order to resolve it - start by trying to gather information on exactly what mmap is failing.

(In reply to Tom Hughes from comment #1)
> If this is an embedded system do you actually have enough memory to use
> valgrind on it - your program will use at least twice the normal amount of
> memory when running under memcheck.
> 
> If you do then are you linking your code to run at some specific address -
> that is the sort of thing I can imagine you might do on an embedded system
> and it can cause problems if it clashes with the address space layout
> valgrind uses.
> 
> At the end of the day there is some incompatibility between the mmap calls
> you are trying to do and the memory layout your program has when running
> under valgrind (which is different to when running normally) and you will
> need to try and understand the nature of that difference in order to resolve
> it - start by trying to gather information on exactly what mmap is failing.

Thank you for the response

Created attachment 125712 [details]
simple mmap testapp execution log

In further investigation, found the issue is with invalid offset under valgrind.

And in high-level, During normal run mmap2 is getting executed where as mmap is getting executed under valgrind.

Attached strace bootup logs for reference.

Normal Run:

open("/tmp/1.txt", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 017754017774) = 3
mmap2(NULL, 157286400, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0xc0200000) = 0x6e196000

Valgrind Run:

open("/tmp/1.txt", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 017662266754) = 3
mmap(0x4980000, 157286400, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0xc0200000) = 0x4980000

And it looks based on mapping for syscalls. if so where this can be configured for mips_mmap2 in valgrind code.

SYSCALL_DEFINE6(mips_mmap, unsigned long, addr, unsigned long, len,
        unsigned long, prot, unsigned long, flags, unsigned long,
        fd, off_t, offset)
{
        unsigned long result;

        result = -EINVAL;
        if (offset & ~PAGE_MASK)
                goto out;

        result = sys_mmap_pgoff(addr, len, prot, flags, fd, offset >> PAGE_SHIFT);

out:
        return result;
}

SYSCALL_DEFINE6(mips_mmap2, unsigned long, addr, unsigned long, len,
        unsigned long, prot, unsigned long, flags, unsigned long, fd,
        unsigned long, pgoff)
{
        if (pgoff & (~PAGE_MASK >> 12))
                return -EINVAL;

        return sys_mmap_pgoff(addr, len, prot, flags, fd, pgoff >> (PAGE_SHIFT-12));
}

In what way is the offset "invalid" and why does it matter whether mmap or mmap2 is used? Are you trying to use some feature that only mmap2 supports?

So I can see that both offsets in the strace are the same which isn't what we would expect if your application is calling mmap2 as it should manipulate it differently before passing it to sys_mmap_pgoff.

Are you able to capture this map with --trace-syscalls=yes so that we can see what call valgrind is seeing from your application?

(In reply to Tom Hughes from comment #4)
> In what way is the offset "invalid" and why does it matter whether mmap or
> mmap2 is used? Are you trying to use some feature that only mmap2 supports?

Sorry for delayed in my response. We have a problem with large offset which the offset can't find available in system memory space. And it is typically 2GB(2*1GB).

And the offset range expected for 2nd segment from 0x9000_0000 to 0xCFFF_FFFF.

I think yes, we are interested for mmap2 feature as we could some code manipulation with offset.

Created attachment 126420 [details]
Captured log with system call traces

(In reply to Tom Hughes from comment #5)
> So I can see that both offsets in the strace are the same which isn't what
> we would expect if your application is calling mmap2 as it should manipulate
> it differently before passing it to sys_mmap_pgoff.
> 
> Are you able to capture this map with --trace-syscalls=yes so that we can
> see what call valgrind is seeing from your application?

PFA, for system call traces and help me to map the system call mmap2 for valgrind.

@Krishna

Can you share some steps to reproduce this issue?
Can you come up with a small example, build it statically and upload the binary somewhere?

Created attachment 126722 [details]
mips mmap executable file

(In reply to Petar Jovanovic from comment #9)
> @Krishna
> 
> Can you share some steps to reproduce this issue?
> Can you come up with a small example, build it statically and upload the
> binary somewhere?

Thanks for your the interest on this issue.Please find attached mips arch executable file.

pre-conditions:

create an dummy text file in /tmp folder with 1.txt name

Steps to reproduce:

1. Execute the file in mips platform and capture traces for strace -e trace=open,mmap,mmap2

2. Repeat the step:1 with valgrind option along with strace

     strace -e trace=open,mmap,mmap2 valgrind <exe>

observations:

We may not encounter with failure but could notice syscall mapping mmap to mmap2     under valgrind as explained.

(In reply to Krishna from comment #10)
> Created attachment 126722 [details]
> mips mmap executable file

This is not statically linked program.

$ ldd mips_mmap_exe
        libssp.so.0 => not found
        libgcc_s.so.1 => /lib/mipsel-linux-gnu/libgcc_s.so.1 (0x77250000)
        libc.so.0 => not found
        libc.so.6 => /lib/mipsel-linux-gnu/libc.so.6 (0x770b0000)
        /lib/ld-uClibc.so.0 => /lib/ld.so.1 (0x772b0000)

Can you share the source code of this example and what toolchain to use, how to build it, so I can reproduce the issue?

(In reply to Petar Jovanovic from comment #12)
> (In reply to Krishna from comment #10)
> > Created attachment 126722 [details]
> > mips mmap executable file
> 
> This is not statically linked program.
> 
> $ ldd mips_mmap_exe
>         libssp.so.0 => not found
>         libgcc_s.so.1 => /lib/mipsel-linux-gnu/libgcc_s.so.1 (0x77250000)
>         libc.so.0 => not found
>         libc.so.6 => /lib/mipsel-linux-gnu/libc.so.6 (0x770b0000)
>         /lib/ld-uClibc.so.0 => /lib/ld.so.1 (0x772b0000)
> 
> Can you share the source code of this example and what toolchain to use, how
> to build it, so I can reproduce the issue?

Hi Peter,

Please find the below source code built for shared executable.

Toolchain used: stbgcc-4.5.4-2.9.tar.bz

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/mman.h>
#include <errno.h>
#include <sys/stat.h>
#include <fcntl.h>

#define BDBG_UINT64_ARG(x) (unsigned )((x)>>32), (unsigned )(x)
#define BDBG_UINT64_FMT "0x%x%08x"
int main()
{
       void *addr;
        unsigned length=157286400;
        unsigned long long offset=0x0c0200000;

        int fd=open("/tmp/1.txt", O_RDWR | O_CREAT | O_TRUNC);

        addr = mmap(0, length, PROT_READ|PROT_WRITE, MAP_SHARED, fd, offset);
        if (addr == MAP_FAILED)
        {
               printf("ERROR:mmap failed: offset " BDBG_UINT64_FMT ", size=%u, errno=%d\n",
                BDBG_UINT64_ARG(offset), (unsigned)length, errno);
                addr = NULL;
        }
        else
        {
                printf("SUCCESS:mmap  offset:" BDBG_UINT64_FMT " size:%u -> %p\n",
                BDBG_UINT64_ARG(offset), (unsigned)length, addr);
        }

       return 0;
}

Compile using mips-cc with mentioned options:

<ToolChainPath>/stbgcc-4.5.4-2.9/bin//mipsel-linux-uclibc-gcc -o mmap_krish mmap.c  -finline-limit=300 -fPIC -D_GNU_SOURCE=1 -D_FILE_OFFSET_BITS=64  -fstack-protector-all -D_FORTIFY_SOURCE=2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DBSTD_CPU_ENDIAN=BSTD_ENDIAN_LITTLE