Well it seems that more people are having this same error , i found this guy
in
Brazil who hasn't reported it but mentioned it in a forum
http://www.bsdforums.org/forums/showthread.php?p=265260
read at the end.
I think it would be a good idea to put the patch in the stable branch
Regards,
Marcos
----- Original Message -----
From: "Otto Moerbeek" <[EMAIL PROTECTED]>
To: "Marcos Laufer" <[EMAIL PROTECTED]>
Cc: <misc@openbsd.org>
Sent: Friday, July 20, 2007 4:02 PM
Subject: Re: fsck Segmentation fault on 4.1
On Fri, 20 Jul 2007, Marcos Laufer wrote:
> Will this be moved to -stable, or is it an uncommon thing ?
It's not very common, but the impact is pretty high. So once some more
test reports are coming in, we'll consider it.
-Otto
>
> ----- Original Message -----
> From: "Otto Moerbeek" <[EMAIL PROTECTED]>
> To: "Marcos Laufer" <[EMAIL PROTECTED]>
> Cc: <misc@openbsd.org>
> Sent: Thursday, July 19, 2007 3:09 PM
> Subject: Re: fsck Segmentation fault on 4.1
>
>
> On Fri, 13 Jul 2007, Otto Moerbeek wrote:
>
> > On Fri, 13 Jul 2007, Marcos Laufer wrote:
> >
> > > Otto ,
> > >
> > > This is the error i get:
> > > It starts booting , and it starts fsck , it fails with /dev/rwd0e and
rwd0h,
> > >
> > > (i could see once that when it finished it says:)
> > > fsck_ffs in free(): error: free_page: pointer to wrong page
> > > fsck: /dev/rwd0h: Abort trap
> > >
> > > I reboot it again many times and that did not show again
> > >
> > >
> > > i try to fsck manually like this as you say and i get:
> > >
> > > # ulimit -d unlimited
> > > # fsck -y /dev/rwd0e
> > >
> > > INCONSISTENT CGSIZE=16384
> > >
> > > FIX? yes
> > >
> > > * * Last mounted on /usr
> > > * * Phase 1- Check Blocks and Sizes
> > > * * Phase 2 - Check pathnames
> > > * * Phase 3 - Check Conectivity
> > > * * Phase 4 - Check Reference Counts
> > > * * Phase 5 - Check Cyl Groups
> > >
> > > CANNOT READ: BLK 64
> > >
> > > CONTINUE? yes
> > >
> > > fsck: /dev/rwd0e: Segmentation Fault
> >
> > This is not an out of memory situation.
> >
> > It looks like fsck_ffs has problems getting data from your disk,
> > probably because of hardware failure or bad cabling. Sometimes it
> > detects it cannot read the data (the CANNOT READ: BLK 64 case), but it
> > is possible it gets corrupted data in other cases.
> >
> > Sadly, this can cause fsck_ffs to do the wrong thing and access wrong
> > memory and corrupt it's internal data. During the last year I've fixed
> > some stuff in this area, but there still remains cases that can go
> > wrong.
>
> I misdiagnosed the problem. In the meantime I got another report with
> a dd of the partition which enabled me to diagnose the problem and
> make a fix for 4.1. Please test and report back. I'll be on vacation
> from Saturday, so it would be nice if you can answer before that.
>
> Anobody else seeing INCONSISTENT CGSIZE messages should try this as well.
>
> NOTE: this diff only applies to 4.1. Current does not have the
> problem, due to a corrected CGSIZE macro.
>
> -Otto
>
> Index: setup.c
> ===================================================================
> RCS file: /cvs/src/sbin/fsck_ffs/setup.c,v
> retrieving revision 1.29
> diff -u -p -r1.29 setup.c
> --- setup.c 16 Feb 2007 08:34:29 -0000 1.29
> +++ setup.c 19 Jul 2007 18:02:36 -0000
> @@ -336,6 +336,7 @@ setup(char *dev)
> sbdirty();
> dirty(&asblk);
> }
> +#if 0
> if (sblock.fs_cgsize != fragroundup(&sblock, CGSIZE(&sblock))) {
> pwarn("INCONSISTENT CGSIZE=%d\n", sblock.fs_cgsize);
> sblock.fs_cgsize = fragroundup(&sblock, CGSIZE(&sblock));
> @@ -346,6 +347,7 @@ setup(char *dev)
> dirty(&asblk);
> }
> }
> +#endif
> if (INOPB(&sblock) != sblock.fs_bsize / sizeof(struct ufs1_dinode)) {
> pwarn("INCONSISTENT INOPB=%d\n", INOPB(&sblock));
> sblock.fs_inopb = sblock.fs_bsize / sizeof(struct ufs1_dinode);
