FW: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Stevenson, Charles]

Resolved, thanks to Joel Yates at IBM for nailing this for me.

My uvconfig ULIMIT parameter was way way too big.
The default is 128000, ours was 800.
I changed it to 128000 and the memory leak got plugged.

It's one of those things where it was set big when I took over and
didn't seem broke so I didn't fix.
Except the HP-Itanium / HPUX 11.23 / UV 10.2.6 combo apparently didn't
agree.

I can't say I completely understand this.  
Or even why there is a UV config parameter for ULIMIT.  
Or why it matters on EXECUTE...CAPTURING...

Thank-you everyone who took a look on their system.
Especially Richard Lewis, who is soon hopping down the same Itanium
bunny path.

cds
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[rbl000]

We only use PICK flavor here, no special options set.

Richard Lewis

 --- On Thu 03/20, Ray Wurlod < [EMAIL PROTECTED] > wrote:
From: Ray Wurlod [mailto: [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Date: Thu, 20 Mar 2008 12:03:21 +0800
Subject: RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory  fault.

Just out of curiosity, because EXECUTE is (may be) handled differently, what is 
the account flavor in each case?  And have you set any compiler options such as 
EXEC.EQ.PERFORM ?---u2-users mailing [EMAIL PROTECTED] unsubscribe please 
visit http://listserver.u2ug.org/

___
No banners. No pop-ups. No kidding.
Make My Way  your home on the Web - http://www.myway.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Stevenson, Charles]

From: Ray Wurlod
> Just out of curiosity, because EXECUTE is (may be) handled
> differently, what is the account flavor in each case?  
> And have you set any compiler options such as EXEC.EQ.PERFORM ?

Primarilly tested in Pick-flavoured account, but IDEAL, too.

I've tried 
   $OPTIONS EXEC.EQ.PERFORM
   $OPTIONS PIOPEN.EXECUTE
   $OPTIONS DEFAULT
   $OPTIONS PIOPEN
All have the same result.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Ray Wurlod]

Just out of curiosity, because EXECUTE is (may be) handled differently, what is 
the account flavor in each case?  And have you set any compiler options such as 
EXEC.EQ.PERFORM ?
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[rbl000]

Since we'll be moving our production server to Itanium, etc., in the next new 
months, we'll be very interested to learn the circumstances that cause the 
problem, etc.

Thanks!
Richard


 --- On Wed 03/19, Stevenson, Charles < [EMAIL PROTECTED] > wrote:
From: Stevenson, Charles [mailto: [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Date: Wed, 19 Mar 2008 16:31:59 -0400
Subject: RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT  fatal memory   
fault.

I hear IBM was finally able to reproduce my problem. I don't know any
other details yet.
After I learn more, maybe I'll come back at you, Richard, and ask to
compare our 2 systems's configurations.
Thanks,
cds


___
No banners. No pop-ups. No kidding.
Make My Way  your home on the Web - http://www.myway.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Stevenson, Charles]

I hear IBM was finally able to reproduce my problem.  I don't know any
other details yet.
After I learn more, maybe I'll come back at you, Richard, and ask to
compare our 2 systems's configurations.
Thanks,
cds

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of rbl000
Sent: Wednesday, March 19, 2008 11:28 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory
fault.

Charles,

One of the guys in our shop tested this on one of our machines (HP
Itanium, HPUX 11.23, UV 10.2.6) and couln't see any problem.

He ran this code for 3,572,053 iterations with no increase in memory
(not even a byte):

0001: CNT = 0
0002: LOOP
0003:   CNT +=1
0004:   CRT OCONV(CNT, "MR0,")
0005:   EXECUTE "TIME" CAPTURING TIME.GOO
0006: UNTIL @FALSE DO
0007: REPEAT

He the following code 288,448 times with no increase in memory:

0001: CNT = 0
0002: LOOP
0003:   CNT +=1
0004:   CRT OCONV(CNT, "MR0,")
0005:   EXECUTE "* anything" CAPTURING TIME.GOO
0006: REPEAT

Best Regards,

Richard Lewis
Nu Skin Enterprises


 --- On Mon 03/17, Stevenson, Charles < [EMAIL PROTECTED]
> wrote:

This is on HP Itanium, HPUX11.23, UV10.2.6 Anticipating some of your
questions:

* My simple case fails at about
1/4 million iterations to fail on my smaller dev system,
1 million on the 2 larger production system.

* The memory leak applies to the session, not the program.
If I limit the number of iterations in the program, but repeatedly
execute it from TCL, eventually it fails.
This fails just the same:

VOC M.LOOP
O1 PA
02 LOOP
03 EXECUTE "RUN CDS.BP M
04 SH -c"ps -lp $$PID"
05 REPEAT
where M is limited to 100,000:
CDS.BP M
01 FOR I = 1 TO 10
02 EXECUTE "* comment" CAPTURING X
03 REPEAT


Thank-you in advance,

Charles Stevenson
Getronics
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


___
No banners. No pop-ups. No kidding.
Make My Way  your home on the Web - http://www.myway.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[rbl000]

Charles,

One of the guys in our shop tested this on one of our machines (HP Itanium, 
HPUX 11.23, UV 10.2.6) and couln't see any problem.

He ran this code for 3,572,053 iterations with no increase in memory (not even 
a byte):

0001: CNT = 0
0002: LOOP
0003:   CNT +=1
0004:   CRT OCONV(CNT, "MR0,")
0005:   EXECUTE "TIME" CAPTURING TIME.GOO
0006: UNTIL @FALSE DO
0007: REPEAT

He the following code 288,448 times with no increase in memory:

0001: CNT = 0
0002: LOOP
0003:   CNT +=1
0004:   CRT OCONV(CNT, "MR0,")
0005:   EXECUTE "* anything" CAPTURING TIME.GOO
0006: REPEAT

Best Regards,

Richard Lewis
Nu Skin Enterprises


 --- On Mon 03/17, Stevenson, Charles < [EMAIL PROTECTED] > wrote:

This is on HP Itanium, HPUX11.23, UV10.2.6
Anticipating some of your questions:

* My simple case fails at about
1/4 million iterations to fail on my smaller dev system,
1 million on the 2 larger production system.

* The memory leak applies to the session, not the program.
If I limit the number of iterations in the program,
but repeatedly execute it from TCL, eventually it fails.
This fails just the same:

VOC M.LOOP
O1 PA
02 LOOP
03 EXECUTE "RUN CDS.BP M
04 SH -c"ps -lp $$PID"
05 REPEAT
where M is limited to 100,000:
CDS.BP M
01 FOR I = 1 TO 10
02 EXECUTE "* comment" CAPTURING X
03 REPEAT


Thank-you in advance,

Charles Stevenson
Getronics
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


___
No banners. No pop-ups. No kidding.
Make My Way  your home on the Web - http://www.myway.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Stevenson, Charles]

I would love it if someone else using Itanium would tell me if they
do/don't see this.

My guess is similar to Tony's.
The child process does disappear after the execute.

Here's a snippet from where I monitored one of my problem processes (pid
5783) by looping 1x/sec:
"date; ps -flu cds33896|grep -v pts/| grep -e 5783"
You can see the child caught at various stages of execution.
Notice that the SZ column for the parent grows.
Notice that the parent's memory is duplicated(?) for the child.
I edited out a few columns to make it easy to read in an email:


  F S  UID   PID PPID SZSTIME   TIME COMD

Sun Mar 16 22:18:37 EDT 2008
401 S cds33896  57831 253057   Mar 15 688:35 phantom RUN BP MF
401 R cds33896 26712 5783 251568 22:18:37   0:00 phantom RUN BP MF

Sun Mar 16 22:18:38 EDT 2008
401 S cds33896  57831 253057   Mar 15 688:35 phantom RUN BP MF
401 R cds33896 26990 5783116 22:18:38   0:00 SH -c # comment

Sun Mar 16 22:18:40 EDT 2008
401 R cds33896  57831 253061   Mar 15 688:36 phantom RUN BP MF

Sun Mar 16 22:18:41 EDT 2008
401 S cds33896  57831 253061   Mar 15 688:36 phantom RUN BP MF
401 R cds33896 27484 5783 251572 22:18:41   0:00 phantom RUN BP MF
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Greg Schraiber]

Try increasing your paging space.




At 01:21 AM 3/18/2008, Tony G wrote:

I'll take a wild guess. Maybe IBM can confirm this.

When you run a BASIC program the runtime allocates memory space
for BASIC variables.  When you use these variables for strings,
integers, or dynamic arrays the BASIC runtime manages that space.

When you EXECUTE, another process is temporarily created.  When
you CAPTURE, the StdOut from that process needs to go
"somewhere".  They can't push it back directly into BASIC space
of the parent process so they allocate new memory space (on the
"heap") and load the data.  When they return control back to your
current process they either return a pointer back to BASIC that
indicates where the new memory space is, or they will pass back a
string which BASIC then stores in the Capturing var.

Now, it seems to me that "someone" isn't letting go of the memory
that was created in the secondary process.
- If a 'ps' shows new processes are still there after Execute,
then it's obvious that because the processes aren't gone they
haven't released their resources.
- If the processes are gone then it's possible that a handle to
the new memory space was passed back to BASIC, but BASIC didn't
release the resource after it was used to populate your Capturing
variable.
- It could also be possible that it's the responsibility of the
secondary process to release its own resources, but due to some
release-specific bug in your HPUX11.23/UV10.2.6 that isn't
happening.

I would ask IBM to find out which process is supposed to be
releasing memory.  Specifically, someone does a malloc() and
someone is supposed to be doing a free().  It's pretty easy to
miss one free() instruction, and that's what causes memory leaks
like what you're seeing.

HTH
Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com

Currently serving as technical editor for "C#3.0 Unleashed" for
SAMS Publishing, and at the very moment I read this note I
happened to also be reading about memory allocation and garbage
collection - which generally isn't a problem in .NET.   ;)

(Link to book at Amazon.com, book won't be available for a couple
months.)
http://tinyurl.com/2mvn2v

> From: Stevenson, Charles
>CDS.BP M
>01 LOOP
>02   EXECUTE '* anything' CAPTURING X
>03 REPEAT
>
>>RUN CDS.BP M
>Memory fault(coredump)
>3046$ls -l core
>-rw---   1 cds33896   tech   279499648 Mar 17 17:11
core
> > This is on HP Itanium, HPUX11.23, UV10.2.6
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Tony G]

