DBD::Oracle causes core dumps

[Markus Bonet]

Hi!

I using Perl 5.6.1, DBI-1.22, DBD::Oracle, Oracle 8.0.0.3 on a HP-UX 11.00 machine.

I got lot of trouble compiling and installing all of them.

Now all compiles well, but testing and using the DBD::Oracle driver ends in core-dumps.

Is this forum correct for my problem?
If so, I can post more details on this problem.


Thanks, Markus

[Steve Steel]

Hi

This will do

Please give all info you have.

especially messages

If a corefile is created run
file core

Steve Steel

[Steve Steel]

Hi

look at

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x3e777d4cf554d611abdb0090277a778c,00.html

You will see that SIGSEGV is caused bu maxssiz
or the 64 bit equivalent being too small.

Follow the URL above and tune your system values upwards.


Steve Steel

[H.Merijn Brand (procura]

Aside the core dumps, I see some other things you might consider to change or redo

The perl you are using is built with gcc-2.95 for hppa-1.1 architecture (32bit). If you want some performance gain and you do not have HP ANSI C, consider upgrading to gcc-3.0.4 or gcc-3.1 The GNU people have gone through great trouble to improve gcc for HP-UX. gcc-3.0.4 is available for 11.00 on http://hpux.tn.tudelft.nl/hppd/hpux/Gnu/alpha.html (amongst other fine HP mirrors) and you can also find binutils-2.12 there.

DBI-1.22 is very new (only a few days) and the only addition is a bulk interface. DBI-1.21 would have been sufficient.

This perl (32bit) cannot be used with 64bit Oracle, but I guess that is not the problem.

Good luck, and happy perl hacking

[Markus Bonet]

OK,

I checked maxssiz:

Parameter: maxssiz
Value: 0x00800000
Default: 0x00800000
Minimum: -
Module: -


There isn't a maxssiz_64 value, because our system is 32bit only.

From the suggested thread I am not sure what value to set.


Sorry, but I am not too sure with this system.
Any hints are valueable for me...
Markus

[Steve Steel]

Hi

There is a document attached to the last part of the url I gave you with good info and indeed the default is too small.

maxssiz maxdsiz maxtsiz are indicators of the maximum memory which can be used.


Would recommend

1)Look at the attached document.

2)Make sure you have at least 1.5*default for these values.

Remember that you must reboot to change but you can use kmtune to upgrade the values online to test

see man kmtune


Steve Steel

[Markus Bonet]

OK,

first of all many thanks for helping.
I will try reconfiguring this machine in the afternoon.

BTW, this is a K360 with 1GB RAM.
The suggestions are based upon N- and V- models.

I wouldn't like to run into troubles, so I am unsure if these suggested values are proper for our system.

I think, I have to change maxssiz to 1.5*default as you said.
Shall I apply this to maxdsiz, too? All values mentioned in this doc to prevent more SIGSEGV core-dumps?


Markus

[Steve Steel]

Hi

maxs maxd maxtsiz you can do online with kmtune without stopping the machine.


Make sure you have 2 to 4 times your memory in swapspace.


If dbc_max_pct is on 50 and you have at least 3gb of swap then put dbc_max and dbc_mix on 20
and 5 to free up main memory.


Steve Steel

[Markus Bonet]

OK,

I raised maxssiz to 0x05000000.
I left maxdsiz and maxtsiz untouched at 0x04000000.

My physical RAM is 1GB, swapspace is only 512 (typically half filled). I could rais it to 1.5GB, but I would rather left it so.

Still I get that core-dump.

I will try recompiling everthing with gcc 3.x and binutils 2.11.x unless someone can point me to another problem.


Hopeless, Markus :-((