Date: Tue, 12 Nov 2002 16:32:30 +1030 From: Greg Lewis <glewis@eyesbeyond.com> To: Fuyuhiko Maruyama <fuyuhik8@is.titech.ac.jp> Cc: Michael E Mercer <mmercer@nc.rr.com>, freebsd-java@FreeBSD.ORG Subject: Re: LimeWire crash gdb information Message-ID: <20021112163230.A95899@misty.eyesbeyond.com> 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 %2B0900 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021112163230.A95899>