I'll take a wild guess. Maybe IBM can confirm this.

When you run a BASIC program the runtime allocates memory space
for BASIC variables.  When you use these variables for strings,
integers, or dynamic arrays the BASIC runtime manages that space.

When you EXECUTE, another process is temporarily created.  When
you CAPTURE, the StdOut from that process needs to go
"somewhere".  They can't push it back directly into BASIC space
of the parent process so they allocate new memory space (on the
"heap") and load the data.  When they return control back to your
current process they either return a pointer back to BASIC that
indicates where the new memory space is, or they will pass back a
string which BASIC then stores in the Capturing var.

Now, it seems to me that "someone" isn't letting go of the memory
that was created in the secondary process.
- If a 'ps' shows new processes are still there after Execute,
then it's obvious that because the processes aren't gone they
haven't released their resources.
- If the processes are gone then it's possible that a handle to
the new memory space was passed back to BASIC, but BASIC didn't
release the resource after it was used to populate your Capturing
variable.
- It could also be possible that it's the responsibility of the
secondary process to release its own resources, but due to some
release-specific bug in your HPUX11.23/UV10.2.6 that isn't
happening.

I would ask IBM to find out which process is supposed to be
releasing memory.  Specifically, someone does a malloc() and
someone is supposed to be doing a free().  It's pretty easy to
miss one free() instruction, and that's what causes memory leaks
like what you're seeing.

