From owner-freebsd-java Mon Nov 11 22: 3:48 2002 Delivered-To: freebsd-java@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7AF237B401 for ; Mon, 11 Nov 2002 22:03:46 -0800 (PST) Received: from mgr5.xmission.com (mgr5.xmission.com [198.60.22.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7380843E42 for ; Mon, 11 Nov 2002 22:03:45 -0800 (PST) (envelope-from glewis@eyesbeyond.com) Received: from mail by mgr5.xmission.com with spam-scanned (Exim 3.35 #1) id 18BU90-0005AF-05 for freebsd-java@freebsd.org; Mon, 11 Nov 2002 23:03:26 -0700 Received: from [207.135.128.145] (helo=misty.eyesbeyond.com) by mgr5.xmission.com with esmtp (Exim 3.35 #1) id 18BU8B-0004fv-05; Mon, 11 Nov 2002 23:02:36 -0700 Received: (from glewis@localhost) by misty.eyesbeyond.com (8.11.6/8.11.6) id gAC62Uu95930; Tue, 12 Nov 2002 16:32:30 +1030 (CST) (envelope-from glewis@eyesbeyond.com) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Tue, 12 Nov 2002 16:32:30 +1030 From: Greg Lewis To: Fuyuhiko Maruyama Cc: Michael E Mercer , freebsd-java@FreeBSD.ORG Subject: Re: LimeWire crash gdb information Message-ID: <20021112163230.A95899@misty.eyesbeyond.com> References: <3DBAE791.27A93619@nc.rr.com> <20021027083816.B10962@misty.eyesbeyond.com> <3DBB49F8.941D3E09@nc.rr.com> <3DBB4CEA.E0DC7E1C@nc.rr.com> <3DBB5250.8DA88B27@nc.rr.com> <20021030172314.A31631@misty.eyesbeyond.com> <55of97wizj.wl@dittohead.is.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <55of97wizj.wl@dittohead.is.titech.ac.jp>; from fuyuhik8@is.titech.ac.jp on Sun, Nov 03, 2002 at 10:16:16AM +0900 X-Spam-Status: No, hits=-3.8 required=8.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MUTT,X_AUTH_WARNING version=2.43 X-Spam-Level: Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Nov 03, 2002 at 10:16:16AM +0900, Fuyuhiko Maruyama wrote: > I don't have enough time to check the JVM code right now. So I write > about codes around iomgr.c very briefly here. > > JVM manages monitor, Java's lock object, and fd_flag for each integer > number(FDs) and reuses such things during JVM process's life time. > To reuse monitors, JVM creates monitors only when a newer numbered FDs > are given. All other parts of JVM assume that all FDs have thier > corresponding monitors and manipulate them without any checking other > than java_g's assertion. Therefore, when JVM meet FDs without > corresponding monitor, Segmentation Fault will be caused. To prevent > this problem, __strong_reference are added to ensure all FDs related > syscalls be watched by iomgr.c. For the case of java_g's assertion > failure, it may show that there's some FDs related syscalls that > aren't watched by iomgr.c. Thank you for the excellent explanation, Fuyuhiko-san! > Michael's case, it seems that there's some syscalls that aren't > wrapped by iomgr.c and it causes inconsistent states of fd_flag. I'm wondering if that is the case in this instance? I've delved into this problem on the weekend and it appears as if something quite odd is going on. The fd_flag entries appear to be getting set and cleared correctly for quite some time until at some point a new fd is asked for and it has an existing fd_flag entry. However, looking back through the traces I have this entry was cleared correctly last time that fd number was used. I need to dig a little deeper obviously :). Its also interesting that the problem doesn't occur in exactly the same sequence every time, although I can reproduce it with LimeWire quite successfully. > Because some syscalls should be wrapped by iomgr.c, JVM cannot give up > wrapping them. If libc's internal FDs may be leaked into JVM due to > such necessary syscall wrappers, there's no other way than trying to > wrap all syscalls by JVM(iomgr.c) to ensure that all FD related > syscalls that potentially leaks FDs into JVM are managed by JVM. I can see how this can cause the JVM to encounter a fd it hasn't previously been aware of, but I'm not sure how it could cause fd_flags to be set when it shouldn't be. Thats what makes me think its something else in this case. I will investigate further. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message