Rana, Everything is correct in you description, but it looks like that * HARMONY-2018* <https://issues.apache.org/jira/browse/HARMONY-2018> should fix described bug. I think Alexei will have a chance to check it.
Thank you. Pavel Afremov. On 11/6/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
Alexei, The1363 submission added functionality for lazy exception support, for exceptions in the VM code. exn_raise_by_name_internal was such a function. This may not be bug free ( as is true of any code ) and we need to check out 2070. I will take a look, as should Pavel. I think that while committing 1363, StackTest failed and there were other asserts, which Geir disabled to not block the large submission. This is not really anything to do with lazy exceptions. This is an issue where parts of the main thread's stack virtual memory are unmapped on Linux. I later added a fix for this. The two issues are orthogonal to each other. Rana On 11/5/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote: > > Rana, Pavel (Afremov), All, > > Geir's comment on r443504 (fix for > http://issues.apache.org/jira/browse/HARMONY-1363 [drlvm] Java 1.5, 64 > bit support, JVMTI improvements) reads: > > > 1) Stack overflow exception stuff is broken. I had to remove the > assert > > in signals_ia32.cpp line 336. Rana knows and will look. I also > > disabled the StackTest. > > I have noticed that the patch added a new function > exn_raise_by_name_internal which fails on the first invocation checking > an assertion about thread state, see > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][unit] > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest > crashes DRLVM. > > I also have noticed that this function is called to create > java.lang.StackOverflowError. > > Could you help me to understand the current status of the problem? > > With best regards, > Alexei Fedotov, > Intel Java & XML Engineering > > >-----Original Message----- > >From: Rana Dasgupta [mailto:[EMAIL PROTECTED] > >Sent: Wednesday, October 18, 2006 4:27 AM > >To: harmony-dev@incubator.apache.org > >Subject: Re: [drlvm] [testing] Excluding commit tests until the problem > is > >fixed > > > >I fixed the StackOverflow functionality problem by going back and > mapping > >all pages ( guard, alternate stack ) meticulously before trying to > protect > >them. I think we should have done this in the first place. I also > cleaned > >up the previous initialization workarounds and asserts Geir and I had > >discussed on the JIRA. The Stacktest and all other stack related tests > now > >pass. > > > >I'll submit the patch against 1786 in the next few hours after running > >acceptance tests. > > > >Rana > > > > > > > >> On 10/16/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > >> > > >> > > >> > > >> > On 10/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > >> > > > >> > > On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote: > >> > > >> I tried to put some back. StackTest still doesn't work. It's > >hard > >> > > to > >> > > >> believe... so I gave up and just kept going :) > >> > > > >> > > >I wonder if the test or the implementation are wrong. Maybe > someone > >> > > who added > >> > > >the test initially could know the answer. > >> > > >> > > >> > > >> > There is nothing wrong with the stacktest test itself. The > >> > > implementation is not quite 100%complete( I think ), but has > enough > >> > > functionality and the test passes on Windows. On Linux, it fails. > I > >am not > >> > > sure if this is a regression, or if this ever worked. There is a > JIRA > >issue > >> > > 1786. In summary, memory protection setup for the guard page > fails on > >the > >> > > main thread(only). So the guard does not work and the overflow is > not > >> > > detected. > >> > > >> > > >> > mprotect fails with an ENOMEM which is either a mapping failure > or a > >> > kernel failure. mprotect() has some known flakiness it seems, as > per > >> > literature. > >> > > >> > The basic implementation on Linux is sound. There are secondary > >design > >> > issues,but we can only get to them later after we have figured out > why > >the > >> > guard setup fails on the main thread. > >> > > >> > > >> > > >> > > >> > > > >> > >> > >> > >> > >> >
