Re: kernel panic in free() called from semop()

On Fri, 12 Nov 2004 15:11:57 -0800 (PST), Don Lewis
<truckman_at_freebsd.org> wrote:

> I cvsup'ed around 18:12 UTC today and got the following kernel panic
> with the new kernel right after moused started.
> 
> Starting default moused:.
> panic: free: address 0xe902ecb0(0xe902e000) has not been allocated.
> 
> cpuid = 0
> KDB: enter: panic
> [thread 100082]
> Stopped at      kdb_enter+0x2c: leave   
> db> tr
> kdb_enter(c082a57e,100,c26c8300,e902ecb0,c26c8300) at kdb_enter+0x2c
> panic(c0828c9f,e902ecb0,e902e000,e902ecb6,c26c8300) at panic+0x17f
> free(e902ecb0,c088f900,c082dd62,685,e902ecb6) at free+0xd4
> semop(c26c8300,e902ed18,5,4,283) at semop+0x150
> syscall(2f,2f,2f,805c010,bfbfed56) at syscall+0x128
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (169, FreeBSD ELF32, semsys), eip = 0x480dd5f8, esp =
> 0xbfbfeb04, ebp = 0xbfbfeb40 ---
> 
> 
> I suspect that the culprit is the sysv_sema.c:1.71.
> 
> This particular part of the change looks like a mistake:
> 
> _at__at_ -900,7 +901,7 _at__at_ semop(td, uap)
>  	semid = IPCID_TO_IX(semid);	/* Convert back to zero origin */
>  
>  	if (semid < 0 || semid >= seminfo.semmni)
> -		return (EINVAL);
> +		error = EINVAL;
>  
>  	/* Allocate memory for sem_ops */
>  	if (nsops <= SMALL_SOPS)
> 
> Falling through instead of returning looks dangerous because a little
> futher down there is the following code:
> 
> 	semakptr = &sema[semid];
>         sema_mtxp = &sema_mtx[semid];
> 
> Oh, this looks bad, too:
> 
> _at__at_ -1152,6 +1153,7 _at__at_ done2:
>  	mtx_unlock(sema_mtxp);
>  	if (sops != small_sops)
>  		free(sops, M_SEM);
> +	free(sops, M_SEM);
>  	return (error);
>  }
> 
> sops can either point to small_sops, which is located on the stack, or
> it call by allocated dynamically with malloc().  Depending on where
> sops points, it will either get freed twice, or it we will pass a
> stack address to free().  It looks like the latter is happening in
> this case.

I was seeing the same thing, until I disabled the execution of the pgsql
script in /usr/local/etc/rc.d.  Then the system booted fine.

I presume postgresql needs to be recompiled.

-- 
Conrad J. Sabatier <conrads_at_cox.net> -- "In Unix veritas"