fsck dumps core

[John-Mark Gurney]

Xin Li wrote this message on Mon, Feb 24, 2014 at 13:57 -0800:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 02/24/14 05:54, Dmitry Sivachenko wrote:
> > Hello!
> > 
> > FreeBSD 10.0-STABLE #0 r262016M
> > 
> > # fsck /dev/mfid0p1 ** /dev/mfid0p1 Segmentation fault #
> > 
> > truss shows: lseek(3,0x2b0000,SEEK_SET)                       =
> > 2818048 (0x2b0000) 
> > read(3,"\0\0\0\0lo\0\0\0\^N\0\0\0\0\0\0"...,32768) = 32768
> > (0x8000) lseek(3,0x2b8000,SEEK_SET)                       = 2850816
> > (0x2b8000) read(3,"\0\0\0\0lo\0\0\0\^N\0\0\0\0\0\0"...,12288) =
> > 12288 (0x3000) 
> > mmap(0x0,-1119879168,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0)
> > ERR#12 'Cannot allocate memory' SIGNAL 11 (SIGSEGV) process exit,
> > rval = 0
> > 
> > 
> > #0  flushentry () at /place/WRK/src/sbin/fsck_ffs/fsutil.c:258 258
> > if (cgbp->b_un.b_cg == NULL) (gdb) bt #0  flushentry () at
> > /place/WRK/src/sbin/fsck_ffs/fsutil.c:258 #1  0x000000000040e827 in
> > setup (dev=<value optimized out>) at fsck.h:392 #2
> > 0x0000000000408cd8 in main (argc=1, argv=0x7fffffffda30) at
> > /place/WRK/src/sbin/fsck_ffs/main.c:394
> > 
> > 
> > 
> > # tunefs -p /dev/mfid0p1 tunefs: POSIX.1e ACLs: (-a)
> > disabled tunefs: NFSv4 ACLs: (-N)
> > disabled tunefs: MAC multilabel: (-l)
> > disabled tunefs: soft updates: (-n)
> > enabled tunefs: soft update journaling: (-j)
> > disabled tunefs: gjournal: (-J)
> > disabled tunefs: trim: (-t)
> > disabled tunefs: maximum blocks per file in a cylinder group: (-e)
> > 4096 tunefs: average file size: (-f)
> > 16384 tunefs: average number of files in a directory: (-s)
> > 64 tunefs: minimum percentage of free space: (-m)             8% 
> > tunefs: space to hold for metadata blocks: (-k)            9136 
> > tunefs: optimization preference: (-o)                      time 
> > tunefs: volume label: (-L)
> > 
> > 
> > Is there any way to complete fsck to get this drive working?
> 
> Can you try this patch and see if it helps?
> 
> Note that fsck'ing such a big UFS volume is painful regardless, any
> reason not to use e.g. ZFS?
> 
> Cheers,
> - -- 
> Xin LI <delphij at delphij.net>    https://www.delphij.net/
> FreeBSD - The Power to Serve!           Live free or die
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (FreeBSD)
> 
> iQIcBAEBCgAGBQJTC8BhAAoJEJW2GBstM+nsChsP/1qEHtZUg0CplNiSUlqo7Jkr
> jtd/Vos6l/YdjjwmjPvWdPvdPxFSmJgqCFlE5a9tml8UvRokDReqblGhFqmtp3Cg
> Qiq6qg+odAvpOCo8NOww8Q7aAl0gwpFceBZGTlaAIxyx8MkoUCeZ1ZnWRR10a1Bk
> 89YPQBgFYoFOMAgHzNi9d1L15jvk6HaUNCTYE6KDDjvM7KUBSEal3q5cYXv31YRi
> 1HHVzi2yUEX6FPg2uOCq0M2awNrBlnMjWAL2RQyN1jJG+eD/A3m/YZXgK8x/mjQz
> w9Pgn8rgu8JfDZWvOp37KBOqzRXc+1jRFEFOWZT95hiDHVIo94s8t9LR+nfqA+Fz
> lCZeS1QzY9r3xgVLM/1dDa0jrDNqRch9d3xmIvGuoe1dLBy3tgRwp8zVc9i6Vp95
> VX1/91GkdYTorh/kMtlzh5EJ9WSrSeH70Ts8RhxM8V5ciAr106hscs7EyxZW74ZU
> AwYSRZd49rq7ElJxfaAlDsfdas8bwZGNsBOT+rUkJ87BJRgxIuRb0QPhpYP9cBRA
> Dcexf2cogKPDlzrV4mEHj0mpecqg6vLxNs5jkHDznvcR6C/rAYQSo291jeluiPaZ
> fegTABwlSh87vguT/yP+2xr51wRyGUSH/6QMU2/lhffPaC8HRy7OFghejVuAWC89
> iYaOHJIhtCZIwIg8V4/S
> =Ylh1
> -----END PGP SIGNATURE-----

> Index: sbin/fsck_ffs/fsck.h
> ===================================================================
> --- sbin/fsck_ffs/fsck.h	(revision 262459)
> +++ sbin/fsck_ffs/fsck.h	(working copy)
> @@ -369,7 +369,7 @@ int flushentry(void);
>   * to get space.
>   */
>  static inline void*
> -Malloc(int size)
> +Malloc(size_t size)
>  {
>  	void *retval;
>  
> @@ -384,7 +384,7 @@ static inline void*
>   * to get space.
>   */
>  static inline void*
> -Calloc(int cnt, int size)
> +Calloc(size_t cnt, size_t size)
>  {
>  	void *retval;
>  

This should fix the issue...  I informed mckusick of the issue, but I
forget who was going to follow through to commit it...

I would say go ahead and commit it, unless mckusick disagrees...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."