HTH
Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com

Currently serving as technical editor for "C#3.0 Unleashed" for
SAMS Publishing, and at the very moment I read this note I
happened to also be reading about memory allocation and garbage
collection - which generally isn't a problem in .NET.   ;)

(Link to book at Amazon.com, book won't be available for a couple
months.)
http://tinyurl.com/2mvn2v 

> From: Stevenson, Charles 
>CDS.BP M
>01 LOOP
>02   EXECUTE '* anything' CAPTURING X
>03 REPEAT
> 
>>RUN CDS.BP M
>Memory fault(coredump)
>3046$ls -l core
>-rw---   1 cds33896   tech   279499648 Mar 17 17:11
core
> > This is on HP Itanium, HPUX11.23, UV10.2.6
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault. {Unclassified}

[HENDERSON MIKE, MR]

UV 10.1.18, Windows Server 2003
Using Louie's code without the DISPLAY

Ran over two-and-a-quarter million iterations so far, task memory
allocation for "tl_server.exe" is still 10,344KB, the same as it was
when I started. It also spawns a "SYSTEM" thread which steadily consumes
40KB


Regards


Mike

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Louie Bergsagel
Sent: Tuesday, 18 March 2008 1:52 p.m.
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory
fault.

I killed this after 1.4 million iterations of executing and displaying
the date (capturing X) and a counter with no problems.

 TEST.FATAL.CS
