Bug 400099 - Memcheck produces truncated backtrace when len(argv + env) = 4096
Summary: Memcheck produces truncated backtrace when len(argv + env) = 4096
Status: REPORTED
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (other bugs)
Version First Reported In: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-21 10:11 UTC by Vyacheslav Belous
Modified: 2019-03-13 15:01 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
Valgrind result with '-v' (7.14 KB, text/x-log)
2018-10-21 10:11 UTC, Vyacheslav Belous
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vyacheslav Belous 2018-10-21 10:11:51 UTC
Created attachment 115798 [details]
Valgrind result with '-v'

SUMMARY
It looks like memcheck could produce truncated backtrace when "stacksize" in coregrind/m_initimg/initimg-linux.c:setup_client_stack becomes equal to 4096.

STEPS TO REPRODUCE
1. docker run -it --rm i386/centos:centos7 linux32
2. yum install vim gcc git make automake autoconf gcc-objc libobjc
3. build and install valgrind with patch (see ADDITIONAL INFORMATION)
4. cd /root
5. echo '
void foo(void *f) 
{
        int bar(void) { return f == (void *)0; }
        void *ff = bar; (void)ff;
}' > lib.c
6. gcc -shared -fPIC lib.c -ggdb3  -o libxxx.so
7. echo 'int main(void) { return 0; }' > xxx.c
8. gcc -ggdb3 -o binary  xxx.c -lobjc -L. -lxxx
9. LD_LIBRARY_PATH=. /usr/local/bin/valgrind --leak-check=full ./binary `perl -e '@o = map { "a" x 200 } (1 .. int($ARGV[0]/200)); push @o, "b" x ($ARGV[0] % 200); print "@o"' 1924`

OBSERVED RESULT
stringsize=3808 auxsize=168 stacksize=4096 maxsize=0x800000
clstack_start 0xFED9C000
clstack_end   0xFED9DFFF
....
==12870== 16 bytes in 2 blocks are definitely lost in loss record 4 of 11
==12870==    at 0x402B4C8: malloc (vg_replace_malloc.c:299)

EXPECTED RESULT
...
==16059== 8 bytes in 1 blocks are definitely lost in loss record 5 of 48
==16059==    at 0x402B4C8: malloc (vg_replace_malloc.c:299)
==16059==    by 0x404829A: objc_malloc (in /usr/lib/libobjc.so.4.0.0)
==16059==    by 0x4046EEE: ??? (in /usr/lib/libobjc.so.4.0.0)
==16059==    by 0x404710F: ??? (in /usr/lib/libobjc.so.4.0.0)
==16059==    by 0x404789E: __objc_exec_class (in /usr/lib/libobjc.so.4.0.0)
==16059==    by 0x404125C: ??? (in /usr/lib/libobjc.so.4.0.0)
==16059==    by 0x401020D: _dl_init (in /usr/lib/ld-2.17.so)
==16059==    by 0x400104E: ??? (in /usr/lib/ld-2.17.so)


ADDITIONAL INFORMATION
# docker, because I can reproduce it only on centos.i386 with packages:
rpm -qa | grep gcc
libgcc-4.8.5-28.el7_5.1.i686
gcc-4.8.5-28.el7_5.1.i686
gcc-objc-4.8.5-28.el7_5.1.i686

Valgrind built from master (d00dd9c2dd3f2e623f4db48d66d3b54b858842dd) with patch:
diff --git a/coregrind/m_initimg/initimg-linux.c b/coregrind/m_initimg/initimg-linux.c
index 61cc458..78e3fc5 100644
--- a/coregrind/m_initimg/initimg-linux.c
+++ b/coregrind/m_initimg/initimg-linux.c
@@ -492,7 +492,7 @@ Addr setup_client_stack( void*  init_sp,
    /* The max stack size */
    clstack_max_size = VG_PGROUNDUP(clstack_max_size);

-   if (0)
+   if (1)
       VG_(printf)("stringsize=%u auxsize=%u stacksize=%u maxsize=0x%lx\n"
                   "clstack_start %p\n"
                   "clstack_end   %p\n",
Comment 1 Julian Seward 2019-03-13 15:01:00 UTC
I can reproduce this.  I'd guess it has to do with the machinery
that decides what area of stack it is safe to allow the unwinder
to visit.