Perl 5.8.6 on HP-UX 11.11 with DBD::ORACLE 1.17 and Oracle 10g DB server

[HPP]

Hi,
I have installed perl 5.8.6 (64bit) on HP-UX 11.11, with June 2006 HP-UX patches. I download perl5.8.6 from merijin's website. i am using gcc64 3.4.3 to compile DBD::Oracle against Oracle 10g version 2 (10.2.0) client/server. DBD::Oracle compile (make test) was successful.

Whenever in the perl script if i have Oracle database connection (database is on remote server, and running Oracle 10g) and then do a HTTP/HTTPS GET or POST anywhere after DB connection i get MemoryFault core dump. If i do HTTP/HTTPS GET or POST request before database connection then my HTTP request is successful.


I tried Openssl 0.9.7i from HP and recompiled Crypt-SSLeay and LibWWW with no luck.

Here is simple perl code i mentioned about:

#!/usr/local/perl64/bin/perl


# Create a user agent object
use LWP;
use DBI;
use LWP::UserAgent;
use HTTP::Request;
use HTTP::Request::Common qw(POST);
use HTTP::Request::Common;
use HTTP::Headers;
$ua = LWP::UserAgent->new;
$ua->agent("MyApp/0.1 ");

my $dbh = db_connect(proddb,trans88,trans188);

my $req = $ua->get('https://172.16.16.95/weekly');
@trans_array=$req->content;
print "@trans_array \n";

sub db_connect {
my ($database,$user,$password) = @_;
my $h = DBI->connect("DBI:Oracle:$database", $user, $password)
or db_err("Unable to connect to $database", $DBI::errstr);
return $h;
}


The same code works with Perl 5.8.1 and Oracle 8i client and Oracle Database server 10g. Perl 5.8.1 which was again downloaded from merijin's website.

Any idea whats wrong?

any help would be of great help.

Thanks in Advance.

[HPP]

I did not see any reply. Anbody has any clue about the issue mentioned above.

Thanks in advance.

[Steven E. Protter]

Shalom,

Not that this will help so much, but are you sure you are using the right version of perl in your scripts.

The perl location unless you created a softlink or some other mechanism is not to a known version of perm.

perl -v and make sure you are using the right version.

Also, why not run your code in debug mode. This might make the problem apparent to you.

SEP
Back in Israel.

[HPP]

Thanks SEP for the reply.

I am using the right perl. I checked the PATH and it looks good.

I have been trying all different versions of PERL with DBI and DBD with no luck. Here are couple of observations.

