gdb log of crashed "btrfs-image -s"

Commit Message

Goldwyn Rodrigues Jan. 18, 2017, 11:49 a.m. UTC

On 01/18/2017 01:13 AM, Christoph Groth wrote:
> Christoph Groth wrote:
>> Chris Murphy wrote:
>>> On Tue, Jan 17, 2017 at 1:25 PM, Christoph Groth
>>> <[e-mail]> wrote:
>>>> Any ideas on what could be done?  If you need help to debug the
>>>> problem with
>>>> btrfs-image, please tell me what I should do.  I can keep the broken
>>>> file
>>>> system around until an image can be created at some later time.
>>>
>>> Try 4.9, or even 4.8.5, tons of bugs have been fixed since 4.7.3
>>> although I don't know off hand if this particular bug is fixed. I did
>>> recently do a btrfs-image with btrfs-progs v4.9 with -s and did not
>>> get a segfault.
>>
>> I compiled btrfs-image.static from btrfs-tools 4.9 (from git) and
>> started it from Debian testing's initramfs.  The exact command that I
>> use is:
>>
>> /mnt/btrfs-image.static -c3 -s /dev/sda2 /mnt/mim-s.bim
>>
>> It runs for a couple of seconds (enough to write 20263936 bytes of
>> output) and then quits with
>>
>> *** Error in `/mnt/btrfs-image.static`: double free or corruption 
>> (!prev): 0x00000000009f0940 ***
>> ====== Backtrace: ======
>> [0x45fb97]
>> [0x465442]
>> [0x465c1e]
>> [0x402694]
>> [0x402dcb]
>> [0x4031fe]
>> [0x4050ff]
>> [0x405783]
>> [0x44cb73]
>> [0x44cdfe]
>> [0x400b2a]
>>
>> (I had to type the above off the other screen, but I double checked
>> that there are no errors.)
>>
>> The executable that I used can be downloaded from
>> http://groth.fr/btrfs-image.static
>> Its md5sum is 48abbc82ac6d3c0cb88cba1e5edb85fd.
>>
>> I hope that this can help someone to see what's going on.
> 
> I ran the same executable under gdb from a live system.  The log is
> attached.
> 

Thanks Christoph for the backtrace. I am unable to reproduce it, but
looking at your backtrace, I found a bug. Would you be able to give it a
try and check if it fixes the problem?

        case BTRFS_DIR_ITEM_KEY:

Comments

Christoph Groth Jan. 18, 2017, 8:11 p.m. UTC | #1

Goldwyn Rodrigues wrote:
> Thanks Christoph for the backtrace. I am unable to reproduce it, 
> but looking at your backtrace, I found a bug. Would you be able 
> to give it a try and check if it fixes the problem?

I applied your patch to v4.9, and compiled the static binaries. 
Unfortunately, it still segfaults. (Perhaps your fix is correct, 
and there's a second problem?)  I attach a new backtrace.  Do let 
me know if I can help in another way.

Goldwyn Rodrigues Jan. 23, 2017, 12:09 p.m. UTC | #2

On 01/18/2017 02:11 PM, Christoph Groth wrote:
> Goldwyn Rodrigues wrote:
>> Thanks Christoph for the backtrace. I am unable to reproduce it, but
>> looking at your backtrace, I found a bug. Would you be able to give it
>> a try and check if it fixes the problem?
> 
> I applied your patch to v4.9, and compiled the static binaries.
> Unfortunately, it still segfaults. (Perhaps your fix is correct, and
> there's a second problem?)  I attach a new backtrace.  Do let me know if
> I can help in another way.

I looked hard, and could not find the reason of a failure here. The
bakctrace of the new one is a little different than previous one, but I
am not sure why it crashes. Until I have a reproduction scneario, I may
not be able to fix this. How about a core? However, a core will have
values which you are trying to mask with sanitize.

Patch

diff --git a/image/main.c b/image/main.c
index 58dcecb..0158844 100644
--- a/image/main.c
+++ b/image/main.c
@@ -550,7 +550,7 @@  static void sanitize_name(struct metadump_struct
*md, u8 *dst,
                return;
        }

-       memcpy(eb->data, dst, eb->len);
+       memcpy(eb->data, src->data, src->len);

        switch (key->type) {