100 levels deep in subroutine calls!
Hello Everyone, I have a large program that loops through approximately 150 rows of data from an Oracle database using Perl DBI. Within each row of data the program performs further actions like logging on to a different database (Netezza using ODBC driver) to gather further information then writing to yet another database. I am making sure that $sth-finish() and $dbh-disconnect are being used appropriately where necessary. Everything seem to be checking out, but at this very same row of data, I always get a core dump while attempting to logon to the same database to which I was connecting and disconnecting in the previous steps. So I turned on the Perl debug to step through the each row. At the very same row, I get the following error from Perl. DB19 c main::sub_exit(/usr/local/apps/common/devl/bin/GlobalRoutines.pm:551): 551:print STDERR * sub_exit() begins. *\n\n; 100 levels deep in subroutine calls! Is this strictly a Perl debug error message or is this a generic Perl error message? Is there a way around this limitation? I saw something while searching on the Internet about setting the $DB::deep to a higher number. I hope you can shed some light for me. Thanks. Peter
Re: 100 levels deep in subroutine calls!
Hi Peter 100 levels deep in subroutine calls! Is this strictly a Perl debug error message or is this a generic Perl error message? Is there a way around this limitation? I saw something while searching on the Internet about setting the $DB::deep to a higher number. You can easily test this with a little program which does not use DBI. Hence, it's not a DBI, nor a debug, specific problem. I think you'd best assume it's a bug in your code :-). -- Ron Savage [EMAIL PROTECTED]
Re: 100 levels deep in subroutine calls!
On 6/19/07, Ron Savage [EMAIL PROTECTED] wrote:
Hi Peter
100 levels deep in subroutine calls!
Is this strictly a Perl debug error message or is this a generic Perl
error message? Is there a way around this limitation? I saw something
while searching on the Internet about setting the $DB::deep to a higher
number.
You can easily test this with a little program which does not use DBI.
Hence, it's not a DBI, nor a debug, specific problem.
I think you'd best assume it's a bug in your code :-).
Um, maybe not:
DB6 sub deep { print caller() }
DB7deep
main(eval 14)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2
DB8 sub deep { print caller() ; deep()}
DB9 deep();
main(eval 16)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1/perl5db.pl:1521]2main(eval
15)[/opt/perl/lib/5.6.1
Re: FW: Re: 100 levels deep in subroutine calls!
On Fri, Jun 15, 2001 at 02:56:49PM -0500, Scott T. Hildreth wrote: I just wanted know where or why the recursive call was comming from, he is not making recursive calls, I checked that right away. Anyway, my quess is when he is done cleaning up the code the errors will disappearI hope :) After he gets the 100 levels deep in subroutine calls in the Perl debugger, he should use the T command to view the call stack. Ronald
Re: 100 levels deep in subroutine calls!
On Fri, 15 Jun 2001 14:20:28 -0500 (CDT), Scott T. Hildreth [EMAIL PROTECTED] wrote: It appears that you are attempting to enter data to a column that has possible reached it's max size. What type of column type is the duplicate entry referring too?? Sorry I should have mentioned that I did Trace it, I traced one of the Statement Handles as well as the Db Handle, it shows the Duplicate Error being returned but nothing else, ERROR EVENT 5 'Duplicate entry '2067258104' for key 1' on DBI::st=HASH(0x14037fa50) Duplicate entry '2067258104' for key 1 error 5 recorded: Duplicate entry '2067258104' for key 1 - dbd_st_execute -2 rows !! ERROR: 5 'Duplicate entry '2067258104' for key 1' - execute= undef at qwl_newcust.pl line 374. - DESTROY for DBD::mysql::st (DBI::st=HASH(0x14037fa50)~INNER) - DESTROY= undef during global destruction. ..the dups are there, that is why we catch with a eval. The $dbh trace shows the same thing, Mike(mickalo)Blezien Thunder Rain Internet Publishing Providing Internet Solutions that work! http://www.thunder-rain.com Tel: 1(225) 686-2002 =
RE: 100 levels deep in subroutine calls!
This is kind of a cop out, but I think you'd be better off fixing your
database to match what your program expects than to change your program to
deal with incomplete data in the database. Or you could just check if
things exist before inserting them. I think you are getting into some messy
stuff with recursion and eval that you could avoid. I'd be really
suspicious of the subroutine that this is happening in. It doesn't call
itself, does it?
Mitch
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Scott T. Hildreth
Sent: Friday, June 15, 2001 2:20 PM
To: Sterin, Ilya
Cc: [EMAIL PROTECTED]
Subject: RE: 100 levels deep in subroutine calls!
Sorry I should have mentioned that I did Trace it,
I traced one of the Statement Handles as well as the
Db Handle, it shows the Duplicate Error being returned
but nothing else,
ERROR EVENT 5 'Duplicate entry '2067258104' for key 1' on
DBI::st=HASH(0x14037fa50)
Duplicate entry '2067258104' for key 1 error 5 recorded:
Duplicate entry
'2067258104' for key 1
- dbd_st_execute -2 rows
!! ERROR: 5 'Duplicate entry '2067258104' for key 1'
- execute= undef at qwl_newcust.pl line 374.
- DESTROY for DBD::mysql::st (DBI::st=HASH(0x14037fa50)~INNER)
- DESTROY= undef during global destruction.
..the dups are there, that is why we catch with a eval.
The $dbh trace shows the same thing,
Duplicate entry '2084592512' for key 1 error 5 recorded:
Duplicate entry
'2084592512' for key 1
- dbd_st_execute -2 rows
!! ERROR: 5 'Duplicate entry '2084592512' for key 1'
- execute= undef at qwl_newcust.pl line 424.
- DESTROY for DBD::mysql::st (DBI::st=HASH(0x14035fa90)~INNER)
- DESTROY= undef during global destruction.
- DESTROY for DBD::mysql::st (DBI::st=HASH(0x140379b00)~INNER)
- DESTROY= undef during global destruction.
- DESTROY for DBD::mysql::db (DBI::db=HASH(0x14035fa30)~INNER)
Rollback ineffective while AutoCommit is on error 15
recorded: Rollback
ineffective while AutoCommit is on
imp_dbh-svsock: 14030e350
- DESTROY= undef during global destruction.
..I don't think it is DBI, because the Trace coninue to show the dup
errors for each record, then they call the DESTROY, and the other
error(100 levels deep in subroutine calls!) comes up.
On 15-Jun-01 Sterin, Ilya wrote:
Well depending on why it is failing. You error message
does not provide any
help. Try using $DBI::errstr in it and also use trace() at
level 2 (see
docs). You can then submit both to us if you can't figure
out yourself.
Ilya
-Original Message-
From: Scott T. Hildreth
To: [EMAIL PROTECTED]
Sent: 06/15/2001 12:50 PM
Subject: 100 levels deep in subroutine calls!
I'm helping a co-worker debug some code, and I can't figure out
what is going on. I hope someone can shed some light on it.
This is perl, version 5.005_02 built for alpha-dec_osf
DBI 1.14
Msql-Mysql-modules-1.2217.tar.gz
Basically, He calls a subroutine that evals the execute
and checks $@. He keeps rerunning in debugger so there
are duplicate keys that were already inserted. So he uses
the eval to skip those errors. It actuall quits in multiple
subroutines. I commented out the eval in one subroutine and
added $dbh-{RaiseError} = 0, and it did not quit in this sub,
but it did quit in another sub with,
main::update_newcust(qwl_newcust.pl:430):
430:if ($@) {
100 levels deep in subroutine calls!
Anybody know what I am missing here???
--
E-Mail: Scott T. Hildreth [EMAIL PROTECTED]
Date: 15-Jun-01
Time: 13:33:13
--
--
E-Mail: Scott T. Hildreth [EMAIL PROTECTED]
Date: 15-Jun-01
Time: 14:12:07
--
FW: Re: 100 levels deep in subroutine calls!
It is updating data, the duplicates come from running again. Will get so far then it dies. When I took out the eval from the one function, it stopped dieing there. He has numerous code changes/fixes to make. He was reusing a global $sth for every handle, preparing everytime in a loop...etc. I have him changing all the code. I just wanted know where or why the recursive call was comming from, he is not making recursive calls, I checked that right away. Anyway, my quess is when he is done cleaning up the code the errors will disappearI hope :) Thanks, STH On 15-Jun-01 MikemickaloBlezien wrote: On Fri, 15 Jun 2001 14:20:28 -0500 (CDT), Scott T. Hildreth [EMAIL PROTECTED] wrote: It appears that you are attempting to enter data to a column that has possible reached it's max size. What type of column type is the duplicate entry referring too?? Sorry I should have mentioned that I did Trace it, I traced one of the Statement Handles as well as the Db Handle, it shows the Duplicate Error being returned but nothing else, ERROR EVENT 5 'Duplicate entry '2067258104' for key 1' on DBI::st=HASH(0x14037fa50) Duplicate entry '2067258104' for key 1 error 5 recorded: Duplicate entry '2067258104' for key 1 - dbd_st_execute -2 rows !! ERROR: 5 'Duplicate entry '2067258104' for key 1' - execute= undef at qwl_newcust.pl line 374. - DESTROY for DBD::mysql::st (DBI::st=HASH(0x14037fa50)~INNER) - DESTROY= undef during global destruction. ..the dups are there, that is why we catch with a eval. The $dbh trace shows the same thing, Mike(mickalo)Blezien Thunder Rain Internet Publishing Providing Internet Solutions that work! http://www.thunder-rain.com Tel: 1(225) 686-2002 = -- E-Mail: Scott T. Hildreth [EMAIL PROTECTED] Date: 15-Jun-01 Time: 14:42:22 -- --End of forwarded message- -- E-Mail: Scott T. Hildreth [EMAIL PROTECTED] Date: 15-Jun-01 Time: 14:53:14 --
