You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Tim Ellison (JIRA)" <ji...@apache.org> on 2006/12/12 17:17:22 UTC
[jira] Resolved: (HARMONY-2002) IBM VME crashes while running derby
with security manager installed.
[ http://issues.apache.org/jira/browse/HARMONY-2002?page=all ]
Tim Ellison resolved HARMONY-2002.
----------------------------------
Resolution: Won't Fix
Assignee: Tim Ellison
Leo, let me know if there are changes required to harmony code for this problem.
> IBM VME crashes while running derby with security manager installed.
> --------------------------------------------------------------------
>
> Key: HARMONY-2002
> URL: http://issues.apache.org/jira/browse/HARMONY-2002
> Project: Harmony
> Issue Type: Bug
> Components: VM
> Reporter: Leo Li
> Assigned To: Tim Ellison
> Attachments: derby_test.diff
>
>
> During my trying to install security manage while running derby on Harmony, I found that IBM VME crashes even in the simplest test.
> It reports:
> Unhandled exception
> Type=Segmentation error vmState=0x00040000
> J9Generic_Signal_Number=00000004 ExceptionCode=c
> A ContextFlags=0001003f
> Handler1=7FE50390 Handler2=7FD074F0 Inaccessible
> EDI=0152D000 ESI=00000000 EAX=00033D50 EBX=01636
> ECX=00000002 EDX=11507068
> EIP=11502F6A ESP=0F72FCCC EBP=0013FBC4
> Module=D:\workspaces\workspace\Harmony\deploy\jd
> Module_base_address=11500000 Offset_in_DLL=00002
> Target=2_30_20060727_07300_lHdSMR (Windows XP 5.
> CPU=x86 (2 logical CPUs) (0x7f67b000 RAM)
> JavaVMInitArgs.nOptions=27:
> -Dcom.ibm.oti.vm.vmdir=D:\workspaces\workspa
> fault\
> -Dcom.ibm.oti.vm.exe=D:\workspaces\workspace
> .exe
> -Dcom.ibm.oti.vm.bootstrap.library.path=D:\w
> oy\jdk\jre\bin;D:\workspaces\workspace\Harmony\d
> -Xbootclasspath/p:D:\workspaces\workspace\Ha
> \luni-kernel.jar;D:\workspaces\workspace\Harmony
> rity-kernel.jar
> -Xint
> -Duser.language=en
> -Duser.country=US
> -Dderby.system.home=D:\workspaces\test\myder
> -Dderby.infolog.append=true
> -Dij.defaultResourcePackage=/org/apache/derb
> g/
> -Dframework=embedded
> -Djava.security.manager
> -Djava.security.policy=D:\workspaces\test\my
> -DderbyTesting.clientjar=file:/D:/workspaces
> -DderbyTesting.testjarpath=D:\workspaces\wor
> es.jar
> -DderbyTesting.codejar=file:/D:/workspaces/w
> -DderbyTesting.testjar=file:/D:/workspaces/w
> -DderbyTesting.codedir=C:\Tools\jdks\classes
> -DderbyTesting.serverhost=localhost
> -DderbyTesting.clienthost=localhost
> -Dconsole.encoding=Cp1252
> -Djava.home=D:\workspaces\workspace\Harmony\
> -Djava.library.path=D:\workspaces\workspace\
> \workspaces\workspace\Harmony\deploy\jdk\jre\bin
> \Harmony\deploy\jdk\jre\bin\;D:\workspaces\works
> -Djava.class.path=D:\workspaces\workspace\de
> jakarta-oro-2.0.8.jar;C:\Tools\jars\junit.jar
> _org.apache.harmony.vmi.portlib (extra info:
> -Xjcl:jclclear_23
> _j2se_j9=136448
> util.getPropertyArg
> K0319java.security.AccessControlException: Acces
> D:\workspaces\test\myderby\supersimple\supersim
> at java.security.AccessController.checkP
> 94)
> at java.lang.SecurityManager.checkPermis
> at java.lang.SecurityManager.checkRead(S
> at java.io.FileInputStream.<init>(FileIn
> at java.io.FileInputStream.<init>(FileIn
> at org.apache.derby.impl.tools.ij.util.g
> at org.apache.derby.impl.tools.ij.Main.m
> at org.apache.derby.impl.tools.ij.Main14
> at org.apache.derby.tools.ij.main(ij.jav
> Generated system dump: C:\Documents and Settings
> Thread: Finalizer thread (priority 5) (daemon) (
> NATIVE java/util/zip/ZipFile.closeZipImpl()V
> 00000008 java/util/zip/ZipFile.close()V
> 00000001 java/util/zip/ZipFile.finalize()V
> Thread: Gc Slave Thread (priority 5) (daemon)
> Thread: DestroyJavaVM helper thread (priority 5)
> If I commented out the close() in ZipFile.finalize(), it works well.
> But actually after digging into it, I found it is occurs in hythread_moniter_enter():
> IDATA VMCALL
> hythread_monitor_enter (hythread_monitor_t monitor)
> {
> hythread_t self = MACRO_SELF ();
> ASSERT (self);
> ASSERT (monitor);
> ASSERT (FREE_TAG != monitor->count);
> if (monitor->owner == self)
> {
> >>Occurs here: ASSERT (monitor->count >= 1);
> monitor->count++;
> if (IS_JLM_ENABLED (self))
> {
> ASSERT (monitor->tracing);
> monitor->tracing->recursive_count++;
> monitor->tracing->enter_count++;
> }
> return 0;
> }
> return monitor_enter (self, monitor);
> }
> Besides, it seems to related with multi-thread, since I can always reproduce it in my machine, but on another I can do it after I add some synchronize mechanism.
> I am looking to it. If anyone is interested in the topic, here is a patch, in whch I add some synchronize mechanism helping to reproduce the problem in org.apache.derby.impl.tools.ij.Main. As to how to build and test it, pls refer to http://wiki.apache.org/harmony/Apache_Derby.
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira