Re: [EXTERNAL] Re: DBI.pm - Memoryfault(coredump)

2020-11-30 Thread Srikantha
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)

2020-11-26 Thread Jared Still
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)

2020-11-02 Thread Srikantha
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)

2020-11-02 Thread Srikantha
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)

2020-10-28 Thread Srikantha
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)

2020-10-28 Thread David Nicol
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)

2020-10-26 Thread Fennell, Brian
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)

2020-10-26 Thread Fennell, Brian
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.