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
[Oorexx-devel] Question on Halt() and possibility of interfering with Java's signal handling?
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, 0x2b960800, 0x2bef) Dynamic libraries: 0x0040 - 0x00424000 E:\jdk1.6.0_11\bin\java.exe 0x7c91 - 0x7c9c9000 D:\WINDOWS\system32\ntdll.dll ... cut ... As can be seen from the output above, rexx is not involved here anymore
Re: [Oorexx-devel] rxapi daemon / kill -TERM not always working / HEAD
Hello,
this is my first attempt to add:
- handler for SIGTERM
- make rxapi capable of working with the AIX subsystem resource
controller (SRC)
I had added some debugging output to the Stop() routine during my tests.
The apiServer.terminateServer() gets called and then exit(1) gets called.
So it can't be completely wrong :-))
Index: APIService.cpp / not checked with Linux ... I would need a
volunteer for that :-)
===
--- APIService.cpp(revision 4762)
+++ APIService.cpp(working copy)
@@ -87,6 +87,22 @@
apiServer.terminateServer(); // shut everything down
}
+/*==*
+ * Function: Stop
+ *
+ * Purpose:
+ *
+ * handles the stop request.
+ *
+ *
+
*==*/
+void Stop(int signo)
+{
+apiServer.terminateServer(); // shut everything down
+
+exit(1);
+}
+
/
/
// Routines to run RXAPI as an daemon BEGIN
@@ -166,6 +182,10 @@
char pid_buf[256];
int pfile, len;
pid_t pid = 0;
+#if defined(AIX)
+struct stat st;
+#endif
+struct sigaction sa;
// Get the command line args
if (argc > 1) {
@@ -204,14 +224,62 @@
close(pfile);
// make ourselves a daemon
-if (morph2daemon() == false) {
-return -1;
+// - if this is AIX we check if the rxapi daemon was sarted via SRC
+// - if the daemon was started via SRC we do not morph - the SRC
handles this
+//
+// - add to AIX SRC without auto restart:
+// mkssys -s rxapi -p /opt/ooRexx/bin/rxapi -i /dev/null -e
/dev/console \
+// -o /dev/console -u 0 -S -n 15 -f 9 -O -Q
+//
+// - add to AIX SRC with auto restart:
+// mkssys -s rxapi -p /opt/ooRexx/bin/rxapi -i /dev/null -e
/dev/console \
+// -o /dev/console -u 0 -S -n 15 -f 9 -R -Q
+#if defined(AIX)
+if (fstat(0, &st) <0) {
+if (morph2daemon() == false) {
+return -1;
+}
+} else {
+if ((st.st_mode & S_IFMT) == S_IFCHR) {
+if (isatty(0)) {
+if (morph2daemon() == false) {
+return -1;
+}
+}
+} else {
+if (morph2daemon() == false) {
+return -1;
+}
+}
}
+#else
+if (morph2daemon() == false) {
+return -1;
+}
+#endif
// run the server
+#if defined(AIX)
if (run_as_daemon == false) {
printf("Starting request processing loop.\n");
+} else {
+(void) setsid();
}
+#else
+if (run_as_daemon == false) {
+printf("Starting request processing loop.\n");
+}
+#endif
+
+// handle kill -15
+(void) sigemptyset(&sa.sa_mask);
+(void) sigaddset(&sa.sa_mask, SIGTERM);
+sa.sa_flags = SA_RESTART;
+sa.sa_handler = Stop;
+if (sigaction(SIGTERM, &sa, NULL) == -1) {
+exit(1);
+}
+
Run(false);
return 0;
Bye
Rainer
Rick McGuire wrote:
> I can't think of any reason why it would be a bad idea, though at this
> point, it should only be developed on trunk for a future release and
> not applied to the 4.0 branch.
>
> Rick
>
> On Thu, Jun 4, 2009 at 2:35 AM, Rainer Tammer wrote:
>
>> Hello,
>> if I did not miss something there is no explicit signal handler for
>> SIGTERM in the API daemon.
>>
>> Sometimes a simple kill does not terminate the daemon.
>> Would it be a problem if I add a signal handler for SIGTERM ?
>>
>> My idea is to add an handler which calls apiServer.terminateServer(); ...
>>
>> Is this a bad idea ?
>>
>> Bye
>> Rainer
>>
>>
>
> --
> 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/lis
Re: [Oorexx-devel] rxapi daemon / kill -TERM not always working
Hello, Rick McGuire wrote: > I can't think of any reason why it would be a bad idea, though at this > point, it should only be developed on trunk for a future release and > not applied to the 4.0 branch. > > thats fine with me. In this step I will also add some code for AIX to enable the rxapi daemon to be able to run under the subsystem resource controller. This code basically checks (only under AIX) if the daemon was stared via the SRC and in this case do not fork. The STDIN/STDOUT/STDERR is handled via the SRC. If the rxapi daemon runs under the SRC you get a nice error message if the daemon crashes: --- LABEL: SRC_SVKO IDENTIFIER: BC3BE5A3 Date/Time: Mon Apr 13 13:07:25 DFT 2009 Sequence Number: 414 Machine Id: 0003F7EAD300 Node Id: build53 Class: S Type:PERM Resource Name: SRC Description SOFTWARE PROGRAM ERROR Probable Causes APPLICATION PROGRAM Failure Causes SOFTWARE PROGRAM Recommended Actions MANUALLY RESTART SUBSYSTEM IF NEEDED Detail Data SYMPTOM CODE 983055 SOFTWARE ERROR CODE -9017 ERROR CODE 0 DETECTING MODULE 'srchevn.c'@line:'355' FAILING MODULE rxapi In the case of a crash the SRC could (if configured) try to restart the daemon. I will apply a patch to HEAD in the near future :-)... > Rick > Bye Rainer > On Thu, Jun 4, 2009 at 2:35 AM, Rainer Tammer wrote: > >> Hello, >> if I did not miss something there is no explicit signal handler for >> SIGTERM in the API daemon. >> >> Sometimes a simple kill does not terminate the daemon. >> Would it be a problem if I add a signal handler for SIGTERM ? >> >> My idea is to add an handler which calls apiServer.terminateServer(); ... >> >> Is this a bad idea ? >> >> Bye >> Rainer >> >> > > -- > 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] rxapi daemon / kill -TERM not always working
I can't think of any reason why it would be a bad idea, though at this point, it should only be developed on trunk for a future release and not applied to the 4.0 branch. Rick On Thu, Jun 4, 2009 at 2:35 AM, Rainer Tammer wrote: > Hello, > if I did not miss something there is no explicit signal handler for > SIGTERM in the API daemon. > > Sometimes a simple kill does not terminate the daemon. > Would it be a problem if I add a signal handler for SIGTERM ? > > My idea is to add an handler which calls apiServer.terminateServer(); ... > > Is this a bad idea ? > > Bye > Rainer > -- 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