With perl 5.8.6 (from merijin's website), compiled DBI and DBD with gcc64 3.4.3, i did strings on core file ("strings core") and it gives

netgroup.byuser
netgroup.byhost
passwd.adjunct.byname
passwd.adjunct.byname
Ue`root


With perl 5.8.8 (from HP website), compiled DBI and DBD with HP ANSI C, still i get memory fault core dump. I did strings on core file and i get

0_64
nis.1
>!P;

Both case it is pointing to NIS.

I am using perl64 for the both the above case.

I am not a programmer. I am just trying figure what the problem might be.

Is there anything which i am missing?

Thanks in advance.

[H.Merijn Brand (procura]

1. Why 5.8.6 and not 5.8.8?
Notthat I know of any bug being fixed in this area, but it might make tracking it down easier.

2. Is it in any way possible to tighten the bug, like using a local dtabase, instead of a remote one, and/or eliminating the need fir NIS.

3. If you downloaded my gcc, you also have gdb. If not, you can install it from the application CD/DVD (wildebeast debugger)
Use it to show the stack trace of the core dumos

4. Check SUM for available patches regarding NIS, and check if the most recent gold pack has been installed.

Enjoy, Have FUN! H.Merijn

[Ralph Grothe]

I'm not sure if this would alleviate your memory problems with the code.
Although I think to have read somewhere that a base DESTROY method is called whenever an object ref gets out of scope automatically by Perl's garbage collector to free up resources this may not work under all circumstances.
Therefore I would suggest to be explicit and call DBI's finish() method on each statement handle that you no longer need to reference, and the disconnect() method on your database handle when you nolonger need the database connection.
Also I am sure there are several remarks in the PODs of DBD::Oracle and DBI about caveats with memory management.

As for SSL support of your LWP
there is a method of LWP::UserAgent which let's you check your installation.
e.g.

$ perl -MLWP -le 'print LWP::UserAgent->new->is_protocol_supported("https")'
1

Usually Crypt::SSLeay should integrate seamlessly with LWP.
The only thing you need to do to activate it is to change the scheme of your requested uri from http to https, and usually the queried server's SSL listening port (provided the webserver is servicing at a TLS at all).

[HPP]

Thanks for the reply.

I forgot to one more thing, that is when i do "file core" the ouput looks like this

core: ELF-64 core file - PA-RISC 2.0 from 'test1.pl' - received SIGSEGV


I have tried perl 5.8.6 on server where 10g database server is installed, the result is core dump.

I tried this command "/opt/pa20_64/bin/gdb /opt/perl64/bin/perl core", this gives me core dump. Am i right regarding gdb syntax. strings for this core gives

>!P;
>!P;
>!P;
>!P;

I used "/opt/langtools/bin/gdb /opt/perl64/bin/perl core". Here is the output for "where"

# gdb /opt/perl64/bin/perl core
Detected 64-bit executable.
Invoking /opt/langtools/bin/gdb64.
HP gdb 5.4.0 for PA-RISC 2.0 (wide), HP-UX 11.00
and target hppa2.0w-hp-hpux11.00.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.4.0 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
Core was generated by `test1.pl'.
Program terminated with signal 11, Segmentation fault.
SEGV_UNKNOWN - Unknown Error

warning: Load module /ora10g/10.2.0/lib/libclntsh.sl.10.1 has been stripped.
Debugging information is not available.


warning: Load module /ora10g/10.2.0/lib/libnnz10.sl has been stripped.
Debugging information is not available.

#0 0xc00000000042db8c in + 0x800001f () from /ora10g/10.2.0/lib/libnnz10.sl
(gdb) what
The history is empty.
(gdb) where
#0 0xc00000000042db8c in + 0x800001f () from /ora10g/10.2.0/lib/libnnz10.sl
#1 0xc0000000004142f8 in + 0x800001f () from /ora10g/10.2.0/lib/libnnz10.sl
#2 0xc000000000901230 in BN_mod_exp_mont+0x4b8 () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#3 0xc000000000911974 in RSA_eay_public_decrypt+0x2f4 () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#4 0xc0000000008bad24 in RSA_public_decrypt+0x24 () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#5 0xc0000000008bb724 in RSA_verify+0x17c () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#6 0xc00000000089b3f0 in ssl3_get_key_exchange+0x9f0 () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#7 0xc00000000089888c in ssl3_connect+0x144 () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#8 0xc0000000008a7e7c in SSL_connect+0xdc () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#9 0xc0000000008a2fa8 in ssl23_get_server_hello+0x2b8 () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#10 0xc0000000008a2a8c in ssl23_connect+0x3fc () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#11 0xc0000000008a7e7c in SSL_connect+0xdc () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#12 0xc000000000890ff8 in XS_Crypt__SSLeay__Conn_connect (cv=0x7ffffffd008c9c00) at SSLeay.c:501
#13 0x40000000000c7570 in Perl_pp_entersub () at pp_hot.c:2926
#14 0x40000000000a5dd4 in Perl_runops_debug () at dump.c:1449
#15 0x4000000000048198 in S_run_body (oldscope=85736) at perl.c:1937
#16 0x4000000000047bb4 in perl_run (my_perl=0x7ffffffd008c9c00) at perl.c:1858
#17 0x4000000000042c5c in main (argc=4, argv=0x3, env=0x1000000010) at perlmain.c:98
(gdb)



Right now i am looking at patch list for NIS and it came from June 2006 support plus CD, The patch i see installed is PHNE_33498.


Output of
perl -MLWP -le 'print LWP::UserAgent->new->is_protocol_supported("https")'
1

[H.Merijn Brand (procura]

Would you be able to re-install Crypt::SSLeay from scratch please?

I fear that that layer might be the troublemaker.

# cd /tmp
# wget http://search.cpan.org/CPAN/authors/id/C/CH/CHAMAS/Crypt-SSLeay-0.51.tar.gz
# gzip -d # cd Crypt-SSLeay-0.51
# opt/perl64/bin/perl Makefile.PL
# make test
# make install UNINST=1

Doing the same for IO-Socket-SSL ( http://search.cpan.org/CPAN/authors/id/S/SU/SULLR/IO-Socket-SSL-1.01.tar.gz ) might be helpfull too, but I don't thing Crypt::SSLeay uses it

Enjoy, Have FUN! H.Merijn

[HPP]

Procura,
Thanks for the reply.

I reinstalled Crypt-SSLeay and IO-Socket-SSL and still get core dump. Here is the gdb output.

# gdb /opt/perl64/bin/perl core
Detected 64-bit executable.
Invoking /opt/langtools/bin/gdb64.
HP gdb 5.4.0 for PA-RISC 2.0 (wide), HP-UX 11.00
and target hppa2.0w-hp-hpux11.00.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.4.0 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
Core was generated by `test1.pl'.
Program terminated with signal 11, Segmentation fault.
SEGV_UNKNOWN - Unknown Error

warning: Load module /ora10g/10.2.0/lib/libclntsh.sl.10.1 has been stripped.
Debugging information is not available.


warning: Load module /ora10g/10.2.0/lib/libnnz10.sl has been stripped.
Debugging information is not available.

#0 0xc00000000042db8c in + 0x800001f () from /ora10g/10.2.0/lib/libnnz10.sl
(gdb) where
#0 0xc00000000042db8c in + 0x800001f () from /ora10g/10.2.0/lib/libnnz10.sl
#1 0xc0000000004142f8 in + 0x800001f () from /ora10g/10.2.0/lib/libnnz10.sl
#2 0xc000000000b01228 in BN_mod_exp_mont+0x4b8 () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#3 0xc000000000b1196c in RSA_eay_public_decrypt+0x2f4 () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#4 0xc000000000abad1c in RSA_public_decrypt+0x24 () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#5 0xc000000000abb71c in RSA_verify+0x17c () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#6 0xc000000000a9b3e8 in ssl3_get_key_exchange+0x9f0 () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#7 0xc000000000a98884 in ssl3_connect+0x144 () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#8 0xc000000000aa7e74 in SSL_connect+0xdc () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#9 0xc000000000aa2fa0 in ssl23_get_server_hello+0x2b8 () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#10 0xc000000000aa2a84 in ssl23_connect+0x3fc () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#11 0xc000000000aa7e74 in SSL_connect+0xdc () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#12 0xc000000000a90ff0 in XS_Crypt__SSLeay__Conn_connect () at SSLeay.c:500
#13 0x40000000000c7570 in Perl_pp_entersub () at pp_hot.c:2926
#14 0x40000000000a5dd4 in Perl_runops_debug () at dump.c:1449
#15 0x4000000000048198 in S_run_body (oldscope=85736) at perl.c:1937
#16 0x4000000000047bb4 in perl_run (my_perl=0x7ffffffd008c9b78) at perl.c:1858
#17 0x4000000000042c5c in main (argc=4, argv=0x3, env=0x1000000010) at perlmain.c:98

[H.Merijn Brand (procura · Accepted solution]

I think this is a name conflict. I tend to blame Oracle, but that would be unfair, as I blame Oracle for most IT problems here on the forum :)

If you look at these two lines:

#1 0xc0000000004142f8 in + 0x800001f () from /ora10g/10.2.0/lib/libnnz10.sl
#2 0xc000000000b01228 in BN_mod_exp_mont+0x4b8 () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl
#3 0xc000000000b1196c in RSA_eay_public_decrypt+0x2f4 () from /opt/perl64/lib/site_perl/5.8.6/PA-RISC2.0-LP64/auto/Crypt/SSLeay/SSLeay.sl

you see that BN_mod_exp_mont () from SSLeay calls a function that is not supposed to be in libnnzl0.sl

This is a touch nut to crack.
My first try would be to move libnnzl0.sl out of the way, and see if this part succeeds, or if it is really needed. If all works fine, leave it out of the way until someone else complains, and then make it his/her problem :)

If not, the next step is to find the conflicting function name.
For this, use the 'nm' command to generate a symbol list for both libraries, and then find the name that is undef in SSLeay.sl and defined in libnnzl0.sl

If you find it, it's up to your adventuras mind how to `fix' it.
Some suggestions:
1. Find a way to have the `correct' lib load before this Oracle cruft
2. Rename the func in the Oracle lib with a binary editor
3. Find the lib needed for SSLeay and load the .a instead of the .sl, so you get it linked in, and it won't look for the shared version.
4. Switch from Oracle to Postgres (or MySQL, or MonetDB, or ... as long as it is not Oracle)
5. Call Oracle support and tell them they suck (they know that, but they will deny). Then tell them where they fucked up, and if they do not fix it in three days, you will tell the world.
6. Use your imagination

Enjoy, Have FUN! H.Merijn