From owner-freebsd-questions@FreeBSD.ORG  Sun Aug 12 09:12:39 2012
Return-Path: <owner-freebsd-questions@FreeBSD.ORG>
Delivered-To: freebsd-questions@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 0D3C4106566C
	for <freebsd-questions@freebsd.org>;
	Sun, 12 Aug 2012 09:12:39 +0000 (UTC)
	(envelope-from peo@intersonic.se)
Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com
	[212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id BE3378FC0A
	for <freebsd-questions@freebsd.org>;
	Sun, 12 Aug 2012 09:12:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at BSDLabs AB
Message-ID: <5027737C.6060601@intersonic.se>
Date: Sun, 12 Aug 2012 11:12:28 +0200
From: Per olof Ljungmark <peo@intersonic.se>
Organization: Intersonic AB
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
	rv:12.0) Gecko/20120525 Thunderbird/12.0.1
MIME-Version: 1.0
To: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Linux app shared memory problem
X-BeenThere: freebsd-questions@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: User questions <freebsd-questions.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-questions>, 
	<mailto:freebsd-questions-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-questions>
List-Post: <mailto:freebsd-questions@freebsd.org>
List-Help: <mailto:freebsd-questions-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-questions>, 
	<mailto:freebsd-questions-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Aug 2012 09:12:39 -0000

Trying to run a Linux app under 9-STABLE. I can start it once and stop 
it once but all subsequent efforts produces a core dump.

I believe the reason being that this app stores licensing information in 
shared memory and when it stops first time it fails to remove this info.

Is there a sysctl parameter that would be useful in a case like this?

Thanks,