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. >> > >> > >> > >> > >> > >> >> >> >> >>