0001   COUNTER = 0
0002   LOOP
0003  EXECUTE "DATE" CAPTURING X
0004  COUNTER += 1
0005  DISPLAY X:" ":COUNTER
0006   REPEAT
0007END

Monday, March 17, 2008  05:47pm~ 1,406,473

I don't dare let it run overnight, in case it does blow up the system.

-- Louie
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
The information contained in this Internet Email message is intended
for the addressee only and may contain privileged information, but not
necessarily the official views or opinions of the New Zealand Defence Force.
If you are not the intended recipient you must not use, disclose, copy or 
distribute this message or the information in it.

If you have received this message in error, please Email or telephone
the sender immediately.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Stevenson, Charles]

From: Allen Egerton
> Capturing writes to uvtemp.  
> Are you running out of disk space or perhaps inodes?

Good question, but no.  Plenty of room in uvtemp.  Plenty of inodes.
It does leave an 0-byte capturenaa file in uvtemp.
0-byte, because I am really doing nothing (execute a comment).
If I do something real, the capture file does contain the appropriate
thing, but it does not correspond to the runaway memory usage.

It also leaves an aceb printer memory segment that needs cleaning up
too.
 (ipcs -mop  &  uv/bin/uvlictool clean_lic )
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Bill Haskett]

Charles:

I ran this in UV v10.2 PE on my XP Thinkpad.  It's been running and running and
running.  Task Manager says I'm using 100% of CPU but the memory isn't getting 
worse.

HTH.

Bill

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:owner-u2-
>[EMAIL PROTECTED] On Behalf Of Louie Bergsagel
>Sent: Monday, March 17, 2008 4:52 PM
>To: u2-users@listserver.u2ug.org
>Subject: Re: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.
>
>I killed this after 1.4 million iterations of executing and displaying the
>date (capturing X) and a counter with no problems.
>
> TEST.FATAL.CS
>0001   COUNTER = 0
>0002   LOOP
>0003  EXECUTE "DATE" CAPTURING X
>0004  COUNTER += 1
>0005  DISPLAY X:" ":COUNTER
>0006   REPEAT
>0007END
>
>Monday, March 17, 2008  05:47pm~ 1,406,473
>
>I don't dare let it run overnight, in case it does blow up the system.
>
>-- Louie
>---
>u2-users mailing list
>u2-users@listserver.u2ug.org
>To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Allen Egerton]

Stevenson, Charles wrote:

IBM can't reproduce this.  I'm hoping someone else can.
That didn't come out right.  I don't really want to you have this
problem.  That would be mean.  I just hope this august body can help.

