Re: [U2] Unidata 7.1.22/AIX - Stack overflow

2013-08-10 Thread Kevin King 
Wol,
MM -E is the greatest debugging tool in the SB+ arsenal (IMO, of course)
and it's not really even an SB+ feature, it's a Unidata thing.  It allows
you to start the SB+ main menu (MM) with the Unidata -E (drop to debug on
error) option.  When there's a problem, unassigned variable, divide by
zero, etc., Unidata usually doesn't stop and it doesn't tell you where the
problem is.  With this, you drop in the debugger on the exact line.  Works
brilliantly for tracing through these big nests of OPM (other people's
messes).


On Sat, Aug 10, 2013 at 4:16 PM, Anthonys Lists wrote:

> On 10/08/2013 21:12, Kevin King wrote:
>
>> We have a customer that has a program (and associated subroutines) that
>> has
>> not been modified in a good long while.  Just this past week it started
>> blowing up with a memory failure and segfault at different times in the
>> process.  Unidata was recently restarted.
>>
>
> Did it start happening at the same time as Unidata was restarted? I
> suspect you don't actually know.
>
>
>> I'm suspecting that some bit of code in this quagmire is doing some GOSUBs
>> and not unravelling the stack, and eventually it's just running out of
>> stack space.  But ... how can I prove this without stepping through the
>> code line by line?  Is there something in the Unidata debugger that shows
>> the GOSUB stack?
>>
>> I've tried running this through the MM -E trick (this is a SB+ app, btw)
>> and it never drops in the debugger when this happens, the process just
>> terminates and returns to AIX.  So I'm a little uncertain as to how to go
>> about figuring this one out.
>>
>
> Not knowing what MM -E is, I don't know what this is supposed to do, but
> surely a basic stack overflow should not crash Unidata itself?
>
> The first thing  I'd be inclined to rule out is a hardware failure of some
> sort. Can you run a memory test?
>
>>
>> Any ideas?
>>
>>  Just my tuppence worth - if it's worth even that ... :-)
>
> Cheers,
> Wol
> __**_
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/**mailman/listinfo/u2-users
>
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Unidata 7.1.22/AIX - Stack overflow

2013-08-10 Thread Kevin King 
Thank you for the insight.  The program in question is entirely BASIC.  It
is a subroutine called from an SB+ paragraph that then calls other
subroutines to do the heavy lifting.  So while it's called from SB+, it
doesn't use anything in SB+, it's just some vendor-written subroutines
calling other vendor-written subroutines.   We have the source for it, but
was hoping we could find a way to debug it as it's a massive number of
lines across an equally massive number of routines, running against a
pretty significant list of records across an equally impressive number of
files.

At the time this started happening, Unidata had been running for about six
months without a restart.  Restarting Unidata didn't change the outcome of
this program, it still aborts randomly, which leads me to think that there
has been some change in the data that is causing this vendor code to
misbehave, but without single-stepping through the code (which literally
could take months) I was just wondering if there's anything in the debugger
that would tell me how many un-returned GOSUBS have been hit?  This site
uses work order assemblies in this particular vendor product and I'm
wondering if there's a loop in the bill of materials somewhere that's
basically exhausting memory, but there just isn't time to single-step
through the code to try to find that without some trickery or magic to help
the process along.

-K


On Sat, Aug 10, 2013 at 5:23 PM, John Jenkins  wrote:

> Kevin,
>
> Could someone be constantly using /process_name to constantly jump around
> the system? If so, the. One of the SB files will build up a history (not
> recalling which one off the top of my head) . Look for a massive increase
> build up of records which will point to a culprit user or process.
>
> SB code - unless you code your own subroutines or generate code /GC - are
> interpreted.
>
> Otherwise I recommend checking files and indexes for corruption. BASIC
> catalog used can become corrupt just like any other data, it's incredibly
> rare though.
>
> Regards
>
> JayJay
>
>
>
> On 10 Aug 2013, at 21:12, Kevin King  wrote:
>
> > We have a customer that has a program (and associated subroutines) that
> has
> > not been modified in a good long while.  Just this past week it started
> > blowing up with a memory failure and segfault at different times in the
> > process.  Unidata was recently restarted.
> >
> > I'm suspecting that some bit of code in this quagmire is doing some
> GOSUBs
> > and not unravelling the stack, and eventually it's just running out of
> > stack space.  But ... how can I prove this without stepping through the
> > code line by line?  Is there something in the Unidata debugger that shows
> > the GOSUB stack?
> >
> > I've tried running this through the MM -E trick (this is a SB+ app, btw)
> > and it never drops in the debugger when this happens, the process just
> > terminates and returns to AIX.  So I'm a little uncertain as to how to go
> > about figuring this one out.
> >
> > Any ideas?
> > ___
> > U2-Users mailing list
> > U2-Users@listserver.u2ug.org
> > http://listserver.u2ug.org/mailman/listinfo/u2-users
>
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Unidata 7.1.22/AIX - Stack overflow

2013-08-10 Thread John Jenkins 
Kevin,

Could someone be constantly using /process_name to constantly jump around the 
system? If so, the. One of the SB files will build up a history (not recalling 
which one off the top of my head) . Look for a massive increase build up of 
records which will point to a culprit user or process. 

SB code - unless you code your own subroutines or generate code /GC - are 
interpreted.

Otherwise I recommend checking files and indexes for corruption. BASIC catalog 
used can become corrupt just like any other data, it's incredibly rare though.

Regards

JayJay



On 10 Aug 2013, at 21:12, Kevin King  wrote:

> We have a customer that has a program (and associated subroutines) that has
> not been modified in a good long while.  Just this past week it started
> blowing up with a memory failure and segfault at different times in the
> process.  Unidata was recently restarted.
> 
> I'm suspecting that some bit of code in this quagmire is doing some GOSUBs
> and not unravelling the stack, and eventually it's just running out of
> stack space.  But ... how can I prove this without stepping through the
> code line by line?  Is there something in the Unidata debugger that shows
> the GOSUB stack?
> 
> I've tried running this through the MM -E trick (this is a SB+ app, btw)
> and it never drops in the debugger when this happens, the process just
> terminates and returns to AIX.  So I'm a little uncertain as to how to go
> about figuring this one out.
> 
> Any ideas?
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Unidata 7.1.22/AIX - Stack overflow

2013-08-10 Thread Anthonys Lists 

On 10/08/2013 21:12, Kevin King wrote:

We have a customer that has a program (and associated subroutines) that has
not been modified in a good long while.  Just this past week it started
blowing up with a memory failure and segfault at different times in the
process.  Unidata was recently restarted.


Did it start happening at the same time as Unidata was restarted? I 
suspect you don't actually know.


I'm suspecting that some bit of code in this quagmire is doing some GOSUBs
and not unravelling the stack, and eventually it's just running out of
stack space.  But ... how can I prove this without stepping through the
code line by line?  Is there something in the Unidata debugger that shows
the GOSUB stack?

I've tried running this through the MM -E trick (this is a SB+ app, btw)
and it never drops in the debugger when this happens, the process just
terminates and returns to AIX.  So I'm a little uncertain as to how to go
about figuring this one out.


Not knowing what MM -E is, I don't know what this is supposed to do, but 
surely a basic stack overflow should not crash Unidata itself?


The first thing  I'd be inclined to rule out is a hardware failure of 
some sort. Can you run a memory test?


Any ideas?


Just my tuppence worth - if it's worth even that ... :-)

Cheers,
Wol
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

[U2] Unidata 7.1.22/AIX - Stack overflow

2013-08-10 Thread Kevin King 
We have a customer that has a program (and associated subroutines) that has
not been modified in a good long while.  Just this past week it started
blowing up with a memory failure and segfault at different times in the
process.  Unidata was recently restarted.

I'm suspecting that some bit of code in this quagmire is doing some GOSUBs
and not unravelling the stack, and eventually it's just running out of
stack space.  But ... how can I prove this without stepping through the
code line by line?  Is there something in the Unidata debugger that shows
the GOSUB stack?

I've tried running this through the MM -E trick (this is a SB+ app, btw)
and it never drops in the debugger when this happens, the process just
terminates and returns to AIX.  So I'm a little uncertain as to how to go
about figuring this one out.

Any ideas?
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users