Re: [EXTERNAL] Re: DBI.pm - Memoryfault(coredump)
Please see below with more details; dbh declaration is of perl hash.
my %connection_hash = (); # keep open connections
$connection_hash{$dbname} = DBI->connect( $sid, $user, $pass,
{AutoCommit => $autocommit_flag}); for(keys %connection_hash){
lib_log::debug_msg("Connection hash of $_ is $connection_hash{$_}\n");
}
o/p with Dumper:
2020/11/06 06:32:53 DEBUG > Connection hash of ORAOD is DBI::db=HASH(0x43b3650)
2020/11/06 06:32:53 INFO > $VAR1 = {
'ORAOD' => bless( {}, 'DBI::db' )
};
2020/11/06 06:32:53 DEBUG > Connection established to ORAOD with autocommit = 0
Basically with this perl hash DB Handler, I am getting - Segmentation fault
(core dumped). This program was perfectly working fine until we upgraded
our Linux Server. So perl got upgraded from v5.10.1 to v5.16.3. Then
onwards we started getting core dump errors. I had to spend lots of time to
figure out which code is causing the core dump and then I am here. Then I
have changed the DB Handler without a hash like below and it works fine.
my $dbh = DBI->connect("dbi:$db_driver:$db", $user, $pass, { RaiseError =>
1, AutoCommit => 0 }) or die ("failed to login $db_user");
But for me the challenge is, there are other places where hash is referred
like below and I am trying to find a way how to commit and rollback my
Oracle DB code without hash program.
$connection_hash{$dbname}->commit();
$connection_hash{$dbname}->rollback();
*Regards*
*Srikantha*
*Mb-9980073640*
On Thu, Nov 26, 2020 at 10:41 PM Jared Still wrote:
> These connection strings are not the same.
>
> There really is not much to say about them without code samples that
> include variable definitions.
>
>
>
> On Wed, Oct 28, 2020 at 13:06 Srikantha wrote:
>
>> Hello Fennel & David,
>> Thanks a lot for your response. FInally I could sort out the segmentation
>> fault/Memory dump error after too many rounds of debugging.
>> Basically I can blame it on the Oracle connection but I may be wrong as
>> there are few minor changes(could be on connection_hash too) in the custom
>> perl module which we are using for Oracle connection. I am using the perl
>> module one which is using the 2nd method below and after that I am not
>> finding the Memory core dump error.
>>
>> $connection_hash{$dbname} = DBI->connect( $sid, $user, $pass, {AutoCommit
>> => $autocommit_flag}); -- Not working
>> my $dbh = DBI->connect("dbi:$db_driver:$db", $user, $pass, { RaiseError
>> => 1, AutoCommit => 1 }) or die ("failed to login $db_user"); -- Working
>>
>> *Regards*
>> *Srikantha*
>>
>>
>>
>> On Tue, Oct 27, 2020 at 2:52 AM Fennell, Brian
>> wrote:
>>
>>> I think the following links should cover all the pieces needed for
>>> Perl/JDBC/Oracle
>>>
>>> https://www.oracle.com/database/technologies/appdev/jdbc.html
>>> https://metacpan.org/pod/distribution/DBD-JDBC/JDBC.pod
>>> https://sdkman.io/
>>> Perl can launch the java server using qx:
>>> https://perlmaven.com/qx
>>>
>>>
>>> This is possibly a tangent:
>>> The last time I dug into this I couldn't figure out how to build
>>> DBD::Oracle from source using a Git source (in place of CPAN)
>>> There is very brief mention the cpanm support for git here
>>> https://metacpan.org/pod/distribution/App-cpanminus/bin/cpanm
>>> (search the page for "git" )
>>> There is better documentation (sort of) hidden in the closed issues here
>>> - several uri formats can be used:
>>> https://metacpan.org/pod/distribution/App-cpanminus/bin/cpanm
>>> https://github.com/miyagawa/cpanminus/issues/296
>>>
>>> https://github.com/miyagawa/cpanminus/commit/cf9a72038123a2f721508f17ec8d314cae03245a
>>>
>>> https://github.com/miyagawa/cpanminus/pull/165
>>>
>>> https://github.com/miyagawa/cpanminus/commit/8d82465cc0dde2bd35cd7b454f06f7fba9f205f8
>>>
>>> https://github.com/miyagawa/cpanminus/pull/230
>>>
>>> https://github.com/miyagawa/cpanminus/commit/c588cd7f5fa3fa6c9dcc30d1f4c958c4d45680c1
>>>
>>>
>>> I found two github repos with incidents - the second seems most active
>>> https://github.com/sergadin/dbd-oracle
>>> https://github.com/gitpan/DBD-Oracle
>>>
>>>
>>>
>>> This is also helpful:
>>> https://metacpan.org/pod/DBI#trace
>>> https://metacpan.org/pod/DBI#TRACING
>>>
>>>
>>>
>>>
>>>
>>>
>>> The information contained in this electronic mail transmission is
>>> intended only for the use of the individual or entity named in this
>>> transmission. If you are not the intended recipient of this transmission,
>>> you are hereby notified that any disclosure, copying or distribution of the
>>> contents of this transmission is strictly prohibited and that you should
>>> delete the contents of this transmission from your system immediately. Any
>>> comments or statements contained in this transmission do not necessarily
>>> reflect the views or position of Radial or its subsidiaries and/or
>>> affiliates.
>>>
>>>
>>> --
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist
> Principal Consultant at Pythian
> Oracle ACE Alumni
> Pythian Blog
Re: [EXTERNAL] Re: DBI.pm - Memoryfault(coredump)
These connection strings are not the same.
There really is not much to say about them without code samples that
include variable definitions.
On Wed, Oct 28, 2020 at 13:06 Srikantha wrote:
> Hello Fennel & David,
> Thanks a lot for your response. FInally I could sort out the segmentation
> fault/Memory dump error after too many rounds of debugging.
> Basically I can blame it on the Oracle connection but I may be wrong as
> there are few minor changes(could be on connection_hash too) in the custom
> perl module which we are using for Oracle connection. I am using the perl
> module one which is using the 2nd method below and after that I am not
> finding the Memory core dump error.
>
> $connection_hash{$dbname} = DBI->connect( $sid, $user, $pass, {AutoCommit
> => $autocommit_flag}); -- Not working
> my $dbh = DBI->connect("dbi:$db_driver:$db", $user, $pass, { RaiseError =>
> 1, AutoCommit => 1 }) or die ("failed to login $db_user"); -- Working
>
> *Regards*
> *Srikantha*
>
>
>
> On Tue, Oct 27, 2020 at 2:52 AM Fennell, Brian
> wrote:
>
>> I think the following links should cover all the pieces needed for
>> Perl/JDBC/Oracle
>>
>> https://www.oracle.com/database/technologies/appdev/jdbc.html
>> https://metacpan.org/pod/distribution/DBD-JDBC/JDBC.pod
>> https://sdkman.io/
>> Perl can launch the java server using qx:
>> https://perlmaven.com/qx
>>
>>
>> This is possibly a tangent:
>> The last time I dug into this I couldn't figure out how to build
>> DBD::Oracle from source using a Git source (in place of CPAN)
>> There is very brief mention the cpanm support for git here
>> https://metacpan.org/pod/distribution/App-cpanminus/bin/cpanm
>> (search the page for "git" )
>> There is better documentation (sort of) hidden in the closed issues here
>> - several uri formats can be used:
>> https://metacpan.org/pod/distribution/App-cpanminus/bin/cpanm
>> https://github.com/miyagawa/cpanminus/issues/296
>>
>> https://github.com/miyagawa/cpanminus/commit/cf9a72038123a2f721508f17ec8d314cae03245a
>>
>> https://github.com/miyagawa/cpanminus/pull/165
>>
>> https://github.com/miyagawa/cpanminus/commit/8d82465cc0dde2bd35cd7b454f06f7fba9f205f8
>>
>> https://github.com/miyagawa/cpanminus/pull/230
>>
>> https://github.com/miyagawa/cpanminus/commit/c588cd7f5fa3fa6c9dcc30d1f4c958c4d45680c1
>>
>>
>> I found two github repos with incidents - the second seems most active
>> https://github.com/sergadin/dbd-oracle
>> https://github.com/gitpan/DBD-Oracle
>>
>>
>>
>> This is also helpful:
>> https://metacpan.org/pod/DBI#trace
>> https://metacpan.org/pod/DBI#TRACING
>>
>>
>>
>>
>>
>>
>> The information contained in this electronic mail transmission is
>> intended only for the use of the individual or entity named in this
>> transmission. If you are not the intended recipient of this transmission,
>> you are hereby notified that any disclosure, copying or distribution of the
>> contents of this transmission is strictly prohibited and that you should
>> delete the contents of this transmission from your system immediately. Any
>> comments or statements contained in this transmission do not necessarily
>> reflect the views or position of Radial or its subsidiaries and/or
>> affiliates.
>>
>>
>> --
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Principal Consultant at Pythian
Oracle ACE Alumni
Pythian Blog http://www.pythian.com/blog/author/still/
Github: https://github.com/jkstill
Re: [EXTERNAL] Re: DBI.pm - Memoryfault(coredump)
I forgot to mention, when I print what is there in the hash after
DBI->connect, I see an extra line(see o/p section) is coming up there.
*Regards*
*Srikantha*
*Mb-9980073640*
On Mon, Nov 2, 2020 at 6:49 PM Srikantha wrote:
> Basically below connection_hash is causing a core dump. Can you please
> guide me, how I can rewrite this? In the previous email, the Not working db
> handle is using a hash method and which is what dumps core.
>
> code:
> my %connection_hash = (); # keep open connections
>
>$connection_hash{$dbname} = DBI->connect( $sid, $user, $pass,
{AutoCommit => $autocommit_flag});
> for(keys %connection_hash){
> lib_log::debug_msg("Connection hash of $_ is $connection_hash{$_}\n");
> }
>
> O/p:
>
> 2020/11/02 06:57:25 DEBUG > Connection hash of ORAXX is
> DBI::db=HASH(0x4d463d0)
>
> 2020/11/02 06:57:25 DEBUG > Connection established to ORAXX with
> autocommit = 0
>
> *Regards*
> *Srikantha*
> *Mb-9980073640*
>
>
> On Wed, Oct 28, 2020 at 10:53 PM David Nicol wrote:
>
>>
>> I wonder what the difference between "$sid" and "dbi:$db_driver:$db" is.
>> If nothing, it would look like Oracle::DBD might have some kind of weakness
>> regarding multiple active connections, if the fault happens later instead
>> of right at connect time, like on the second time through, with a different
>> value of $dbname.
>>
>> On Wed, Oct 28, 2020 at 10:06 AM Srikantha wrote:
>>
>>>
>>> $connection_hash{$dbname} = DBI->connect( $sid, $user, $pass,
>>> {AutoCommit => $autocommit_flag}); -- Not working
>>> my $dbh = DBI->connect("dbi:$db_driver:$db", $user, $pass, { RaiseError
>>> => 1, AutoCommit => 1 }) or die ("failed to login $db_user"); -- Working
>>>
>> --
>> If you are neutral in situations of injustice, you have chosen the side
>> of the oppressor." -- Bshp. Desmond Tutu
>>
>
Re: [EXTERNAL] Re: DBI.pm - Memoryfault(coredump)
Basically below connection_hash is causing a core dump. Can you please
guide me, how I can rewrite this? In the previous email, the Not working db
handle is using a hash method and which is what dumps core.
code:
my %connection_hash = (); # keep open connections
for(keys %connection_hash){
lib_log::debug_msg("Connection hash of $_ is $connection_hash{$_}\n");
}
O/p:
2020/11/02 06:57:25 DEBUG > Connection hash of ORAXX is
DBI::db=HASH(0x4d463d0)
2020/11/02 06:57:25 DEBUG > Connection established to ORAXX with autocommit
= 0
*Regards*
*Srikantha*
*Mb-9980073640*
On Wed, Oct 28, 2020 at 10:53 PM David Nicol wrote:
>
> I wonder what the difference between "$sid" and "dbi:$db_driver:$db" is.
> If nothing, it would look like Oracle::DBD might have some kind of weakness
> regarding multiple active connections, if the fault happens later instead
> of right at connect time, like on the second time through, with a different
> value of $dbname.
>
> On Wed, Oct 28, 2020 at 10:06 AM Srikantha wrote:
>
>>
>> $connection_hash{$dbname} = DBI->connect( $sid, $user, $pass, {AutoCommit
>> => $autocommit_flag}); -- Not working
>> my $dbh = DBI->connect("dbi:$db_driver:$db", $user, $pass, { RaiseError
>> => 1, AutoCommit => 1 }) or die ("failed to login $db_user"); -- Working
>>
> --
> If you are neutral in situations of injustice, you have chosen the side of
> the oppressor." -- Bshp. Desmond Tutu
>
Re: [EXTERNAL] Re: DBI.pm - Memoryfault(coredump)
Hello Fennel & David,
Thanks a lot for your response. FInally I could sort out the segmentation
fault/Memory dump error after too many rounds of debugging.
Basically I can blame it on the Oracle connection but I may be wrong as
there are few minor changes(could be on connection_hash too) in the custom
perl module which we are using for Oracle connection. I am using the perl
module one which is using the 2nd method below and after that I am not
finding the Memory core dump error.
$connection_hash{$dbname} = DBI->connect( $sid, $user, $pass, {AutoCommit
=> $autocommit_flag}); -- Not working
my $dbh = DBI->connect("dbi:$db_driver:$db", $user, $pass, { RaiseError =>
1, AutoCommit => 1 }) or die ("failed to login $db_user"); -- Working
*Regards*
*Srikantha*
On Tue, Oct 27, 2020 at 2:52 AM Fennell, Brian wrote:
> I think the following links should cover all the pieces needed for
> Perl/JDBC/Oracle
>
> https://www.oracle.com/database/technologies/appdev/jdbc.html
> https://metacpan.org/pod/distribution/DBD-JDBC/JDBC.pod
> https://sdkman.io/
> Perl can launch the java server using qx:
> https://perlmaven.com/qx
>
>
> This is possibly a tangent:
> The last time I dug into this I couldn't figure out how to build
> DBD::Oracle from source using a Git source (in place of CPAN)
> There is very brief mention the cpanm support for git here
> https://metacpan.org/pod/distribution/App-cpanminus/bin/cpanm
> (search the page for "git" )
> There is better documentation (sort of) hidden in the closed issues here -
> several uri formats can be used:
> https://metacpan.org/pod/distribution/App-cpanminus/bin/cpanm
> https://github.com/miyagawa/cpanminus/issues/296
>
> https://github.com/miyagawa/cpanminus/commit/cf9a72038123a2f721508f17ec8d314cae03245a
>
> https://github.com/miyagawa/cpanminus/pull/165
>
> https://github.com/miyagawa/cpanminus/commit/8d82465cc0dde2bd35cd7b454f06f7fba9f205f8
>
> https://github.com/miyagawa/cpanminus/pull/230
>
> https://github.com/miyagawa/cpanminus/commit/c588cd7f5fa3fa6c9dcc30d1f4c958c4d45680c1
>
>
> I found two github repos with incidents - the second seems most active
> https://github.com/sergadin/dbd-oracle
> https://github.com/gitpan/DBD-Oracle
>
>
>
> This is also helpful:
> https://metacpan.org/pod/DBI#trace
> https://metacpan.org/pod/DBI#TRACING
>
>
>
>
>
>
> The information contained in this electronic mail transmission is intended
> only for the use of the individual or entity named in this transmission. If
> you are not the intended recipient of this transmission, you are hereby
> notified that any disclosure, copying or distribution of the contents of
> this transmission is strictly prohibited and that you should delete the
> contents of this transmission from your system immediately. Any comments or
> statements contained in this transmission do not necessarily reflect the
> views or position of Radial or its subsidiaries and/or affiliates.
>
>
>
Re: [EXTERNAL] Re: DBI.pm - Memoryfault(coredump)
I wonder what the difference between "$sid" and "dbi:$db_driver:$db" is. If
nothing, it would look like Oracle::DBD might have some kind of weakness
regarding multiple active connections, if the fault happens later instead
of right at connect time, like on the second time through, with a different
value of $dbname.
On Wed, Oct 28, 2020 at 10:06 AM Srikantha wrote:
>
> $connection_hash{$dbname} = DBI->connect( $sid, $user, $pass, {AutoCommit
> => $autocommit_flag}); -- Not working
> my $dbh = DBI->connect("dbi:$db_driver:$db", $user, $pass, { RaiseError =>
> 1, AutoCommit => 1 }) or die ("failed to login $db_user"); -- Working
>
--
If you are neutral in situations of injustice, you have chosen the side of
the oppressor." -- Bshp. Desmond Tutu
Re: DBI.pm - Memoryfault(coredump)
On Tuesday, October 27, 2020 1:18:29 PM EDT Bruce Johnson wrote: > Or the client isn’t installed or the environment variables are not > set properly, or, or... > > RHEL, Fedora and CentOS do NOT include DBD::Oracle in their > pre-built perl modules. Like Gary I’ve always had to build it with > CPAN. You need to have an Oracle client setup installed first. > > By far the simplest method is to install the Oracle Instant Client, > (literally download the rpms from Oracle and run yum localinstall > rpmfile.rpm ) you need the base IC and the SDK rpms. > > I usually also install the SQL*Plus package but that is not strictly > necessary. It is, however, very useful for troubleshooting > connectivity. > > Then establish the ORACLE_HOME, LD_LIBRARY_PATH and TNS_ADMIN > Environment variables and appropriate config file for the latter, > then build DBD::Oracle in CPAN. I've never had an issue doing it > that way. > > If you’re using JDBC I think all you need is the base client > install. +1 -- Garry T. Williams
Re: DBI.pm - Memoryfault(coredump)
On Oct 26, 2020, at 7:31 PM, Garry T. Williams mailto:gtwilli...@gmail.com>> wrote: On Monday, October 26, 2020 11:47:54 AM EDT David Nicol wrote: if the Oracle module is maintained by red hat, yum update should help. If you built it in-house, you may need to yum update the perl development environment and reinstall. This is good advice. The original poster also should make sure the Oracle C-API libraries are still installed properly on the client machine. It's impossible to really tell from what the original poster wrote what the code that is running is doing. (The code he posted is a shell script that executes the actual code, which is unknown to us.) But... It probably is DBD::Oracle running under DBI. That is the preferred, simple, and reliable way to access Oracle databases from Perl. There is no need to complicate things with an intermediate Java program. Just use the direct interface to the Oracle C-API -- DBD::Oracle. (I have used Perl DBD::Oracle for over 20 years on many different operating systems and releases with zero problems.) The error the original poster is getting is probably due to the DBD::Oracle module never being updated to the new RHEL release. Fixing it may require recompiling by hand, using CPAN. (I do not know if RHEL has an already-built DBD::Oracle module available from their repositories. I install from CPAN -- that is compile -- in Fedora.) Or the client isn’t installed or the environment variables are not set properly, or, or... RHEL, Fedora and CentOS do NOT include DBD::Oracle in their pre-built perl modules. Like Gary I’ve always had to build it with CPAN. You need to have an Oracle client setup installed first. By far the simplest method is to install the Oracle Instant Client, (literally download the rpms from Oracle and run yum localinstall rpmfile.rpm ) you need the base IC and the SDK rpms. I usually also install the SQL*Plus package but that is not strictly necessary. It is, however, very useful for troubleshooting connectivity. Then establish the ORACLE_HOME, LD_LIBRARY_PATH and TNS_ADMIN Environment variables and appropriate config file for the latter, then build DBD::Oracle in CPAN. I've never had an issue doing it that way. If you’re using JDBC I think all you need is the base client install. -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs
Re: DBI.pm - Memoryfault(coredump)
On Monday, October 26, 2020 11:47:54 AM EDT David Nicol wrote: > if the Oracle module is maintained by red hat, yum update should > help. If you built it in-house, you may need to yum update the perl > development environment and reinstall. This is good advice. The original poster also should make sure the Oracle C-API libraries are still installed properly on the client machine. It's impossible to really tell from what the original poster wrote what the code that is running is doing. (The code he posted is a shell script that executes the actual code, which is unknown to us.) But... It probably is DBD::Oracle running under DBI. That is the preferred, simple, and reliable way to access Oracle databases from Perl. There is no need to complicate things with an intermediate Java program. Just use the direct interface to the Oracle C-API -- DBD::Oracle. (I have used Perl DBD::Oracle for over 20 years on many different operating systems and releases with zero problems.) The error the original poster is getting is probably due to the DBD::Oracle module never being updated to the new RHEL release. Fixing it may require recompiling by hand, using CPAN. (I do not know if RHEL has an already-built DBD::Oracle module available from their repositories. I install from CPAN -- that is compile -- in Fedora.) -- Garry T. Williams
Re: [EXTERNAL] Re: DBI.pm - Memoryfault(coredump)
I think the following links should cover all the pieces needed for Perl/JDBC/Oracle https://www.oracle.com/database/technologies/appdev/jdbc.html https://metacpan.org/pod/distribution/DBD-JDBC/JDBC.pod https://sdkman.io/ Perl can launch the java server using qx: https://perlmaven.com/qx This is possibly a tangent: The last time I dug into this I couldn't figure out how to build DBD::Oracle from source using a Git source (in place of CPAN) There is very brief mention the cpanm support for git here https://metacpan.org/pod/distribution/App-cpanminus/bin/cpanm (search the page for "git" ) There is better documentation (sort of) hidden in the closed issues here - several uri formats can be used: https://metacpan.org/pod/distribution/App-cpanminus/bin/cpanm https://github.com/miyagawa/cpanminus/issues/296 https://github.com/miyagawa/cpanminus/commit/cf9a72038123a2f721508f17ec8d314cae03245a https://github.com/miyagawa/cpanminus/pull/165 https://github.com/miyagawa/cpanminus/commit/8d82465cc0dde2bd35cd7b454f06f7fba9f205f8 https://github.com/miyagawa/cpanminus/pull/230 https://github.com/miyagawa/cpanminus/commit/c588cd7f5fa3fa6c9dcc30d1f4c958c4d45680c1 I found two github repos with incidents - the second seems most active https://github.com/sergadin/dbd-oracle https://github.com/gitpan/DBD-Oracle This is also helpful: https://metacpan.org/pod/DBI#trace https://metacpan.org/pod/DBI#TRACING The information contained in this electronic mail transmission is intended only for the use of the individual or entity named in this transmission. If you are not the intended recipient of this transmission, you are hereby notified that any disclosure, copying or distribution of the contents of this transmission is strictly prohibited and that you should delete the contents of this transmission from your system immediately. Any comments or statements contained in this transmission do not necessarily reflect the views or position of Radial or its subsidiaries and/or affiliates.
Re: [EXTERNAL] Re: DBI.pm - Memoryfault(coredump)
Also consider switching to the JDBC module and using the Oracle JDBC driver. The JDBC driver requires launching a Java server which perl accesses via sockets which is available from CPAN but is not simply a drop in replacement for other DBI / DBD modules. I had to downgrade both perl and Oracle PM in order to get some legacy perl / Oracle working. The "Correct fix" requires rebuilding the Perl/Oracle module from source, an Oracle license, Oracle C Libraries and dot-h files and "sample" makefiles, and lots of time and patience and skill debugging buffer overflows in C (using something like electric fence) and extensive knowledge of Perl internals and Oracle C libraries. The Perl/Oracle module was not being actively maintained the last time I checked. I was not able to invest the time needed. There is a fork of the perl/oracle module (or more than one) on GitHub / GitLab which can be build using cpanm (not cpan) which supports git. I forget the details beyond that. The information contained in this electronic mail transmission is intended only for the use of the individual or entity named in this transmission. If you are not the intended recipient of this transmission, you are hereby notified that any disclosure, copying or distribution of the contents of this transmission is strictly prohibited and that you should delete the contents of this transmission from your system immediately. Any comments or statements contained in this transmission do not necessarily reflect the views or position of Radial or its subsidiaries and/or affiliates.
Re: DBI.pm - Memoryfault(coredump)
if the Oracle module is maintained by red hat, yum update should help. If
you built it in-house, you may need to yum update the perl development
environment and reinstall.
On Fri, Oct 23, 2020 at 11:27 PM Srikantha wrote:
> Hello,
> We are having the below issue from one of the perl modules. We are trying
> to get Oracle query results via this perl package and that package is using
> DBI.pm.
> The perl script is executing end-end but at the end there is a
> segmentation fault error. We have recently upgraded our RHEL version and so
> perl got updated to v5.16.3 from v5.10.1. Below code was working fine
> with the older version. Your help if any will be greatly appreciated.
> if I comment the code lines which is trying to get Oracle query results,
> then there is no Memory fault error. So I am pointing out issue to DBI.pm.
> And DBI version is 1.643.
>
> *Code snippet:*
>
> ${CODE_MOUNT_BASE}/scripts/audits/run_audit_dm_${TABLE}_${DATAMART}.pl
>
> exit_status=$?
>
> echo "exit status after pl call: ${exit_status}"
>
>
>
> *Log message*:
>
> /u01/Projects/audits/scripts/run_audit_dm.ksh: line 12: 2613: Memory
> fault(coredump)
>
> exit status after pl call: 267
>
>
> *Regards*
> *Srikantha*
> *Mb-9980073640*
>
--
"You can be in my dream if I can be in yours." -- Bob Dylan
DBI.pm - Memoryfault(coredump)
Hello,
We are having the below issue from one of the perl modules. We are trying
to get Oracle query results via this perl package and that package is using
DBI.pm.
The perl script is executing end-end but at the end there is a segmentation
fault error. We have recently upgraded our RHEL version and so perl got
updated to v5.16.3 from v5.10.1. Below code was working fine with the older
version. Your help if any will be greatly appreciated.
if I comment the code lines which is trying to get Oracle query results,
then there is no Memory fault error. So I am pointing out issue to DBI.pm.
And DBI version is 1.643.
*Code snippet:*
${CODE_MOUNT_BASE}/scripts/audits/run_audit_dm_${TABLE}_${DATAMART}.pl
exit_status=$?
echo "exit status after pl call: ${exit_status}"
*Log message*:
/u01/Projects/audits/scripts/run_audit_dm.ksh: line 12: 2613: Memory
fault(coredump)
exit status after pl call: 267
*Regards*
*Srikantha*
*Mb-9980073640*