Simplest case:

   CDS.BP M
   01 LOOP
   02   EXECUTE '* anything' CAPTURING X
   03 REPEAT

   >RUN CDS.BP M
   Memory fault(coredump)
   3046$ls -l core
   -rw---   1 cds33896   tech   279499648 Mar 17 17:11 core




Capturing writes to uvtemp.  Are you running out of disk space or 
perhaps inodes?


--
Allen Egerton
aegerton at pobox dot com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Louie Bergsagel]

I killed this after 1.4 million iterations of executing and displaying the
date (capturing X) and a counter with no problems.

 TEST.FATAL.CS
0001   COUNTER = 0
0002   LOOP
0003  EXECUTE "DATE" CAPTURING X
0004  COUNTER += 1
0005  DISPLAY X:" ":COUNTER
0006   REPEAT
0007END

Monday, March 17, 2008  05:47pm~ 1,406,473

I don't dare let it run overnight, in case it does blow up the system.

-- Louie
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Stevenson, Charles]

From: Louie Bergsagel
> How long before it fails?

A few minutes for me, for that simple test.
The question is what's memory doing?
Try looking at the process with -l option of the unix ps command.

But look at this where I execute an "SH" command:
  EXECUTE "SH -c'# comment'" CAPTURING X
& then printed a report line every 100,000 iterations.
It still failed after 990,230 iterations,  but ran slower & slower &
slower.
It took 28 hours to get to that point, whereas my old much slower
PA/risc got to that number in ~5 hrs.
Look at Mem SZ: constant 942, vs growing to 230145.

Itanium:

0001: HP-UX x0003031 B.11.23 U ia64 2885820074 unlimited-user license
0002: uid=5517(cds33896) gid=212(tech)
0003: -5783 resizetmp From cds33896
0004: RUN CDS.BP MEMFAULT3
0005: 12:24:01 15 MAR 2008  Count   Secs  Sys(9)  Mem SZ
0006: 12:49:09 15 MAR 2008  10  1508  420550  26715
0007: 13:43:27 15 MAR 2008  20  3257 1138400  52103
0008: 15:14:58 15 MAR 2008  30  5490 1947890  77495
0009: 17:30:49 15 MAR 2008  40  8151 2831010 103019
0010: 20:35:40 15 MAR 2008  50 11090 3734720 128407
0011: 00:22:42 16 MAR 2008  60 13621 4617480 153865
0012: 05:07:25 16 MAR 2008  70 17083 5582570 179357
0013: 10:24:14 16 MAR 2008  80 19008 6438780 204745
0014: 16:17:22 16 MAR 2008  90 21188 7272240 230145 
Bottom at line 14.
(6 hours later, this aborted before reaching 1 million.
 Dumped a core file.)


Here's the same job on PA/risc.
It took ~5 hrs to reach the same point.

0001: HP-UX w0003030 B.11.11 U 9000/800 1488117173 unlimited-user
license
0002: uid=5517(cds33896) gid=212(tech)
0003: -23412 resizetmp From cds33896
0004: RUN CDS.BP MEMFAULT3 
0005: 17:16:55 15 MAR 2008  Count   Secs  Sys(9) Mem SZ 
0006: 17:51:39 15 MAR 2008  10  2083  278170   942 
0007: 18:24:48 15 MAR 2008  20  1988  269890   942 
0008: 18:57:50 15 MAR 2008  30  1982  269170   942 
0009: 19:31:13 15 MAR 2008  40  2002  271450   942 
0010: 20:04:06 15 MAR 2008  50  1973  268050   942 
0011: 20:36:04 15 MAR 2008  60  1917  256230   942 
0012: 21:07:16 15 MAR 2008  70  1872  248220   942 
0013: 21:38:34 15 MAR 2008  80  1878  249360   942 
0014: 22:09:35 15 MAR 2008  90  1861  247390   942 
0015: 22:40:38 15 MAR 2008 100  1862  247480   942 
0016: 23:11:46 15 MAR 2008 110  1867  248500   942 
0017: 23:42:51 15 MAR 2008 120  1865  246870   942 
0018: 00:14:33 16 MAR 2008 130  1901  250930   942 
0019: 00:47:19 16 MAR 2008 140  1965  259980   942 
0020: 01:19:09 16 MAR 2008 150  1910  254220   942 
0021: 01:50:15 16 MAR 2008 160  1865  247170   942 
0022: 02:21:10 16 MAR 2008 170  1855  246310   942 
0023: 02:52:10 16 MAR 2008 180  1859  246240   942 
0024: 03:23:04 16 MAR 2008 190  1854  245850   942 
Bottom at line 24. 
(Killed duiring nightly UV stop/restart @3:30AM.)
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Stevenson, Charles]

