memcheck/tests/leak-segv-jmp

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

memcheck/tests/leak-segv-jmp

Petar Jovanovic
Has anyone tested memcheck/tests/leak-segv-jmp on platforms with larger
page sizes, e.g. 64K?
It causes a segmentation fault, since mprotect call protects non-
allocated areas too, and the call to calloc crashes afterwards.

Anyone objects if value of nr_ptr is increased to cover this case?
See the patch below.

Regards,
Petar


diff --git a/memcheck/tests/leak-segv-jmp.c b/memcheck/tests/leak-segv-jmp.c
index 1d1f84c..5435185 100644
--- a/memcheck/tests/leak-segv-jmp.c
+++ b/memcheck/tests/leak-segv-jmp.c
@@ -287,7 +287,7 @@ void f(void)
    long pagesize;
 #define RNDPAGEDOWN(a) ((long)a & ~(pagesize-1))
    int i;
-   const int nr_ptr = (10000 * 4)/sizeof(char*);
+   const int nr_ptr = (10000 * 20)/sizeof(char*);

    b10 = calloc (nr_ptr * sizeof(char*), 1);
    for (i = 0; i < nr_ptr; i++)
diff --git a/memcheck/tests/leak-segv-jmp.stderr.exp
b/memcheck/tests/leak-segv-jmp.stderr.exp
index 1ee37cd..f455bd5 100644
--- a/memcheck/tests/leak-segv-jmp.stderr.exp
+++ b/memcheck/tests/leak-segv-jmp.stderr.exp
@@ -6,7 +6,7 @@ LEAK SUMMARY:
    definitely lost: 0 bytes in 0 blocks
    indirectly lost: 0 bytes in 0 blocks
      possibly lost: 0 bytes in 0 blocks
-   still reachable: 41,000 bytes in 2 blocks
+   still reachable: 201,000 bytes in 2 blocks
         suppressed: 0 bytes in 0 blocks
 Reachable blocks (those to which a pointer was found) are not shown.
 To see them, rerun with: --leak-check=full --show-leak-kinds=all
@@ -21,7 +21,7 @@ LEAK SUMMARY:
    definitely lost: 1,000 bytes in 1 blocks
    indirectly lost: 0 bytes in 0 blocks
      possibly lost: 0 bytes in 0 blocks
-   still reachable: 40,000 bytes in 1 blocks
+   still reachable: 200,000 bytes in 1 blocks
         suppressed: 0 bytes in 0 blocks
 Reachable blocks (those to which a pointer was found) are not shown.
 To see them, rerun with: --leak-check=full --show-leak-kinds=all
@@ -37,7 +37,7 @@ LEAK SUMMARY:
    definitely lost: 1,000 bytes in 1 blocks
    indirectly lost: 0 bytes in 0 blocks
      possibly lost: 0 bytes in 0 blocks
-   still reachable: 40,000 bytes in 1 blocks
+   still reachable: 200,000 bytes in 1 blocks
         suppressed: 0 bytes in 0 blocks
 Reachable blocks (those to which a pointer was found) are not shown.
 To see them, rerun with: --leak-check=full --show-leak-kinds=all
@@ -53,7 +53,7 @@ LEAK SUMMARY:
    definitely lost: 1,000 bytes in 1 blocks
    indirectly lost: 0 bytes in 0 blocks
      possibly lost: 0 bytes in 0 blocks
-   still reachable: 40,000 bytes in 1 blocks
+   still reachable: 200,000 bytes in 1 blocks
         suppressed: 0 bytes in 0 blocks
 Reachable blocks (those to which a pointer was found) are not shown.
 To see them, rerun with: --leak-check=full --show-leak-kinds=all
@@ -65,7 +65,7 @@ expecting heuristic not to crash after full mprotect
    by 0x........: f (leak-segv-jmp.c:295)
    by 0x........: main (leak-segv-jmp.c:370)

-40,000 bytes in 1 blocks are possibly lost in loss record ... of ...
+200,000 bytes in 1 blocks are possibly lost in loss record ... of ...
    at 0x........: calloc (vg_replace_malloc.c:...)
    by 0x........: f (leak-segv-jmp.c:342)
    by 0x........: main (leak-segv-jmp.c:370)
@@ -73,8 +73,8 @@ expecting heuristic not to crash after full mprotect
 LEAK SUMMARY:
    definitely lost: 1,000 bytes in 1 blocks
    indirectly lost: 0 bytes in 0 blocks
-     possibly lost: 40,000 bytes in 1 blocks
-   still reachable: 40,000 bytes in 1 blocks
+     possibly lost: 200,000 bytes in 1 blocks
+   still reachable: 200,000 bytes in 1 blocks
         suppressed: 0 bytes in 0 blocks
 Reachable blocks (those to which a pointer was found) are not shown.
 To see them, rerun with: --leak-check=full --show-leak-kinds=all
@@ -83,19 +83,19 @@ finished
 LEAK SUMMARY:
    definitely lost: 1,000 bytes in 1 blocks
    indirectly lost: 0 bytes in 0 blocks
-     possibly lost: 40,000 bytes in 1 blocks
-   still reachable: 40,000 bytes in 1 blocks
+     possibly lost: 200,000 bytes in 1 blocks
+   still reachable: 200,000 bytes in 1 blocks
         suppressed: 0 bytes in 0 blocks
 Rerun with --leak-check=full to see details of leaked memory

 leaked:     1000 bytes in  1 blocks
-dubious:    40000 bytes in  1 blocks
-reachable:  40000 bytes in  1 blocks
+dubious:    200000 bytes in  1 blocks
+reachable:  200000 bytes in  1 blocks
 suppressed:   0 bytes in  0 blocks

 HEAP SUMMARY:
-    in use at exit: 81,000 bytes in 3 blocks
-  total heap usage: 3 allocs, 0 frees, 81,000 bytes allocated
+    in use at exit: 401,000 bytes in 3 blocks
+  total heap usage: 3 allocs, 0 frees, 401,000 bytes allocated

 For a detailed leak analysis, rerun with: --leak-check=full

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
Reply | Threaded
Open this post in threaded view
|

Re: memcheck/tests/leak-segv-jmp

Philippe Waroquiers
On Thu, 2017-02-02 at 18:14 +0100, Petar Jovanovic wrote:
> Has anyone tested memcheck/tests/leak-segv-jmp on platforms with larger
> page sizes, e.g. 64K?
> It causes a segmentation fault, since mprotect call protects non-
> allocated areas too, and the call to calloc crashes afterwards.
>
> Anyone objects if value of nr_ptr is increased to cover this case?
> See the patch below.
The change looks good to me.
Philippe



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-developers