From owner-freebsd-questions@FreeBSD.ORG Sun Nov 1 13:17:36 2009 Return-Path: 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 339B71065679 for ; Sun, 1 Nov 2009 13:17:36 +0000 (UTC) (envelope-from usleepless@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id AD5298FC0C for ; Sun, 1 Nov 2009 13:17:35 +0000 (UTC) Received: by bwz5 with SMTP id 5so5381698bwz.3 for ; Sun, 01 Nov 2009 05:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=JEu+Oc6HtihWT9JKjy8xtfDr0ecDSvXZR+ysib+XqKg=; b=R4jzYBslpgFIl3h136LDNdUc6IP1kuf0aZSgxDQHgJYCgWASvIWx1ZZatcWyJUeohY P4VfIMjht0LiuSYLDh04Hja53KlGv9TPgj72gooJ60yWXyqi5Ffb6DHyfoE1skMecmTQ z8N7VPGx3dnL9pVmGoOtEujBU1sWhw2fR3X3w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NYe/Z9mNY6SYVTbtk00K35vQU4p68pLck+UX5Gem+F405SMqLELibHhHVpleOv/9bO DtbfvgpwNiMRKdtvydE4UhpRfphlkIARDLZbL7/13nho+JmWs0va16eylriroAAKLyTY l0BqJreNhwJRGB9ycc6EPoi+xkYVhRxtS+OGA= MIME-Version: 1.0 Received: by 10.204.156.213 with SMTP id y21mr3033997bkw.109.1257081454481; Sun, 01 Nov 2009 05:17:34 -0800 (PST) In-Reply-To: <4AEC5E02.8040705@FreeBSD.org> References: <7B9397B189EB6E46A5EE7B4C8A4BB7CB327D117F@MBX03.exg5.exghost.com> <4AEC5E02.8040705@FreeBSD.org> Date: Sun, 1 Nov 2009 14:17:34 +0100 Message-ID: From: usleepless@gmail.com To: Kris Kennaway Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Peter Steele , "freebsd-questions@freebsd.org" Subject: Re: system() call causes core dump X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 13:17:36 -0000 On Sat, Oct 31, 2009 at 4:55 PM, Kris Kennaway wrote: > Peter Steele wrote: > >> I have an application running a number of threads. I've had recent >> instances where the code below is causing a core dump to occur: >> >> char fstatCmd[200]; >> char *fstatOut = "/tmp/fstat.out"; >> sprintf(fstatCmd, "fstat | grep -v USER | wc -l >%s", fstatOut); >> rc = system(fstatCmd); >> >> The call is simply intended to get a count of the current open handles. >> The system call though causes a core: >> >> #0 0x0000000801058307 in _spinunlock () from /lib/libthr.so.3 >> #1 0x00000008011d0afb in _malloc_postfork () from /lib/libc.so.7 >> #2 0x000000080105c5fb in fork () from /lib/libthr.so.3 >> #3 0x0000000801191aae in system () from /lib/libc.so.7 >> #4 0x00000008010553aa in system () from /lib/libthr.so.3 >> #5 0x000000000040b6f9 in mythread at myapp.c:461 >> #6 0x0000000801056a88 in pthread_getprio () from /lib/libthr.so.3 >> >> There appears to be some kind of thread-safe issue going on. I have a >> number of threads that are monitoring various items, waking up a differing >> intervals to do their respective tasks. Do I need to put in a global mutex >> so that the threads never attempt to make simultaneous system() calls? >> Curiously, only this particular system() call appears to be causing a core. >> > > In UNIX it is not safe to perform arbitrary actions after forking a > multi-threaded process. You're basically expected to call exec soon after > the fork, although you can do certain other work if you are very careful. > > The reason for this is that after the fork, only one thread will be running > in the child, and if that thread tries to acquire a lock or other > formerly-shared resource it may deadlock or crash, because the child process > is no longer accessing the same memory location as the threads in the parent > process (it gets a separate copy of the address space at the time of fork, > which may not be in a consistent state from the point of view of the thread > library). > Are you saying system/popen can't be used in threads? Is there a workaround? ( forking manual and executing exec? ) Would calling 'system("exec fstat | ... > result.txt")' make any difference? just curious, kind regards, usleep