From:  Ken Hall
> Maybe, just maybe, the loop is executing too fast on the
> Itanium server. Try putting a SLEEP into the loop.

Ken, 

See line 9.  
Notice SZ column increases by the same amount with or without sleep.

>CT CDS.BP KEN

 KEN
0001   PERFORM "SH -c'ps -lp $PPID'"
0002   CRT TIMEDATE() , 'Simple:'
0003   FOR I = 1 TO 600
0004  EXECUTE '* DUMMY' CAPTURING X
0005   NEXT I
0006   PERFORM "SH -c'ps -lp $PPID'"
0007   CRT TIMEDATE(), 'Simple done.  With sleep:'
0008   FOR I = 1 TO 600
0009  SLEEP 1
0010  EXECUTE '* DUMMY' CAPTURING X
0011   NEXT I
0012   PERFORM "SH -c'ps -lp $PPID'"
0013   CRT TIMEDATE(), 'done.'
>
>RUN CDS.BP KEN
  F SUID   PID  PPID  C PRI NI ADDR   SZ
WCHAN TTY   TIME COMD
401 S   5517 19121 18392  0 158 20 e001894f24c0 1015
e0018c70c000 pts/ta0:00 uvsh
19:50:36 17 MAR 2008  Simple:
  F SUID   PID  PPID  C PRI NI ADDR   SZ
WCHAN TTY   TIME COMD
401 S   5517 19121 18392  7 158 20 e001894f24c0 1172
e0018c70c000 pts/ta0:00 uvsh
19:50:36 17 MAR 2008  Simple done.  With sleep:
  F SUID   PID  PPID  C PRI NI ADDR   SZ
WCHAN TTY   TIME COMD
401 S   5517 19121 18392  0 158 20 e001894f24c0 1328
e0018c70c000 pts/ta0:00 uvsh
20:00:42 17 MAR 2008  done.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Louie Bergsagel]

How long before it fails?

I've been running
LOOP
   EXECUTE "DATE" CAPTURING X
REPEAT
for over 8 minutes now, on an IBM P650, AIX 5.2, UniVerse release 10.1.12,
Pick syntax.

Perhaps because it is only March...

-- Louie In Seattle
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Ken Hall]

Maybe, just maybe, the loop is executing too fast on the Itanium 
server. Try putting a SLEEP into the loop.


Ken

At 03:13 PM 3/17/2008, you wrote:

IBM can't reproduce this.  I'm hoping someone else can.
That didn't come out right.  I don't really want to you have this
problem.  That would be mean.  I just hope this august body can help.

Simplest case:

   CDS.BP M
   01 LOOP
   02   EXECUTE '* anything' CAPTURING X
   03 REPEAT

   >RUN CDS.BP M
   Memory fault(coredump)
   3046$ls -l core
   -rw---   1 cds33896   tech   279499648 Mar 17 17:11 core


This is on HP Itanium, HPUX11.23, UV10.2.6
Anticipating some of your questions:

* If I get rid of CAPTURING X it works fine.

* PERFORM works fine.

* It doesn't matter what the command executed is.
  I executed a comment ('* anything')above, because what is more benign?

* ps -l shows memory increasing (SZ column) as the process executes.
  (Monitoring it from a 2nd session.)

* EXECUTE "SH -c'[any unix command]'" CAPTURING X
  gets slower & slower each iteration.
  ( Because ever increasing memory is duplicated for child process? )

