Re: [Oorexx-devel] Question on Halt() and possibility of interfering with Java's signal handling?
Just wanted to report that the problem has gone away and it had nothing to do with ooRexx or Java, but with a coding error: in the code path there was a condition which caused the invocation of RexxFreeMemory() on the same pointer twice. This obviously caused the observed behaviour that I reported (much later though). Once found and fixed, everything now works in this area as it should. ---rony Rick McGuire wrote: > I did spot a resource locking problem in the Halt() API that could > create a race condition that might result in a memory overlay. I've > fixed that, but there really is not much else involved with that API. > > Rick > > On Thu, Jun 4, 2009 at 5:34 PM, Rony G. Flatscher > wrote: > >> Rick McGuire wrote: >> >>> Halt() does not use any signalling mechanisms. It only iterates >>> through the threads associated with each instance and sets a flag >>> indicating that a halt condition needs to be raised. That flag is >>> detected at instruction boundaries and the condition gets raised. >>> That's all that this does. >>> >>> >> Thanks, that really helps a lot, because then I will concentrate to look >> over the code thoroughly to see what might cause this. >> >> ---rony >> -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Question on Halt() and possibility of interfering with Java's signal handling?
I did spot a resource locking problem in the Halt() API that could create a race condition that might result in a memory overlay. I've fixed that, but there really is not much else involved with that API. Rick On Thu, Jun 4, 2009 at 5:34 PM, Rony G. Flatscher wrote: > > Rick McGuire wrote: >> Halt() does not use any signalling mechanisms. It only iterates >> through the threads associated with each instance and sets a flag >> indicating that a halt condition needs to be raised. That flag is >> detected at instruction boundaries and the condition gets raised. >> That's all that this does. >> > Thanks, that really helps a lot, because then I will concentrate to look > over the code thoroughly to see what might cause this. > > ---rony > > > > > -- > OpenSolaris 2009.06 is a cutting edge operating system for enterprises > looking to deploy the next generation of Solaris that includes the latest > innovations from Sun and the OpenSource community. Download a copy and > enjoy capabilities such as Networking, Storage and Virtualization. > Go to: http://p.sf.net/sfu/opensolaris-get > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Question on Halt() and possibility of interfering with Java's signal handling?
Rick McGuire wrote: > Halt() does not use any signalling mechanisms. It only iterates > through the threads associated with each instance and sets a flag > indicating that a halt condition needs to be raised. That flag is > detected at instruction boundaries and the condition gets raised. > That's all that this does. > Thanks, that really helps a lot, because then I will concentrate to look over the code thoroughly to see what might cause this. ---rony -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Question on Halt() and possibility of interfering with Java's signal handling?
Halt() does not use any signalling mechanisms. It only iterates through the threads associated with each instance and sets a flag indicating that a halt condition needs to be raised. That flag is detected at instruction boundaries and the condition gets raised. That's all that this does. Rick On Thu, Jun 4, 2009 at 5:23 PM, Rony G. Flatscher wrote: > Having proceeded to a point in which I am confident that dispatching Rexx > intepreter instances on separate Java threads is stable, I turned back to a > use case from a BSF4Rexx user who tries to halt Rexx threads from Java. In > the 4.0 API version the Halt() API of the interpreter instance is used > > The problem/phenomenon I am confronted with: after terminating the JVM I get > access violations in code outside of rexx (or BSF4Rexx), e.g. a stack-trace > may look like: > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7c9204fa, pid=5604, > tid=4908 > # > # Java VM: Java HotSpot(TM) Client VM (11.0-b16 mixed mode, sharing > windows-x86) > # Problematic frame: > # C [ntdll.dll+0x104fa] > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > --- T H R E A D --- > > Current thread (0x02bedc00): VMThread [stack: 0x02cd,0x02d2] > [id=4908] > > siginfo: ExceptionCode=0xc005, reading address 0xfffd > > Registers: > EAX=0x, EBX=0x02d1efe0, ECX=0x0008, EDX=0x7c38b1d8 > ESP=0x02d1eecc, EBP=0x02d1eed0, ESI=0x6dae35a4, EDI=0x002b > EIP=0x7c9204fa, EFLAGS=0x00010246 > > Top of Stack: (sp=0x02d1eecc) > 0x02d1eecc: 6daa34e4 02d1ef1c 7c3420d6 002b > 0x02d1eedc: 6daa34e4 6dae35a4 > 0x02d1eeec: 02d1efe0 001a0018 7ffdbc00 > 0x02d1eefc: 000910a0 02d1eee4 02d1eaf0 > 0x02d1ef0c: 02d1ef48 7c34240d 7c37a368 > 0x02d1ef1c: 02d1ef58 7c34c0b4 6daa34e4 > 0x02d1ef2c: 0003 02d1efe0 0020 > 0x02d1ef3c: 02d1efdc 02d1ef28 02d1eaf0 02d1f054 > > Instructions: (pc=0x7c9204fa) > 0x7c9204ea: 47 10 a9 00 00 02 69 0f 85 db a8 03 00 8b 45 10 > 0x7c9204fa: 8a 48 fd 83 c0 f8 f6 c1 01 56 0f 84 e2 a8 03 00 > > > Stack: [0x02cd,0x02d2], sp=0x02d1eecc, free space=315k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > C [ntdll.dll+0x104fa] > C [msvcr71.dll+0x20d6] > C [msvcr71.dll+0xc0b4] > V [jvm.dll+0x1c8ac4] > > VM_Operation (0x00a5fb38): Exit, mode: safepoint, requested by thread > 0x002b7000 > > V [jvm.dll+0x1c8ac4] > --- P R O C E S S --- > VM_Operation (0x00a5fb38): Exit, mode: safepoint, requested by thread > 0x002b7000 > Java Threads: ( => current thread ) > 0x02c02000 JavaThread "Low Memory Detector" daemon [_thread_blocked, > id=5972, stack(0x02eb,0x02f0)] > 0x02bff000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=2944, > stack(0x02e6,0x02eb)] > 0x02bfa400 JavaThread "Attach Listener" daemon [_thread_blocked, id=3100, > stack(0x02e1,0x02e6)] > 0x02bf9000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, > id=2088, stack(0x02dc,0x02e1)] > 0x02bf0c00 JavaThread "Finalizer" daemon [_thread_blocked, id=4400, > stack(0x02d7,0x02dc)]02f0)] > 0x02bef400 JavaThread "Reference Handler" daemon [_thread_blocked, > id=3076, stack(0x02d2,0x02d7)] > 0x002b7000 JavaThread "main" [_thread_blocked, id=5464, > stack(0x00a1,0x00a6)]1,0x02e6)] > 0x02bf9000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, > id=2088, stack(0x02dc,0x02e1)] > Other Threads:avaThread "Finalizer" daemon [_thread_blocked, id=4400, > stack(0x02d7,0x02dc)] > =>0x02bedc00 VMThread [stack: 0x02cd,0x02d2] [id=4908]ocked, > id=3076, stack(0x02d2,0x02d7)] > 0x002b7000 JavaThread "main" [_thread_blocked, id=5464, > stack(0x00a1,0x00a6)] > VM state:at safepoint (shutting down) > Other Threads: > VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) > [0x002b5e70] UNKNOWN - owner thread: 0x02bedc00 > VM state:at safepoint (shutting down) > Heap > def new generation total 960K, used 448K [0x22af, 0x22bf, > 0x22fd) > eden space 896K, 42% used [0x22af, 0x22b502c0, 0x22bd) > from space 64K, 100% used [0x22be, 0x22bf, 0x22bf) > to space 64K, 0% used [0x22bd, 0x22bd, 0x22be) > tenured generation total 4096K, used 97K [0x22fd, 0x233d, > 0x26af) >the space 4096K, 2% used [0x22fd, 0x22fe87d8, 0x22fe8800, > 0x233d) > compacting perm gen total 12288K, used 284K [0x26af, 0x276f, > 0x2aaf) >the space 12288K, 2% used [0x26af, 0x26b372f0, 0x26b37400, > 0x276f) > ro space 8192K, 67% used [0x2aaf, 0x2b052d98, 0x2b052e00, > 0x2b2f) > rw space 12288K, 53% used [0x2b2f, 0x2b960640, 0x2b960
