From owner-freebsd-questions@FreeBSD.ORG Fri Nov 6 15:43:20 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 18734106566B for ; Fri, 6 Nov 2009 15:43:20 +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 8B50B8FC14 for ; Fri, 6 Nov 2009 15:43:19 +0000 (UTC) Received: by bwz5 with SMTP id 5so1319016bwz.3 for ; Fri, 06 Nov 2009 07:43:18 -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=HbKNOVYk5oUfbcAftw9xvrUF9dmsPckDO/7e1FPkqI0=; b=F3P0eYBMMACpLDEoxKiWHr2pKUtlvVqPEH92G3PpwbDaJFolZwnlgvpjOlxoO0F6yf RM5Q+VVNv7X4iWQ/tWrpDoSDJzPHYBL6+x10IeMsAnUwESAoK1SZh+M60jcFQRrAKgnG ppR53UmdPt1cOKcyk9oZYXuTFojH0DaDh3BGI= 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=Gcdnk03OL0XC0oo1Y17w6V3GYuU3gDbqBXfq2YjRPR4Lkxw5bLTV8NX6CnLdtFSPfm YPv5GImo1p7wB9BNpmJIpVYMXhxuJFI3YDmhXok9ENLqEJMJ1q5aDZyWHqJ+nyLfZuhK nvF/aIPoe0jPiq32ate37lTmz+VYYNFKgEuqk= MIME-Version: 1.0 Received: by 10.204.3.211 with SMTP id 19mr4866663bko.36.1257522198353; Fri, 06 Nov 2009 07:43:18 -0800 (PST) In-Reply-To: <7B9397B189EB6E46A5EE7B4C8A4BB7CB3394ED41@MBX03.exg5.exghost.com> References: <7B9397B189EB6E46A5EE7B4C8A4BB7CB327D117F@MBX03.exg5.exghost.com> <4AEC5E02.8040705@FreeBSD.org> <7B9397B189EB6E46A5EE7B4C8A4BB7CB327D11A9@MBX03.exg5.exghost.com> <200911040149.48701.mel.flynn+fbsd.questions@mailing.thruhere.net> <7B9397B189EB6E46A5EE7B4C8A4BB7CB3394ED41@MBX03.exg5.exghost.com> Date: Fri, 6 Nov 2009 16:43:18 +0100 Message-ID: From: usleepless@gmail.com To: Peter Steele Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "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: Fri, 06 Nov 2009 15:43:20 -0000 On Fri, Nov 6, 2009 at 4:19 PM, Peter Steele wrote: > > Either I'm very lucky, or popen is better suited for this, as I have this > running on various machines, 24/7: > ... > > I could try popen as a next step. What we tried first was to replace our > system calls with a function called vsys() which does exactly the same thing > but uses vfork() underneath instead of fork(). If this problem had been due > to resource conflicts due to the fork() performed by system(), we figured > this would solve the problem. Unfortunately, we are still getting the exact > same core with the identical stack trace. > > #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 > > I don't know much about the internal implementation of popen but I suspect > that at its core it still likely ends up doing a fork(). Still, it's worth a > try. Curiously, we have several other threads in our application running in > threads that periodically make system calls. For some reason only this call > to fstat causes a core to occur. Seems that something fishy is going on > here.... > > I am following this thread since i find it interesting ( playing around with popen & threads at times ). I am still trying to understand what Kris said. He says it is not safe to fork from a multithread proces. And he suggests using execve. You stacktrace btw is consistent with what Kris says: "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". -> that's probably the spinlock in malloc. I think you need to 1. (v)fork, 2. run execve on your fstat ( make it a sh script ) Something along the lines of this << your current thread code here >> // rc = system(fstatCmd); childpid = fork(); if (childpid >= 0) /* fork succeeded */ { if (childpid == 0) /* fork() returns 0 to the child process */ { execve("/usr/local/app/myscript", NULL, NULL); } } else { // didn't work, log something } << rest of your code here >> regards, usleep > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" >