* Other flavours of the CAPTURING syntax are the same:
EXECUTE cmd CAPTURING X
EXECUTE cmd,OUT>X
EXECUTE cmd,/OUT.>X
  They compile identically.

* Behaviour is the same in IDEAL- & PICK-flavoured accounts.

* It doesn't matter if I null out X.
 X = ''
 EXECUTE cmd CAPTURING X

* It doesn't matter if I assign X to an unassigned variable.
 X = Y  ;* (where Y has deliberately never been assigned.)
 EXECUTE cmd CAPTURING X

* My simple case fails at about
1/4 million iterations to fail on my smaller dev system,
1 million on the 2 larger production system.

* The memory leak applies to the session, not the program.
  If I limit the number of iterations in the program,
  but repeatedly execute it from TCL, eventually it fails.
  This fails just the same:

 VOC M.LOOP
 O1 PA
 02 LOOP
 03EXECUTE "RUN CDS.BP M
 04SH -c"ps -lp $$PID"
 05 REPEAT
  where M is limited to 100,000:
 CDS.BP M
 01 FOR I = 1 TO 10
 02EXECUTE "* comment" CAPTURING X
 03 REPEAT

* My old HP PA/risc, HPUX 11.11i, UV 10.0.16 system works fine.


Thank-you in advance,

Charles Stevenson
Getronics
Costa Mesa, CA
714-641-5943 desk
714-396-2771 cell
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

[U2] UV: LOOP;EXECUTE cmd CAPTURING X; REPEAT fatal memory fault.

[Stevenson, Charles]

IBM can't reproduce this.  I'm hoping someone else can.
That didn't come out right.  I don't really want to you have this
problem.  That would be mean.  I just hope this august body can help.

Simplest case:

   CDS.BP M
   01 LOOP
   02   EXECUTE '* anything' CAPTURING X
   03 REPEAT

   >RUN CDS.BP M
   Memory fault(coredump)
   3046$ls -l core
   -rw---   1 cds33896   tech   279499648 Mar 17 17:11 core


This is on HP Itanium, HPUX11.23, UV10.2.6
Anticipating some of your questions:

* If I get rid of CAPTURING X it works fine.

* PERFORM works fine.

* It doesn't matter what the command executed is.  
  I executed a comment ('* anything')above, because what is more benign?

* ps -l shows memory increasing (SZ column) as the process executes.
  (Monitoring it from a 2nd session.)

* EXECUTE "SH -c'[any unix command]'" CAPTURING X
  gets slower & slower each iteration.
  ( Because ever increasing memory is duplicated for child process? )

* Other flavours of the CAPTURING syntax are the same:
EXECUTE cmd CAPTURING X
EXECUTE cmd,OUT>X
EXECUTE cmd,/OUT.>X
  They compile identically.

* Behaviour is the same in IDEAL- & PICK-flavoured accounts.

* It doesn't matter if I null out X.
 X = ''
 EXECUTE cmd CAPTURING X

* It doesn't matter if I assign X to an unassigned variable.
 X = Y  ;* (where Y has deliberately never been assigned.)
 EXECUTE cmd CAPTURING X

* My simple case fails at about 
1/4 million iterations to fail on my smaller dev system, 
1 million on the 2 larger production system.

* The memory leak applies to the session, not the program.
  If I limit the number of iterations in the program, 
  but repeatedly execute it from TCL, eventually it fails.
  This fails just the same:

 VOC M.LOOP
 O1 PA
 02 LOOP
 03EXECUTE "RUN CDS.BP M
 04SH -c"ps -lp $$PID"
 05 REPEAT
  where M is limited to 100,000:   
 CDS.BP M
 01 FOR I = 1 TO 10
 02EXECUTE "* comment" CAPTURING X
 03 REPEAT

* My old HP PA/risc, HPUX 11.11i, UV 10.0.16 system works fine.


Thank-you in advance,

Charles Stevenson
Getronics
Costa Mesa, CA
714-641-5943 desk
714-396-2771 cell
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/