From: Marc Dietrich <marvin24@gmx.de>
To: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Cc: Zooko Wilcox-OHearn <zooko@leastauthority.com>,
linux-btrfs@vger.kernel.org
Subject: Re: fs corruption report
Date: Mon, 01 Sep 2014 11:09:41 +0200 [thread overview]
Message-ID: <5322846.kPR8ohTNYd@ax5200p> (raw)
In-Reply-To: <1484373.Oezxgh4u8P@ax5200p>
Am Montag 01 September 2014, 10:47:26 schrieb Marc Dietrich:
> Guy,
>
> Am Donnerstag 28 August 2014, 10:28:02 schrieb Gui Hecheng:
> > And for the last one and the crucial one...
> > ==5569== Invalid read of size 4
> > ==5569== at 0x41E394: decompress (cmds-restore.c:93)
> > ==5569== by 0x41F291: search_dir (cmds-restore.c:378)
> > along with
> > ==5569== Invalid read of size 1
> > ==5569== at 0x548DDB6: lzo1x_decompress_safe
> > ==5569== by 0x41E3BD: decompress (cmds-restore.c:122)
> > ==5569== by 0x41F291: search_dir (cmds-restore.c:378)
> >
> > Sorry, I'm not able to reproduce it yet, it may be just what you've
> > guessed that corruption happens. But I am sure that there are bugs
> > around the decompress routine, because I've got "failed to inflate"s too
> > with a non-corrupted btrfs. I'm going to track it down.
>
> this one still exists. It took me a while to reproduce this (actually, find
> the file which causes it). So we have:
>
> ==27292== Invalid read of size 8
> ==27292== at 0x57A10D2: lzo1x_decompress_safe (in
> /usr/lib64/liblzo2.so.2.0.0)
> ==27292== by 0x41E9ED: decompress (cmds-restore.c:129)
> ==27292== by 0x41F8A7: search_dir (cmds-restore.c:386)
> ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916)
> ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916)
> ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916)
> ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916)
> ==27292== by 0x420C6F: cmd_restore (cmds-restore.c:1319)
> ==27292== by 0x4042FC: main (btrfs.c:247)
> ==27292== Address 0x6280afc is 24,572 bytes inside a block of size 24,576
> alloc'd
> ==27292== at 0x4C277AB: malloc (in
> /usr/lib64/valgrind/vgpreload_memcheck- amd64-linux.so)
> ==27292== by 0x41F577: search_dir (cmds-restore.c:317)
> ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916)
> ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916)
> ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916)
> ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916)
> ==27292== by 0x420C6F: cmd_restore (cmds-restore.c:1319)
> ==27292== by 0x4042FC: main (btrfs.c:247)
> ==27292==
> ==27292== (action on error) vgdb me ...
>
> and the attached debug backtrace is (I attached the full bt):
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00000000057a10d2 in lzo1x_decompress_safe () from /usr/lib64/liblzo2.so.2
> (gdb) bt
> #0 0x00000000057a10d2 in lzo1x_decompress_safe () from
> /usr/lib64/liblzo2.so.2
after installing debuginfo for liblzo I get
#0 lzo1x_decompress_safe (in=0x1 <error: Cannot access memory at address
0x1>, in@entry=0x6280a6d "\017ource/core/dom/webl\001",
in_len=103290581, in_len@entry=3176, out=out@entry=0x63229a0
"ource/core/dom/webcore_dom.StaticNodeList.o",
out_len=out_len@entry=0x7feff9de0, wrkmem=0x6322a55, wrkmem@entry=0x0) at
src/lzo1x_d.ch:184
ip = 0x1 <error: Cannot access memory at address 0x1>
ip_end = 0x62816d5 ""
op_end = 0x6323ae3 ""
I'll keep the debug session open just in case.
Marc
> #1 0x000000000041e9ee in decompress_lzo (decompress_len=0x7feff9f60,
> compress_len=417,
> outbuf=0x63229a0 "ource/core/dom/webcore_dom.StaticNodeList.o",
> inbuf=0x6280a6d "\017ource/core/dom/webl\001") at cmds-restore.c:129
> #2 decompress (inbuf=inbuf@entry=0x627ab00 "zU\001",
> outbuf=outbuf@entry=0x631a9a0 "<X", compress_len=compress_len@entry=24576,
> decompress_len=decompress_len@entry=0x7feff9f60,
> compress=compress@entry=2) at cmds-restore.c:155
> #3 0x000000000041f8a8 in copy_one_extent (pos=4063232, fi=<optimized out>,
> leaf=0x5fb58d0, fd=4, root=0x61405c0) at cmds-restore.c:386
> #4 copy_file (file=0x66a700 <path_name>
> "/work/chromium/src/out/Release/.ninja_deps", key=0x7feffb080, fd=4,
> root=0x61405c0)
> at cmds-restore.c:659
> #5 search_dir (root=root@entry=0x61405c0, key=key@entry=0x7feffc2d0,
> output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work",
> in_dir=in_dir@entry=0x6602d70 "/chromium/src/out/Release",
> mreg=mreg@entry=0x7fefffd60) at cmds-restore.c:840
> #6 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0,
> key=key@entry=0x7feffd520,
> output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work",
> in_dir=in_dir@entry=0x6df4d90 "/chromium/src/out",
> mreg=mreg@entry=0x7fefffd60) at cmds-restore.c:916
> #7 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0,
> key=key@entry=0x7feffe770,
> output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work",
> in_dir=in_dir@entry=0x65d7080 "/chromium/src", mreg=mreg@entry=0x7fefffd60)
> at cmds-restore.c:916
> #8 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0,
> key=key@entry=0x7fefff9c0,
> output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work",
> in_dir=in_dir@entry=0x6f35ac0 "/chromium", mreg=mreg@entry=0x7fefffd60)
> at cmds-restore.c:916
> #9 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0,
> key=key@entry=0x7fefffe30,
> output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work",
> in_dir=in_dir@entry=0x45ab43 "", mreg=mreg@entry=0x7fefffd60)
> at cmds-restore.c:916
> #10 0x0000000000420c70 in cmd_restore (argc=<optimized out>, argv=<optimized
> out>) at cmds-restore.c:1319
> #11 0x00000000004042fd in main (argc=8, argv=0x7feffffa0) at btrfs.c:247
next prev parent reply other threads:[~2014-09-01 9:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-25 5:08 fs corruption report Zooko Wilcox-OHearn
2014-08-28 2:28 ` Gui Hecheng
2014-09-01 8:47 ` Marc Dietrich
2014-09-01 9:09 ` Marc Dietrich [this message]
2014-09-01 15:25 ` Zooko Wilcox-OHearn
2014-09-04 3:00 ` Gui Hecheng
2014-09-04 9:50 ` Marc Dietrich
2014-09-12 12:35 ` Marc Dietrich
2014-09-18 3:39 ` Gui Hecheng
2014-09-18 8:16 ` Marc Dietrich
2014-09-18 12:47 ` Zooko Wilcox-OHearn
2014-09-19 1:30 ` Gui Hecheng
2014-09-22 8:19 ` Marc Dietrich
2014-09-22 8:33 ` Gui Hecheng
2014-09-22 8:49 ` Marc Dietrich
2014-09-22 8:55 ` Gui Hecheng
2014-09-22 15:05 ` Zooko Wilcox-OHearn
2014-08-28 2:46 ` Gui Hecheng
2014-08-28 3:23 ` Chris Murphy
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=5322846.kPR8ohTNYd@ax5200p \
--to=marvin24@gmx.de \
--cc=guihc.fnst@cn.fujitsu.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=zooko@leastauthority.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).