Date: Sun, 03 Nov 2002 10:16:16 +0900 From: Fuyuhiko Maruyama <fuyuhik8@is.titech.ac.jp> To: Michael E Mercer <mmercer@nc.rr.com> Cc: Greg Lewis <glewis@eyesbeyond.com>, freebsd-java@FreeBSD.ORG Subject: Re: LimeWire crash gdb information Message-ID: <55of97wizj.wl@dittohead.is.titech.ac.jp> In-Reply-To: <20021030172314.A31631@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, On Wed, 30 Oct 2002 17:23:14 +1030, Greg Lewis wrote: > > On Sat, Oct 26, 2002 at 10:41:20PM -0400, Michael E Mercer wrote: > > If I am to assume that each method call below calls the method mentioned right above it, > > then why is the res_send method calling socket found in iomgr.c? > > > > res_send is found in libc and therefore one would think that this would call the > > systems socket method. Am I totally wrong here? > > IIRC you are correct. The block of __strong_reference code at the bottom > of iomgr.c is supposed to stop this and allow libc routines that use > things like socket internally to do so. I've cc'ed Fuyuhiko Maruyama-san > who originally added this code and hopefully he will correct me if my > memory is incorrect. > 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. 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. 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 will not be able to have enough time to analyze the problem more precisely right now because I will leave home for the next couple of weeks. I will visit Seattle for ACM conferences (JavaGrande-ISCOPE/OOPSLA). -- Fuyuhiko MARUYAMA <fuyuhik8@is.titech.ac.jp> Matsuoka laboratory, Department of Mathematical and Computing Sciences, Graduate School of Information Science and Engineering, Tokyo Institute of Technology. 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?55of97wizj.wl>