Is Valgrind supposed to work inside Flatpak sandbox?

[Dan Nicholson]

It doesn't seem like you don't have the debug symbols in the runtime.
Probably you need to install the Debug extension for your runtime.

On Thu, Dec 20, 2018, 10:01 AM Jiří Janoušek <janousek.jiri at gmail.com wrote:

> Hello Flatpak friends,
>
> I have this buggy sample C file from The Valgrind Quick Start Guide:
>
> ------- leak.c -----
> #include <stdlib.h>
> void f(void) {
>   int* x = malloc(10 * sizeof(int));
>   x[10] = 0;
> }
> int main(void) {
>   f();
>   return 0;
> }
> ------ EOF ------
>
> When I run Valgrind on a host (Fedora 29), I get the expected output:
>
> host$ gcc -g -O0 leak.c -o leak
> host$ valgrind --leak-check=yes ./leak
> ==10191== Memcheck, a memory error detector
> ==10191== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==10191== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright
> info
> ==10191== Command: ./leak
> ==10191==
> ==10191== Invalid write of size 4
> ==10191==    at 0x401144: f (leak.c:4)
> ==10191==    by 0x401155: main (leak.c:7)
> ==10191==  Address 0x4a3b068 is 0 bytes after a block of size 40 alloc'd
> ==10191==    at 0x483880B: malloc (vg_replace_malloc.c:299)
> ==10191==    by 0x401137: f (leak.c:3)
> ==10191==    by 0x401155: main (leak.c:7)
> ==10191==
> ==10191==
> ==10191== HEAP SUMMARY:
> ==10191==     in use at exit: 40 bytes in 1 blocks
> ==10191==   total heap usage: 1 allocs, 0 frees, 40 bytes allocated
> ==10191==
> ==10191== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
> ==10191==    at 0x483880B: malloc (vg_replace_malloc.c:299)
> ==10191==    by 0x401137: f (leak.c:3)
> ==10191==    by 0x401155: main (leak.c:7)
> ==10191==
> ==10191== LEAK SUMMARY:
> ==10191==    definitely lost: 40 bytes in 1 blocks
> ==10191==    indirectly lost: 0 bytes in 0 blocks
> ==10191==      possibly lost: 0 bytes in 0 blocks
> ==10191==    still reachable: 0 bytes in 0 blocks
> ==10191==         suppressed: 0 bytes in 0 blocks
> ==10191==
> ==10191== For counts of detected and suppressed errors, rerun with: -v
> ==10191== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
>
> However, when I run Valgrind inside a Flatpak sandbox (flatpak
> 1.0.6-3.fc29), I get only nonsense:
>
> host$ flatpak run --devel --filesystem=$PWD org.gnome.Sdk//3.30
> sh-4.4$ rm -f leak; gcc -g -O0 leak.c -o leak
> sh-4.4$ valgrind --leak-check=yes ./leak
> ==11== Memcheck, a memory error detector
> ==11== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==11== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
> ==11== Command: ./leak
> ==11==
> ==11== Conditional jump or move depends on uninitialised value(s)
> ==11==    at 0x401D248: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.27.so)
> ==11==    by 0x40081DC: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.27.so)
> ==11==
> ==11== Conditional jump or move depends on uninitialised value(s)
> ==11==    at 0x401D46E: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.27.so)
> ==11==    by 0x2D34365F3638782E: ???
> ==11==    by 0x6E672D78756E696B: ???
> ==11==    by 0x6972676C61762F74: ???
> ==11==    by 0x65727067762F646D: ???
> ==11==    by 0x726F635F64616F6B: ???
> ==11==    by 0x2D3436646D612D64: ???
> ==11==    by 0x6F732E78756E696B: ???
> ==11==
> ==11== Conditional jump or move depends on uninitialised value(s)
> ==11==    at 0x401D46E: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.27.so)
> ==11==    by 0x400B580: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.27.so)
> ==11==
> ==11==
> ==11== HEAP SUMMARY:
> ==11==     in use at exit: 0 bytes in 0 blocks
> ==11==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==11==
> ==11== All heap blocks were freed -- no leaks are possible
> ==11==
> ==11== For counts of detected and suppressed errors, rerun with: -v
> ==11== Use --track-origins=yes to see where uninitialised values come from
> ==11== ERROR SUMMARY: 6 errors from 3 contexts (suppressed: 0 from 0)
>
> Are there any magic spells to make Valgrind work?
>
> Best regards,
>
> Jiri Janousek
> _______________________________________________
> Flatpak mailing list
> Flatpak at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/flatpak
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/flatpak/attachments/20181220/a791c05c/attachment.html>