Bug 53591 - repquota segfaults
repquota segfaults
Status: CLOSED CANTFIX
Product: Red Hat Linux
Classification: Retired
Component: quota (Show other bugs)
7.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Brock Organ
:
Depends On:
Blocks: 91022
  Show dependency treegraph
 
Reported: 2001-09-12 09:43 EDT by Preston Brown
Modified: 2007-04-18 12:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-18 12:08:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to skip invalid block pointers (1.40 KB, patch)
2002-09-12 08:43 EDT, John Dalbec
no flags Details | Diff

  None (edit)
Description Preston Brown 2001-09-12 09:43:19 EDT
* repquota -ua segfaults after the output of the data
* repquota doesn't seem to print out correct values, because e.g. deleting
files does not change the numbers showed with repquota
Comment 1 Need Real Name 2001-10-09 13:48:48 EDT
ACtually quotas just don't seem to update at all unless you do quotacheck.
Comment 2 John Dalbec 2002-06-25 15:04:28 EDT
Here's the end of an strace:
lseek(3, 31550464, SEEK_SET)            = 31550464
read(3, "", 1024)                       = 0
lseek(3, 31562752, SEEK_SET)            = 31562752
read(3, "", 1024)                       = 0
lseek(3, 31575040, SEEK_SET)            = 31575040
read(3, "", 1024)                       = 0
lseek(3, 31538176, SEEK_SET)            = 31538176
read(3, "", 1024)                       = 0
lseek(3, 31522816, SEEK_SET)            = 31522816
read(3, "", 1024)                       = 0
lseek(3, 31559680, SEEK_SET)            = 31559680
read(3, "", 1024)                       = 0
lseek(3, 1567744, SEEK_SET)             = 1567744
read(3, "\0\0\0\0\0\0\0\0\25\0\0\0\0\0\0\0=y\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
lseek(3, 31781888, SEEK_SET)            = 31781888
read(3, "", 1024)                       = 0
lseek(3, 31818752, SEEK_SET)            = 31818752
read(3, "", 1024)                       = 0
lseek(3, 31815680, SEEK_SET)            = 31815680
read(3, "", 1024)                       = 0
lseek(3, 31823872, SEEK_SET)            = 31823872
read(3, "", 1024)                       = 0
lseek(3, 31820800, SEEK_SET)            = 31820800
read(3, "", 1024)                       = 0
lseek(3, 31828992, SEEK_SET)            = 31828992
read(3, "", 1024)                       = 0
lseek(3, 31819776, SEEK_SET)            = 31819776
read(3, "", 1024)                       = 0
lseek(3, 31826944, SEEK_SET)            = 31826944
read(3, "", 1024)                       = 0
lseek(3, 31827968, SEEK_SET)            = 31827968
read(3, "", 1024)                       = 0
lseek(3, 31817728, SEEK_SET)            = 31817728
read(3, "", 1024)                       = 0
lseek(3, 31814656, SEEK_SET)            = 31814656
read(3, "", 1024)                       = 0
lseek(3, 31822848, SEEK_SET)            = 31822848
read(3, "", 1024)                       = 0
lseek(3, 31825920, SEEK_SET)            = 31825920
read(3, "", 1024)                       = 0
lseek(3, 31821824, SEEK_SET)            = 31821824
read(3, "", 1024)                       = 0
lseek(3, 31824896, SEEK_SET)            = 31824896
read(3, "", 1024)                       = 0
lseek(3, 31816704, SEEK_SET)            = 31816704
read(3, "", 1024)                       = 0
lseek(3, 31835136, SEEK_SET)            = 31835136
read(3, "", 1024)                       = 0
lseek(3, 31838208, SEEK_SET)            = 31838208
read(3, "", 1024)                       = 0
lseek(3, 31831040, SEEK_SET)            = 31831040
read(3, "", 1024)                       = 0
lseek(3, 9216, SEEK_SET)                = 9216
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
socket(PF_UNIX, SOCK_STREAM, 0)         = 4
connect(4, {sin_family=AF_UNIX, path="                                                                                       /var/run/.nscd_socket"}, 110) = 0
write(4, "\2\0\0\0\1\0\0\0\2\0\0\0", 12) = 12
write(4, "8\0", 2)     = 2
read(4, "\350\22\30@\1\0\0\0\5\0\0\0\2\0\0\0\10\0\0\0\f\0\0\0\5"..., 36) = 36
read(4, "mail\0x\0mail\0/var/spool/mail\0\0", 29) = 29
close(4)                                = 0
time([1025026691])                      = 1025026691
time([1025026691])                      = 1025026691
--- SIGSEGV (Segmentation fault) ---

I wonder why there are so many seeks past the end-of-file?
Comment 3 John Dalbec 2002-06-26 17:03:08 EDT
Here's a backtrace from an unstripped repquota:
(gdb) bt
#0  0x0804dd5c in report_tree (dquot=0x8054c38, blk=1531, depth=3, 
    bitmap=0x8054c90 "`\a 
P{\177_{\177Gw\237o}]w\177}ow?{o\177~wm\177{o?v{o{/\217}w{{w?_{o\177o}\177w__}\177o}?w
}\003Aj", '' <repeats 15 times>, "s{~_soo75~}~~~{w\177w~w\203", process_dquot=0x80496b0 <print>) at 
quotaio_v2.c:696
#1  0x0804dda6 in report_tree (dquot=0x8054c38, blk=3, depth=2, 
    bitmap=0x8054c90 "`\a 
P{\177_{\177Gw\237o}]w\177}ow?{o\177~wm\177{o?v{o{/\217}w{{w?_{o\177o}\177w__}\177o}?w
}\003Aj", '' <repeats 15 times>, "s{~_soo75~}~~~{w\177w~w\203", process_dquot=0x80496b0 <print>) at 
quotaio_v2.c:703
#2  0x0804dda6 in report_tree (dquot=0x8054c38, blk=2, depth=1, 
    bitmap=0x8054c90 "`\a 
P{\177_{\177Gw\237o}]w\177}ow?{o\177~wm\177{o?v{o{/\217}w{{w?_{o\177o}\177w__}\177o}?w
}\003Aj", '' <repeats 15 times>, "s{~_soo75~}~~~{w\177w~w\203", process_dquot=0x80496b0 <print>) at 
quotaio_v2.c:703
#3  0x0804dda6 in report_tree (dquot=0x8054c38, blk=1, depth=0, 
    bitmap=0x8054c90 "`\a 
P{\177_{\177Gw\237o}]w\177}ow?{o\177~wm\177{o?v{o{/\217}w{{w?_{o\177o}\177w__}\177o}?w
}\003Aj", '' <repeats 15 times>, "s{~_soo75~}~~~{w\177w~w\203", process_dquot=0x80496b0 <print>) at 
quotaio_v2.c:703
#4  0x0804deb9 in v2_scan_dquots (h=0x8056088, process_dquot=0x80496b0 <print>)
    at quotaio_v2.c:733
#5  0x08049960 in report_it (h=0x8056088, type=0) at repquota.c:151
#6  0x08049a15 in report (type=0) at repquota.c:170
---Type <return> to continue, or q <return> to quit---
#7  0x08049a7d in main (argc=2, argv=0xbffff914) at repquota.c:183
#8  0x4003d647 in __libc_start_main (main=0x8049a30 <main>, argc=2, 
    ubp_av=0xbffff914, init=0x8048ef4 <_init>, fini=0x8050460 <_fini>, 
    rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffff90c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) print i
$15 = 226
(gdb) print blk
$16 = 193368

Apparently blk is too large for the bitmap (which maxes out at 17264 bytes).  Is info->dqi_blocks the highest used pointer block or is it a count of the 
number of pointer blocks?  Is the tree allowed to be fragmented?
Comment 4 Phil Copeland 2002-08-12 14:28:00 EDT
Fixed with quota 0.3-8
(created a 64Mb file in test's home dir then deleted it) to get a before and
after snapshot)


[root@dhcp59-202 root]# repquota -ua > l

[root@dhcp59-202]$ su - test
[test@dhcp59-202]$ rm test

[root@dhcp59-202 root]# repquota -ua > ll

[root@dhcp59-202 root]# diff l ll 
38c38
< test      --   65668 5242880 5242880             17     0     0       
---
> test      --      64 5242880 5242880             16     0     0       


Please try ftp://ftp.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS
quota-3.06-4.src.rpm

Phil
=--=
Comment 5 Phil Copeland 2002-08-12 14:28:50 EDT
ack with quota 3.06-4 I meant to say, not 0.3-8..
appologies

Phil
=--=
Comment 6 John Dalbec 2002-09-11 16:05:58 EDT
This doesn't work for me.  Granted my quota files have some corruption, but
couldn't repquota handle this more gracefully?
Comment 7 John Dalbec 2002-09-12 08:43:45 EDT
Created attachment 75924 [details]
Patch to skip invalid block pointers
Comment 8 John Dalbec 2002-09-12 08:50:42 EDT
I've attached a patch that fixes the segfaults on my machine.  It silently
ignores block pointers that are too large.  You might want to change this to
print a warning instead.  Also, does the info->dqi_blocks limit apply to tree
nodes as well?  If so, it may be more efficient to check those pointers also.
Comment 9 John Dalbec 2002-10-04 07:27:27 EDT
Is my patch incorporated into quotacheck as well?  It segfaulted on me this morning.
Comment 10 Petri T. Koistinen 2003-05-17 18:11:36 EDT
Similar problems in #91022. See also releated quota bug #90939.
Comment 11 Bill Nottingham 2006-08-07 14:46:28 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
Please check if this issue is still present in a current Fedora Core
release. If so, please change the product and version to match, and
check the box indicating that the requested information has been
provided. Note that any bug still open against Red Hat Linux on will be
closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.
Comment 12 Bill Nottingham 2006-10-18 12:08:29 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.

Note You need to log in before you can comment on or make changes to this bug.