All of lore.kernel.org
 help / color / mirror / Atom feed
* [patch] [PATCH] Fix memory leaks
@ 2008-09-11 15:23 Bernhard Walle
  2008-09-12  2:03 ` Ken'ichi Ohmichi
  0 siblings, 1 reply; 2+ messages in thread
From: Bernhard Walle @ 2008-09-11 15:23 UTC (permalink / raw)
  To: oomichi; +Cc: kexec

This memory leaks appear in valigrind run:

    makedumpfile Completed.
    ==6024== 
    ==6024== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 1)
    ==6024== malloc/free: in use at exit: 8,838 bytes in 5 blocks.
    ==6024== malloc/free: 80 allocs, 75 frees, 192,858 bytes allocated.
    ==6024== For counts of detected errors, rerun with: -v
    ==6024== searching for pointers to 5 not-freed blocks.
    ==6024== checked 70,864 bytes.
    ==6024== 
    ==6024== 
    ==6024== 22 bytes in 1 blocks are definitely lost in loss record 2 of 5
    ==6024==    at 0x4C2560E: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
    ==6024==    by 0x416955: initial (makedumpfile.c:3318)
    ==6024==    by 0x418954: create_dumpfile (makedumpfile.c:6000)
    ==6024==    by 0x4191AA: main (makedumpfile.c:6299)
    ==6024== 
    ==6024== 
    ==6024== 4,120 bytes in 1 blocks are definitely lost in loss record 4 of 5
    ==6024==    at 0x4C2560E: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
    ==6024==    by 0x409F72: prepare_dump_bitmap (makedumpfile.c:4338)
    ==6024==    by 0x4187D8: create_dump_bitmap (makedumpfile.c:4361)
    ==6024==    by 0x41886C: create_dumpfile (makedumpfile.c:6005)
    ==6024==    by 0x4191AA: main (makedumpfile.c:6299)
    ==6024== 
    ==6024== 
    ==6024== 4,120 bytes in 1 blocks are definitely lost in loss record 5 of 5
    ==6024==    at 0x4C2560E: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
    ==6024==    by 0x409F51: prepare_dump_bitmap (makedumpfile.c:4333)
    ==6024==    by 0x4187D8: create_dump_bitmap (makedumpfile.c:4361)
    ==6024==    by 0x41886C: create_dumpfile (makedumpfile.c:6005)
    ==6024==    by 0x4191AA: main (makedumpfile.c:6299)
    ==6024== 
    ==6024== LEAK SUMMARY:
    ==6024==    definitely lost: 8,262 bytes in 3 blocks.
    ==6024==      possibly lost: 0 bytes in 0 blocks.
    ==6024==    still reachable: 576 bytes in 2 blocks.
    ==6024==         suppressed: 0 bytes in 0 blocks.
    ==6024== Reachable blocks (those to which a pointer was found) are not shown.
    ==6024== To see them, rerun with: --leak-check=full --show-reachable=yes

Although it's not strictly necessary to free memory at the end of program run since
it gets freed automatically, it still makes sense to have a clean valgrind run to be
able to check the program for "real" memory leaks with valgrind.


Signed-off-by: Bernhard Walle <bwalle@suse.de>

---
 makedumpfile.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -5268,6 +5268,14 @@ close_dump_bitmap(void)
 		ERRMSG("Can't close the bitmap file(%s). %s\n",
 		    info->name_bitmap, strerror(errno));
 	free(info->name_bitmap);
+
+	/* free 1st bitmap */
+	free(info->bitmap1);
+	info->bitmap1 = NULL;
+
+	/* free 2nd bitmap */
+	free(info->bitmap2);
+	info->bitmap2 = NULL;
 }
 
 void
@@ -5332,6 +5340,10 @@ close_files_for_creating_dumpfile(void)
 	else if (info->dump_level > DL_EXCLUDE_ZERO)
 		close_kernel_file();
 
+	/* free name for vmcoreinfo */
+	free(info->name_vmcoreinfo);
+	info->name_vmcoreinfo = NULL;
+
 	close_dump_memory();
 
 	close_dump_file();

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [patch] [PATCH] Fix memory leaks
  2008-09-11 15:23 [patch] [PATCH] Fix memory leaks Bernhard Walle
@ 2008-09-12  2:03 ` Ken'ichi Ohmichi
  0 siblings, 0 replies; 2+ messages in thread
From: Ken'ichi Ohmichi @ 2008-09-12  2:03 UTC (permalink / raw)
  To: Bernhard Walle, kexec

