From owner-freebsd-ports@FreeBSD.ORG  Wed Sep 17 04:22:23 2008
Return-Path: <owner-freebsd-ports@FreeBSD.ORG>
Delivered-To: freebsd-ports@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 4103A1065672
	for <freebsd-ports@FreeBSD.org>; Wed, 17 Sep 2008 04:22:23 +0000 (UTC)
	(envelope-from stephen@math.missouri.edu)
Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu
	[128.206.184.213])
	by mx1.freebsd.org (Postfix) with ESMTP id 107AD8FC23
	for <freebsd-ports@FreeBSD.org>; Wed, 17 Sep 2008 04:22:17 +0000 (UTC)
	(envelope-from stephen@math.missouri.edu)
Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu
	[128.206.184.213])
	by cauchy.math.missouri.edu (8.14.2/8.14.2) with ESMTP id
	m8H4LZvs068467
	for <freebsd-ports@FreeBSD.org>; Tue, 16 Sep 2008 23:21:36 -0500 (CDT)
	(envelope-from stephen@math.missouri.edu)
Message-ID: <48D085F7.8080004@math.missouri.edu>
Date: Tue, 16 Sep 2008 23:22:15 -0500
From: Stephen Montgomery-Smith <stephen@math.missouri.edu>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US;
	rv:1.8.1.16) Gecko/20080909 SeaMonkey/1.1.11
MIME-Version: 1.0
To: freebsd-ports <freebsd-ports@FreeBSD.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 
Subject: signal handling issues
X-BeenThere: freebsd-ports@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Porting software to FreeBSD <freebsd-ports.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ports>,
	<mailto:freebsd-ports-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ports>
List-Post: <mailto:freebsd-ports@freebsd.org>
List-Help: <mailto:freebsd-ports-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ports>,
	<mailto:freebsd-ports-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Sep 2008 04:22:23 -0000

Apparently the program octave, as installed from ports, can coredump 
with "malloc(): error: recursive call."  I did a google check, and it 
seems that it results when a signal handler calls malloc when the signal 
was caught inside a malloc.  And looking inside 
/usr/ports/math/octave/work/octave-3.0.2/src/sighandlers.cc, I see that 
it does seem to use "new" and printing functions which I guess are not 
listed as allowed in "man sigaction."

My question is this.  Do you think it would be a good idea to link 
octave against /devel/ptmalloc?  I am thinking of graphics/xaralx as a 
model for how to do this.

Or does anyone else have some other idea on how to fix this?

Thanks, Stephen