[Omaha.pm] RE: Perl - Trace

["Jay Hannah" <jhannah@omnihotels.com>]

I'm not aware of any dead-easy way to isolate the issue without understanding the Perl programs and what they do. How long are TXKScript.pl and txkVal11510MP.pl (how many lines)?

You could try running under the debugger -- usually anything fatal throws a stack trace. 

perl -d $ORACLE_HOME/appsutil/bin/TXKScript.pl \
   etc...

Then type "c" enter to tell the debugger to "continue" until it dies...

Is the program dumping core? If so and you're brave enough to use gdb check out the stuff I Google'd for you at the bottom of this post. (I'm no C programmer...)

HTH,

j



> -----Original Message-----
> From: Nancy Iles
> Sent: Monday, December 20, 2004 3:30 PM
> To: jhannah@omnihotels.com
> Subject: Perl - Trace
> 
> Jay,
> 
> I understand that you are the perl guru. I have an perl 
> script provided by oracle that I need to run to validate the 
> Oracle tech stack. When it runs on ifs-data, I receive an 
> 'Out of Memory' error and it terminates. No logs are being 
> generated so I have no clue as to what is wrong. I have an 
> issue open with Oracle but it has not made any progress yet. 
> The script is:
> 
> $ perl $ORACLE_HOME/appsutil/bin/TXKScript.pl \
> 
>    -script=$ORACLE_HOME/appsutil/bin/txkVal11510MP.pl \
> 
>    -txktop=$ORACLE_HOME/appsutil \
> 
>    -contextfile= $CONTEXT_FILE \
> 
>    -appspass=<apps_password> \
> 
>    -outfile=$ORACLE_HOME/appsutil/temp/txkVal11510MP_DB.html
> 
> Is there a way to trace the execution to find out where it is 
> generating the 'Out of Memory' error? 
> 
> Thanks! 
> 



>From USENET:

So, here's what I would suggest:


1. Use a debugger. My examples are for gdb, as this lives on more
  platforms than most (all?) other debuggers.


2. Using said debugger, get a stack trace of the core dump:


        gdb /usr/bin/perl        # This tells gdb to look at the perl
                                #        executable. Looking at your script
                                #        would do gdb no good.


  typed into gdb:


        core core                # Tell gdb to read in the core file
        bt                        # Get a stack-trace of what functions
                                #        had been called.


3. Using this information, you can look at the source code and try to
  figure out what might have happened to cause the last function
  called to crap out. If you want, you can look at the source from
  within gdb by typing:


        frame <#>                # Where <#> is the number that was
                                #        printed before the function name in
                                #        the stack-listing (see above).
        dir <perl-source-dir>        # Where <perl-source-dir> is where the
                                #        source-code to perl lives.
        list                        # This prints out the code around the
                                #        line from the stack-trace.


4. You can look at the values of any variables at the time of the
  crash, by typing:


        p <variable-name>        # <variable-name> may also be any (or
                                #        almost any) valid C expresion.
                                #       ex.: p (foo + 2) - bar


5. If none of this helps, post a message that includes the
  stack-trace, any relevant details, and the output of:


        perl -v                        # Version of perl
        uname -a                # Machine/OS type/revision info