pthreads app fails with assert in vmareas when run under drcachesim

[prasun3]

Describe the bug See initial post here https://groups.google.com/g/DynamoRIO-Users/c/kBWn4YVQRe0 and more details below

The following assert is seen when pthreads app is run under drcachesim. There is no error seen if run with just drrun.

$ bin32/drrun -debug -loglevel 4 -t drcachesim -- suite/tests/bin/pthreads.pthreads 10000
<log dir=/home/prasun/dynamorio-debug-32b-failure/build-32b/bin32/../logs/pthreads.pthreads.2478.00000000>
<Starting application /home/prasun/dynamorio-debug-32b-failure/build-32b/suite/tests/bin/pthreads.pthreads (2478)>
...
<Application /home/prasun/dynamorio-debug-32b-failure/build-32b/suite/tests/bin/pthreads.pthreads (2478).  Internal Error: DynamoRIO debug check failure: /home/prasun/dynamorio-debug-32b-failure/dynamorio/core/vmareas.c:925 start < end

The assert fails because start and end have the same value. This is because the size is detected as 0.

$ grep "^syscall: mmap2" logs/pthreads.pthreads.2478.00000000/log.0.2478.html
syscall: mmap2 addr=0x00000000 size=0x2000 prot=0x3 flags=0x22 offset=0x0 fd=-1
syscall: mmap2 addr=0x00000000 size=0x1a97b prot=0x1 flags=0x2 offset=0x0 fd=3
syscall: mmap2 addr=0x00000000 size=0x1f298 prot=0x5 flags=0x802 offset=0x0 fd=3
syscall: mmap2 addr=0xf7594000 size=0x2000 prot=0x3 flags=0x812 offset=0x1b fd=3
syscall: mmap2 addr=0xf7596000 size=0x1298 prot=0x3 flags=0x32 offset=0x0 fd=-1
syscall: mmap2 addr=0x00000000 size=0x1dba20 prot=0x5 flags=0x802 offset=0x0 fd=3
syscall: mmap2 addr=0xf7572000 size=0x3000 prot=0x3 flags=0x812 offset=0x1d5 fd=3
syscall: mmap2 addr=0xf7575000 size=0x2a20 prot=0x3 flags=0x32 offset=0x0 fd=-1
syscall: mmap2 addr=0x00000000 size=0x0 prot=0x0 flags=0x20022 offset=0x0 fd=-1

The test runs fine when run with just drrun

$ bin32/drrun -debug -loglevel 4 -- suite/tests/bin/pthreads.pthreads 10000
<log dir=/home/prasun/dynamorio-debug-32b-failure/build-32b/bin32/../logs/pthreads.pthreads.2463.00000000>
<Starting application /home/prasun/dynamorio-debug-32b-failure/build-32b/suite/tests/bin/pthreads.pthreads (2463)>
<Initial options = -no_dynamic_options -loglevel 4 -code_api -stack_size 56K -signal_stack_size 32K -max_elide_jmp 0 -max_elide_call 0 -early_inject -emulate_brk -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct >
<Paste into GDB to debug DynamoRIO clients:
set confirm off
add-symbol-file '/home/prasun/dynamorio-debug-32b-failure/build-32b/lib32/debug/libdynamorio.so' 0xf7c20ddc
>
Estimation of pi is 3.141592654423132
<Stopping application /home/prasun/dynamorio-debug-32b-failure/build-32b/suite/tests/bin/pthreads.pthreads (2463)>

We can see that there is no mmap2 syscall with size 0 in this case.

$ grep "^syscall: mmap2" logs/pthreads.pthreads.2463.00000000/log.0.2463.html
syscall: mmap2 addr=0x00000000 size=0x2000 prot=0x3 flags=0x22 offset=0x0 fd=-1
syscall: mmap2 addr=0x00000000 size=0x1a97b prot=0x1 flags=0x2 offset=0x0 fd=3
syscall: mmap2 addr=0x00000000 size=0x1f298 prot=0x5 flags=0x802 offset=0x0 fd=3
syscall: mmap2 addr=0xf7bb2000 size=0x2000 prot=0x3 flags=0x812 offset=0x1b fd=3
syscall: mmap2 addr=0xf7bb4000 size=0x1298 prot=0x3 flags=0x32 offset=0x0 fd=-1
syscall: mmap2 addr=0x00000000 size=0x1dba20 prot=0x5 flags=0x802 offset=0x0 fd=3
syscall: mmap2 addr=0xf7b90000 size=0x3000 prot=0x3 flags=0x812 offset=0x1d5 fd=3
syscall: mmap2 addr=0xf7b93000 size=0x2a20 prot=0x3 flags=0x32 offset=0x0 fd=-1
syscall: mmap2 addr=0x00000000 size=0x801000 prot=0x0 flags=0x20022 offset=0x0 fd=-1
syscall: mmap2 addr=0x00000000 size=0x801000 prot=0x0 flags=0x20022 offset=0x0 fd=-1

When I run the app under gdb(gdb suite/tests/bin/pthreads.pthreads 10000), I see that the last two syscalls come from allocate_stack in pthread_create

(gdb) where
#0  0xf7fd51b9 in __kernel_vsyscall ()
#1  0xf7eab464 in __GI___mmap (addr=0x0, len=0x801000, prot=0x0, flags=0x20022, fd=0xffffffff, offset=0x0)
    at ../sysdeps/unix/sysv/linux/mmap.c:42
#2  0xf7f99e4d in allocate_stack (stack=<synthetic pointer>, pdp=<synthetic pointer>, attr=0xffffd37c) at allocatestack.c:563
#3  __pthread_create_2_1 (newthread=0xffffd3ec, attr=0x0, start_routine=0x56556228 <process>, arg=0x565570f7) at pthread_create.c:644
#4  0x56556368 in main (argc=0x1, argv=0xffffd4b4)
    at /home/prasun/dynamorio-debug-32b-failure/dynamorio/suite/tests/pthreads/pthreads.c:100

(gdb) where
#0  0xf7fd51b9 in __kernel_vsyscall ()
#1  0xf7eab464 in __GI___mmap (addr=0x0, len=0x801000, prot=0x0, flags=0x20022, fd=0xffffffff, offset=0x0)
    at ../sysdeps/unix/sysv/linux/mmap.c:42
#2  0xf7f99e4d in allocate_stack (stack=<synthetic pointer>, pdp=<synthetic pointer>, attr=0xffffd37c) at allocatestack.c:563
#3  __pthread_create_2_1 (newthread=0xffffd3e8, attr=0x0, start_routine=0x56556228 <process>, arg=0x565570f9) at pthread_create.c:644
#4  0x56556388 in main (argc=0x1, argv=0xffffd4b4)
    at /home/prasun/dynamorio-debug-32b-failure/dynamorio/suite/tests/pthreads/pthreads.c:101

To Reproduce See above

Expected behavior No crash

Screenshots or Pasted Text See above

Versions

• What version of DynamoRIO are you using?
  • 7e5a3e84
• Does the latest build from https://github.com/DynamoRIO/dynamorio/releases solve the problem?
  • No
• What operating system version are you running on? ("Windows 10" is not sufficient: give the release number.)
  • Ubuntu 18
• Is your application 32-bit or 64-bit?
  • 32 bit

Additional context

[derekbruening]

You're saying drcachesim corrupts that syscall parameter? If you could track down where that corruption happens. Running offline and filtering and delayed tracing to vary the instrumentation may help isolate it; delayed tracing can be used to binary search if it only fails with full tracing.