[-- Attachment #1: Type: text/plain, Size: 3657 bytes --]


Hi Bernhard,

Good catching :-)
This patch also will be merged to the next release.


Thanks
Ken'ichi Ohmichi

Bernhard Walle wrote:
> This memory leaks appear in valigrind run:
> 
>     makedumpfile Completed.
>     ==6024== 
>     ==6024== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 1)
>     ==6024== malloc/free: in use at exit: 8,838 bytes in 5 blocks.
>     ==6024== malloc/free: 80 allocs, 75 frees, 192,858 bytes allocated.
>     ==6024== For counts of detected errors, rerun with: -v
>     ==6024== searching for pointers to 5 not-freed blocks.
>     ==6024== checked 70,864 bytes.
>     ==6024== 
>     ==6024== 
>     ==6024== 22 bytes in 1 blocks are definitely lost in loss record 2 of 5
>     ==6024==    at 0x4C2560E: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
>     ==6024==    by 0x416955: initial (makedumpfile.c:3318)
>     ==6024==    by 0x418954: create_dumpfile (makedumpfile.c:6000)
>     ==6024==    by 0x4191AA: main (makedumpfile.c:6299)
>     ==6024== 
>     ==6024== 
>     ==6024== 4,120 bytes in 1 blocks are definitely lost in loss record 4 of 5
>     ==6024==    at 0x4C2560E: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
>     ==6024==    by 0x409F72: prepare_dump_bitmap (makedumpfile.c:4338)
>     ==6024==    by 0x4187D8: create_dump_bitmap (makedumpfile.c:4361)
>     ==6024==    by 0x41886C: create_dumpfile (makedumpfile.c:6005)
>     ==6024==    by 0x4191AA: main (makedumpfile.c:6299)
>     ==6024== 
>     ==6024== 
>     ==6024== 4,120 bytes in 1 blocks are definitely lost in loss record 5 of 5
>     ==6024==    at 0x4C2560E: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
>     ==6024==    by 0x409F51: prepare_dump_bitmap (makedumpfile.c:4333)
>     ==6024==    by 0x4187D8: create_dump_bitmap (makedumpfile.c:4361)
>     ==6024==    by 0x41886C: create_dumpfile (makedumpfile.c:6005)
>     ==6024==    by 0x4191AA: main (makedumpfile.c:6299)
>     ==6024== 
>     ==6024== LEAK SUMMARY:
>     ==6024==    definitely lost: 8,262 bytes in 3 blocks.
>     ==6024==      possibly lost: 0 bytes in 0 blocks.
>     ==6024==    still reachable: 576 bytes in 2 blocks.
>     ==6024==         suppressed: 0 bytes in 0 blocks.
>     ==6024== Reachable blocks (those to which a pointer was found) are not shown.
>     ==6024== To see them, rerun with: --leak-check=full --show-reachable=yes
> 
> Although it's not strictly necessary to free memory at the end of program run since
> it gets freed automatically, it still makes sense to have a clean valgrind run to be
> able to check the program for "real" memory leaks with valgrind.
> 
> 
> Signed-off-by: Bernhard Walle <bwalle@suse.de>
> 
> ---
>  makedumpfile.c |   12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> --- a/makedumpfile.c
> +++ b/makedumpfile.c
> @@ -5268,6 +5268,14 @@ close_dump_bitmap(void)
>  		ERRMSG("Can't close the bitmap file(%s). %s\n",
>  		    info->name_bitmap, strerror(errno));
>  	free(info->name_bitmap);
> +
> +	/* free 1st bitmap */
> +	free(info->bitmap1);
> +	info->bitmap1 = NULL;
> +
> +	/* free 2nd bitmap */
> +	free(info->bitmap2);
> +	info->bitmap2 = NULL;
>  }
>  
>  void
> @@ -5332,6 +5340,10 @@ close_files_for_creating_dumpfile(void)
>  	else if (info->dump_level > DL_EXCLUDE_ZERO)
>  		close_kernel_file();
>  
> +	/* free name for vmcoreinfo */
> +	free(info->name_vmcoreinfo);
> +	info->name_vmcoreinfo = NULL;
> +
>  	close_dump_memory();
>  
>  	close_dump_file();
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 





[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-09-12  2:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-11 15:23 [patch] [PATCH] Fix memory leaks Bernhard Walle
2008-09-12  2:03 ` Ken'ichi Ohmichi

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.