linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: linux-btrfs <linux-btrfs@vger.kernel.org>,
	Shilong Wang <wangshilong1991@gmail.com>,
	Chris Murphy <lists@colorremedies.com>
Subject: "btrfs rescue super-recover" memory corruption
Date: Wed, 17 Sep 2014 12:00:14 -0500	[thread overview]
Message-ID: <5419BE1E.2020607@redhat.com> (raw)

This:

# truncate --size=8g
# dd if=/dev/zero of=file conv=notrunc  bs=4 seek=16384 count=1
# valgrind ./btrfs rescue super-recover file -v

yields:

==4604== Memcheck, a memory error detector
==4604== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4604== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==4604== Command: ./btrfs rescue super-recover file -v
==4604== 
All Devices:
	Device: id = 1, name = file

Before Recovering:
	[All good supers]:
		device name = file
		superblock bytenr = 67108864

	[All bad supers]:
		device name = file
		superblock bytenr = 65536


Make sure this is a btrfs disk otherwise the tool will destroy other fs, Are you sure? [y/N]: y
Recovered bad superblocks successful
==4604== Invalid read of size 8
==4604==    at 0x426B55: btrfs_recover_superblocks (list.h:204)
==4604==    by 0x421C79: cmd_super_recover (cmds-rescue.c:148)
==4604==    by 0x40420A: handle_command_group (btrfs.c:145)
==4604==    by 0x421B54: cmd_rescue (cmds-rescue.c:162)
==4604==    by 0x404199: main (btrfs.c:247)
==4604==  Address 0x4c250b0 is 48 bytes inside a block of size 96 free'd
==4604==    at 0x4A063F0: free (vg_replace_malloc.c:446)
==4604==    by 0x43C77E: btrfs_close_devices (volumes.c:196)
==4604==    by 0x42F5D1: close_ctree (disk-io.c:1404)
==4604==    by 0x426A85: btrfs_recover_superblocks (super-recover.c:340)
==4604==    by 0x421C79: cmd_super_recover (cmds-rescue.c:148)
==4604==    by 0x40420A: handle_command_group (btrfs.c:145)
==4604==    by 0x421B54: cmd_rescue (cmds-rescue.c:162)
==4604==    by 0x404199: main (btrfs.c:247)
==4604== 
==4604== Invalid free() / delete / delete[] / realloc()
==4604==    at 0x4A063F0: free (vg_replace_malloc.c:446)
==4604==    by 0x426B9E: btrfs_recover_superblocks (super-recover.c:85)
==4604==    by 0x421C79: cmd_super_recover (cmds-rescue.c:148)
==4604==    by 0x40420A: handle_command_group (btrfs.c:145)
==4604==    by 0x421B54: cmd_rescue (cmds-rescue.c:162)
==4604==    by 0x404199: main (btrfs.c:247)
==4604==  Address 0x4c25080 is 0 bytes inside a block of size 96 free'd
==4604==    at 0x4A063F0: free (vg_replace_malloc.c:446)
==4604==    by 0x43C77E: btrfs_close_devices (volumes.c:196)
==4604==    by 0x42F5D1: close_ctree (disk-io.c:1404)
==4604==    by 0x426A85: btrfs_recover_superblocks (super-recover.c:340)
==4604==    by 0x421C79: cmd_super_recover (cmds-rescue.c:148)
==4604==    by 0x40420A: handle_command_group (btrfs.c:145)
==4604==    by 0x421B54: cmd_rescue (cmds-rescue.c:162)
==4604==    by 0x404199: main (btrfs.c:247)
==4604== 
==4604== 
==4604== HEAP SUMMARY:
==4604==     in use at exit: 0 bytes in 0 blocks
==4604==   total heap usage: 72 allocs, 73 frees, 140,384 bytes allocated
==4604== 
==4604== All heap blocks were freed -- no leaks are possible
==4604== 
==4604== For counts of detected and suppressed errors, rerun with: -v
==4604== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6)

i.e. I think we are double freeing memory:

        close_ctree(root); // <-- here
no_recover:
        recover_err_str(ret);
        free_recover_superblock(&recover); // <-- and here

I can't really work out what all this is all doing, but maybe the fix is obvious
to Wang Shilong (who wrote the original code)?

Thanks,
-Eric

             reply	other threads:[~2014-09-17 17:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-17 17:00 Eric Sandeen [this message]
2014-09-17 17:01 ` "btrfs rescue super-recover" memory corruption Eric Sandeen
2014-09-18  7:28 ` Wang Shilong
2014-09-18  9:01 ` [PATCH] Btrfs-progs: super-recover: fix double free fs_devices memory Wang Shilong
2014-09-18  9:23   ` Gui Hecheng
2014-09-22 20:39   ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5419BE1E.2020607@redhat.com \
    --to=sandeen@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=wangshilong1991@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).