reiserfsck segfault when journal transactions count == 1

reiserfsck segfault when journal transactions count == 1

[Victor Leschuk]

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

Damn gmx.com, can't manage to make it use TEXT/PLAIN. Jeff, sorry for spamming.

Resending original message from gmail...

Hello,

We have met a situation when reiserfsck segfaulted on one of our
partitions. I have performed a small research and the cause appeared
to be wrong detection of transaction count.

Our FS had only one journal transaction, however trans_count which was
passed to progbar_update() as maximum transaction value was detected
as (last_transaction - first_transaction) which in our case was 0.
Thus progbar_update() resulted in segmentation fault:

(gdb) bt
#0  0xb7610b7c in vfprintf () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#1  0xb7611bb2 in ?? () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#2  0xb760cdc3 in vfprintf () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#3  0xb7616e4f in fprintf () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#4  0x08088aca in progbar_update (ctx=0xbfef0020, label=0x8096650
"Replaying journal", curr=1, max=0, dpynum=1) at progbar.c:80
#5  0x080843c4 in replay_journal (fs=0x9492980) at journal.c:868
#6  0x0804ae67 in reiserfsck_replay_journal (fs=0x9492980) at main.c:727
#7  0x0804b477 in prepare_fs_for_check (fs=0x9492980) at main.c:838
#8  0x0804c0c8 in check_fs (fs=0x9492980) at main.c:1100
#9  0x0804cfb0 in main (argc=3, argv=0xbfef0254) at main.c:1380

Here is part of debugreiserfs -j output

Journal header (block #8210 of ./partition.bug):
    j_last_flush_trans_id 0
    j_first_unflushed_offset 0
    j_mount_id 10
    Device [0x0]
    Magic [0x4f0a099e]
    Size 8193 blocks (including 1 for journal header) (first block 18)
    Max transaction length 1024 blocks
    Max batch size 900 blocks
    Max commit age 30
Mountid 10, transid 10, desc 18, length 2, commit 21
#0    19->16 20->8211    < ========================= this is the only record

I successfully reproduced it on versions 3.6.21 (which we were using)
and 3.6.23 (which I believe is the latest).

Attaching patch. Let me know your opinion. If I am wrong, please
comment, if I am correct, feel free to include patch into sources.

Thanks.

--
Victor Leschuk

[-- Attachment #2: trans_count.patch.tar --]
[-- Type: application/x-tar, Size: 10240 bytes --]

Re: reiserfsck segfault when journal transactions count == 1

[Jeff Mahoney]

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

On 8/23/13 12:57 PM, Victor Leschuk wrote:
> Damn gmx.com, can't manage to make it use TEXT/PLAIN. Jeff, sorry for spamming.
> 
> Resending original message from gmail...
> 
> Hello,
> 
> We have met a situation when reiserfsck segfaulted on one of our
> partitions. I have performed a small research and the cause appeared
> to be wrong detection of transaction count.
> 
> Our FS had only one journal transaction, however trans_count which was
> passed to progbar_update() as maximum transaction value was detected
> as (last_transaction - first_transaction) which in our case was 0.
> Thus progbar_update() resulted in segmentation fault:
> 
> (gdb) bt
> #0  0xb7610b7c in vfprintf () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
> #1  0xb7611bb2 in ?? () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
> #2  0xb760cdc3 in vfprintf () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
> #3  0xb7616e4f in fprintf () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
> #4  0x08088aca in progbar_update (ctx=0xbfef0020, label=0x8096650
> "Replaying journal", curr=1, max=0, dpynum=1) at progbar.c:80
> #5  0x080843c4 in replay_journal (fs=0x9492980) at journal.c:868
> #6  0x0804ae67 in reiserfsck_replay_journal (fs=0x9492980) at main.c:727
> #7  0x0804b477 in prepare_fs_for_check (fs=0x9492980) at main.c:838
> #8  0x0804c0c8 in check_fs (fs=0x9492980) at main.c:1100
> #9  0x0804cfb0 in main (argc=3, argv=0xbfef0254) at main.c:1380
> 
> Here is part of debugreiserfs -j output
> 
> Journal header (block #8210 of ./partition.bug):
>     j_last_flush_trans_id 0
>     j_first_unflushed_offset 0
>     j_mount_id 10
>     Device [0x0]
>     Magic [0x4f0a099e]
>     Size 8193 blocks (including 1 for journal header) (first block 18)
>     Max transaction length 1024 blocks
>     Max batch size 900 blocks
>     Max commit age 30
> Mountid 10, transid 10, desc 18, length 2, commit 21
> #0    19->16 20->8211    < ========================= this is the only record
> 
> I successfully reproduced it on versions 3.6.21 (which we were using)
> and 3.6.23 (which I believe is the latest).
> 
> Attaching patch. Let me know your opinion. If I am wrong, please
> comment, if I am correct, feel free to include patch into sources.

Thanks for the report and patch. I've applied it to my repo (adding your
Signed-off-by, per the line immediately quoted above) and it'll be part
of 3.6.24.

-Jeff

-- 
Jeff Mahoney
SUSE Labs


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]