f



Centos 6.3 + PCEL ibm_db2 + PHP 5.3.3 + DB2 ADCL 8.1 with Fixpak 18 = Segmentation fault

Hello,
I have installed on Centos 6.3
PHP 5.3.3
DB2 ADCL 8.1 with fixpack 18
PECL ibm_db2 Driver Version 1.9.5

All works fine. I can connect to my DB2 Database on commandline.
I can see the driver in phpinfo()
The driver will be loaded successfully.

When I start this PHP Script from commandline:
<?php
$conn = db2_connect('sample','db2inst1',ibmdb2');
?>
I get an Segmentation fault error (Core dump)
The error comes only, when I use a db2 connection. PHP scripts without db2 connection works fine. The problem must come from the ibm_db2.so driver

What can I do?

Regards
  
  Ulrich
0
ulrich45131
2/21/2013 10:56:05 AM
comp.databases.ibm-db2 12448 articles. 3 followers. arunrocks (9) is leader. Post Follow

17 Replies
5609 Views

Similar Articles

[PageSpeed] 55

On 2/21/2013 5:56 AM, ulrich45131@googlemail.com wrote:
> Hello,
> I have installed on Centos 6.3
> PHP 5.3.3
> DB2 ADCL 8.1 with fixpack 18
> PECL ibm_db2 Driver Version 1.9.5
>
> All works fine. I can connect to my DB2 Database on commandline.
> I can see the driver in phpinfo()
> The driver will be loaded successfully.
>
> When I start this PHP Script from commandline:
> <?php
> $conn = db2_connect('sample','db2inst1',ibmdb2');
> ?>
> I get an Segmentation fault error (Core dump)
> The error comes only, when I use a db2 connection. PHP scripts without db2 connection works fine. The problem must come from the ibm_db2.so driver
>
> What can I do?
>
> Regards
>
>    Ulrich
>

Is the PECL extension compiled against the same version of PHP and DB2 
you're using?  A mismatch is probably the most common reason for seg faults.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
Jerry
2/21/2013 2:01:58 PM
Am Donnerstag, 21. Februar 2013 11:56:05 UTC+1 schrieb ulric...@googlemail.com:
> Hello,
> 
> I have installed on Centos 6.3
> 
> PHP 5.3.3
> 
> DB2 ADCL 8.1 with fixpack 18
> 
> PECL ibm_db2 Driver Version 1.9.5
> 
> 
> 
> All works fine. I can connect to my DB2 Database on commandline.
> 
> I can see the driver in phpinfo()
> 
> The driver will be loaded successfully.
> 
> 
> 
> When I start this PHP Script from commandline:
> 
> <?php
> 
> $conn = db2_connect('sample','db2inst1',ibmdb2');
> 
> ?>
> 
> I get an Segmentation fault error (Core dump)
> 
> The error comes only, when I use a db2 connection. PHP scripts without db2 connection works fine. The problem must come from the ibm_db2.so driver
> 
> 
> 
> What can I do?
> 
> 
> 
> Regards
> 
>   
> 
>   Ulrich

I have found the problem.
I have installed the 64Bit Version of the ADCL Client.
By the installation of the DB2 Client it will be a 32bit and a 64bit version in parallel installed. In the user home directory I see  a directory /sqllib/lib and a directory /sqllib/lib64

In the db2profile file, at the end, I see
AddRemoveString LD_LIBRARY_PATH ${INSTHOME}/sqllib/lib a
Here will be build the LD_LIBRARY_PATH variable 
It points only to the 32bit version.

I have changed it to:

AddRemoveString LD_LIBRARY_PATH ${INSTHOME}/sqllib/lib64 a

and now it works.

Regands 

   Ulrich
0
ulrich45131
2/21/2013 2:47:17 PM
On 21.02.13 9:01 , Jerry Stuckle wrote:
> Is the PECL extension compiled against the same version of PHP and DB2 you're
> using?  A mismatch is probably the most common reason for seg faults.

This should not happen though, since you are compiling the extension yourself
with PECL. The extension dynamically links to the db2 library, so even if you
upgrade DB2, the extension picks up the new libs.

It's just that the OP uses a very old DB2 client, so he will not be able to
use any new features...

-- 
Helmut K. C. Tessarek
DB2 Performance and Development
IBM Toronto Lab
0
Helmut
2/21/2013 4:11:57 PM
On 21.02.13 9:47 , ulrich45131@googlemail.com wrote:
> I have found the problem.
> I have installed the 64Bit Version of the ADCL Client.
> By the installation of the DB2 Client it will be a 32bit and a 64bit version in parallel installed. In the user home directory I see  a directory /sqllib/lib and a directory /sqllib/lib64

Yea, with DB2 8.1 you still had the possibility to install a 32-bit client or
a 32-bit server instance on a 64-bit system.

> In the db2profile file, at the end, I see
> AddRemoveString LD_LIBRARY_PATH ${INSTHOME}/sqllib/lib a
> Here will be build the LD_LIBRARY_PATH variable 
> It points only to the 32bit version.
> 
> I have changed it to:
> 
> AddRemoveString LD_LIBRARY_PATH ${INSTHOME}/sqllib/lib64 a
> 
> and now it works.

Are you only using the client or is also a server instance installed under
${INSTHOME}?
If your server instance is 32-bit and you set the LD_LIBRARY_PATH to the
64-bit libs, you might run into other problems...

In that case, I suggest to use 2 different users for the client and server.
With newer versions you can also use the cli driver code.

-- 
Helmut K. C. Tessarek
DB2 Performance and Development
IBM Toronto Lab
0
Helmut
2/21/2013 4:36:59 PM
Am Donnerstag, 21. Februar 2013 17:36:59 UTC+1 schrieb Helmut Tessarek:
> On 21.02.13 9:47 , ulrich45131@googlemail.com wrote:
> 
> > I have found the problem.
> 
> > I have installed the 64Bit Version of the ADCL Client.
> 
> > By the installation of the DB2 Client it will be a 32bit and a 64bit version in parallel installed. In the user home directory I see  a directory /sqllib/lib and a directory /sqllib/lib64
> 
> 
> 
> Yea, with DB2 8.1 you still had the possibility to install a 32-bit client or
> 
> a 32-bit server instance on a 64-bit system.
> 
> 
> 
> > In the db2profile file, at the end, I see
> 
> > AddRemoveString LD_LIBRARY_PATH ${INSTHOME}/sqllib/lib a
> 
> > Here will be build the LD_LIBRARY_PATH variable 
> 
> > It points only to the 32bit version.
> 
> > 
> 
> > I have changed it to:
> 
> > 
> 
> > AddRemoveString LD_LIBRARY_PATH ${INSTHOME}/sqllib/lib64 a
> 
> > 
> 
> > and now it works.
> 
> 
> 
> Are you only using the client or is also a server instance installed under
> 
> ${INSTHOME}?
> 
> If your server instance is 32-bit and you set the LD_LIBRARY_PATH to the
> 
> 64-bit libs, you might run into other problems...
> 
> 
> 
> In that case, I suggest to use 2 different users for the client and server.
> 
> With newer versions you can also use the cli driver code.
> 
> 
> 
> -- 
> 
> Helmut K. C. Tessarek
> 
> DB2 Performance and Development
> 
> IBM Toronto Lab


Hi Helmut,

thanks for your answer.

I had installed the 64Bit ADCL Client. Only the Client is on that machine.
With the corrected LD_LIBRARY_PATH the driver is working. 

> Are you only using the client or is also a server instance installed under 
> ${INSTHOME}?
I have only the client under ${INSTHOME}

But now I had an other problem. At the end of the php script I get always an Segmentation fault (core dump)

The script is working fine. I insert big pictures in my DB2 database with blob fields. I get no errors while the script is running.

Only at the very end of the script I see the segmentation fault. I think it must be something with 32Bit / 64Bit on my machine?

Do you have any idea?

   Ulrich   
0
ulrich45131
2/21/2013 4:59:32 PM
On 21.02.13 11:59 , ulrich45131@googlemail.com wrote:
> But now I had an other problem. At the end of the php script I get always
> an Segmentation fault (core dump)

Can you post the backtrace?

> Only at the very end of the script I see the segmentation fault. I think it
> must be something with 32Bit / 64Bit on my machine?

Hard to say w/o a backtrace. We need to figure out which function is causing
the crash.

Do you get the seg fault only via the module or also via PHP CLI?
Can you narrow it down? Say, does it only segfault, when you insert? Or does
it also crash at a select, or is just a connect enough to make it crash?

wrt 32/64 bit:
How did you create the client instance? What was your db2icrt command?
I assume that your instance might be 32-bit. I think the lowest bitwidth was
the default.
Can you change your instance to 64-bit? db2iupdt -w 64 <instance_user>

-- 
Helmut K. C. Tessarek
DB2 Performance and Development
IBM Toronto Lab
0
Helmut
2/21/2013 5:44:02 PM
On 2/21/2013 11:11 AM, Helmut Tessarek wrote:
> On 21.02.13 9:01 , Jerry Stuckle wrote:
>> Is the PECL extension compiled against the same version of PHP and DB2 you're
>> using?  A mismatch is probably the most common reason for seg faults.
>
> This should not happen though, since you are compiling the extension yourself
> with PECL. The extension dynamically links to the db2 library, so even if you
> upgrade DB2, the extension picks up the new libs.
>
> It's just that the OP uses a very old DB2 client, so he will not be able to
> use any new features...
>

All too easy for it to happen.  For instance, if one has one version of 
the PHP runtime system and a different version of the development system 
on their machine.  Or, as in this case, mixing 32 and 64 bit versions.

It happens all too often.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
Jerry
2/21/2013 7:01:50 PM
Am Donnerstag, 21. Februar 2013 18:44:02 UTC+1 schrieb Helmut Tessarek:
> On 21.02.13 11:59 , ulrich45131@googlemail.com wrote:
> 
> > But now I had an other problem. At the end of the php script I get always
> 
> > an Segmentation fault (core dump)
> 
> 
> 
> Can you post the backtrace?
> 
> 
> 
> > Only at the very end of the script I see the segmentation fault. I think it
> 
> > must be something with 32Bit / 64Bit on my machine?
> 
> 
> 
> Hard to say w/o a backtrace. We need to figure out which function is causing
> 
> the crash.
> 
> 
> 
> Do you get the seg fault only via the module or also via PHP CLI?
> 
> Can you narrow it down? Say, does it only segfault, when you insert? Or does
> 
> it also crash at a select, or is just a connect enough to make it crash?
> 
> 
> 
> wrt 32/64 bit:
> 
> How did you create the client instance? What was your db2icrt command?
> 
> I assume that your instance might be 32-bit. I think the lowest bitwidth was
> 
> the default.
> 
> Can you change your instance to 64-bit? db2iupdt -w 64 <instance_user>
> 
> 
> 
> -- 
> 
> Helmut K. C. Tessarek
> 
> DB2 Performance and Development
> 
> IBM Toronto Lab

Hi Helmut,
thanks for your Answer.

> wrt 32/64 bit:
> How did you create the client instance? What was your db2icrt command?
> I assume that your instance might be 32-bit. I think the lowest bitwidth was
> the default.
> Can you change your instance to 64-bit? db2iupdt -w 64 <instance_user>
You are right. I had installed the 32bit instance.
Now I have deinstalled the complete ADCL Client because I had done to many changes.

After this i have installed new the ADCL Client and created a 64bit instance.

Now, the driver is working without to change the lib path. I think in this case the correct 64bit libraries will be copied to the right places.

Now I have only the Segmentation fault on the end of the php script.

> Do you get the seg fault only via the module or also via PHP CLI?
> Can you narrow it down? Say, does it only segfault, when you insert? Or does
> it also crash at a select, or is just a connect enough to make it crash?

I can reproduce the error with this minimal script:
<?php
echo "Start\n";
$conn = db2_connect('BTNSMS', 'xxxx', 'xxxxxx');
echo $con;
exit;
?>

The output is:
Start
Recource id #4
Segmentation fault (core dump)

... and a 2MB Core Dump file



> Can you post the backtrace?
 
I am not familar with backtrace. What have I to do?

Regards

    Ulrich from Germany
0
ulrich45131
2/22/2013 8:56:54 AM
On 22.02.13 3:56 , ulrich45131@googlemail.com wrote:
> Now I have only the Segmentation fault on the end of the php script.

> I can reproduce the error with this minimal script:
> <?php
> echo "Start\n";
> $conn = db2_connect('BTNSMS', 'xxxx', 'xxxxxx');
> echo $con;
> exit;
> ?>
> 
> The output is:
> Start
> Recource id #4
> Segmentation fault (core dump)
> 
> .. and a 2MB Core Dump file

This is really weird. Am I correct that you also get the segfault, when you
remove the 'exit;' line?

Right now it is just a guess, but I suspect that some memory pool might be
freed twice or something similar.

Can you do one more test for me? Since I haven't seen the backtrace yet, I'm
trying to narrow down the problem.
Can you try to replace db2_connect with db2_pconnect ?
Also, this segfault only happens, if you use a db2_* function, right?

> I am not familar with backtrace. What have I to do?

If you don't get the backtrace in some of your logs (httpd, php, syslog), you
will have to use a debugger. In your case, gdb might be the best choice.

gdb /path/to/binary /path/to/coredump

To get a correct code mapping your binary should have been compiled with -g.
How did you get the coredump?
1) httpd + php module + ibm_db2 extension?
2) PHP CLI + ibm_db2?

1) gdb `which httpd` coredump
2) gdb `which php` coredump

Then you enter 'bt' and you'll get the backtrace for the segfault. The
backtrace (also called stack trace) basically shows you the chain of events
(function calls) which lead to the segfault.
You can also select the stack frame which caused the coredump and use 'list'
to see the source code. 'print' can be used to show you the value of variables...

-- 
Helmut K. C. Tessarek
DB2 Performance and Development
IBM Toronto Lab
0
Helmut
2/22/2013 5:07:59 PM
On Thu, 21 Feb 2013 02:56:05 -0800, ulrich45131 wrote:

> Hello,
> I have installed on Centos 6.3
> PHP 5.3.3
> DB2 ADCL 8.1 with fixpack 18
> PECL ibm_db2 Driver Version 1.9.5
> 
> All works fine. I can connect to my DB2 Database on commandline.
> I can see the driver in phpinfo()
> The driver will be loaded successfully.
> 
> When I start this PHP Script from commandline:
> <?php
> $conn = db2_connect('sample','db2inst1',ibmdb2');
> ?>
> I get an Segmentation fault error (Core dump)
> The error comes only, when I use a db2 connection. PHP scripts without db2 connection works fine. The problem must come from the ibm_db2.so driver
> 
> What can I do?
> 
> Regards
>   
>   Ulrich

I wholeheartedly recommend ADOdb:

#!/usr/bin/env php
<?php
require_once ('adodb/adodb.inc.php');
require_once ('adodb/adodb-exceptions.inc.php');

// Cannot use '*' in the following query because hiredate is timestapm

$QUERY = <<<EOQ
select empno,ename,job,mgr,sal,deptno,to_char(hiredate,'YYYY-MM-DD'),sal,comm
from emp
EOQ;

$conn = ADONewConnection("db2");
$conn->Connect("sampledb", "db2inst1", 'qwerty', 'scott');
$rs = $conn->Execute($QUERY);
while ($row = $rs->fetchRow()) {
    foreach ($row as $col) {
        print ("$col\t");
    }
    print ("\n");
}
?>


[mgogala@medo dba]$ /tmp/ttt
7369	SMITH	CLERK	7902	800.00	20	1980-12-17	800.00		
7499	ALLEN	SALESMAN	7698	1600.00	30	1981-02-20	1600.00300.00	
7521	WARD	SALESMAN	7698	1250.00	30	1981-02-22	1250.00500.00	
7566	JONES	MANAGER	7839	2975.00	20	1981-04-02	2975.00		
7654	MARTIN	SALESMAN	7698	1250.00	30	1981-09-28	1250.001400.00	
7698	BLAKE	MANAGER	7839	2850.00	30	1981-05-01	2850.00		
7782	CLARK	MANAGER	7839	2450.00	10	1981-06-09	2450.00		
7788	SCOTT	ANALYST	7566	3000.00	20	1987-04-19	3000.00		
7839	KING	PRESIDENT		5000.00	10	1981-11-17	5000.00
7844	TURNER	SALESMAN	7698	1500.00	30	1981-09-08	1500.000.00	
7876	ADAMS	CLERK	7788	1100.00	20	1987-05-23	1100.00		
7900	JAMES	CLERK	7698	950.00	30	1981-12-03	950.00		
7902	FORD	ANALYST	7566	3000.00	20	1981-12-03	3000.00		
7934	MILLER	CLERK	7782	1300.00	10	1982-01-23	1300.00	

It does need ibm_db2 extension installed and it does need instance defined in the php.ini:

[root@medo pear]# grep db2 /etc/php.ini|egrep -v '^;'
extension=ibm_db2.so
ibm_db2.instance_name = db2inst1


[root@medo pear]# pecl list
Installed packages, channel pecl.php.net:
=========================================
Package Version State
ibm_db2 1.9.5   stable
oci8    1.4.9   stable


The schema is SCOTT and it may be vaguely familiar to people who have spent 
some tome working with some other databases...

[mgogala@medo ~]$ db2 list tables for schema scott

Table/View                      Schema          Type  Creation time             
------------------------------- --------------- ----- --------------------------
BONUS                           SCOTT           T     2013-01-19-00.33.16.694844
DEPT                            SCOTT           T     2013-01-19-00.33.17.239418
EMP                             SCOTT           T     2013-01-19-00.33.18.050442
JOBHIST                         SCOTT           T     2013-01-19-00.33.18.685354
SALGRADE                        SCOTT           T     2013-01-19-00.33.19.310096








Mladen Gogala
The Oracle Whisperer
http://mgogala.byethost5.com
0
Mladen
2/23/2013 4:23:11 AM
Am Freitag, 22. Februar 2013 18:07:59 UTC+1 schrieb Helmut Tessarek:
> On 22.02.13 3:56 , ulrich45131@googlemail.com wrote:
> 
> > Now I have only the Segmentation fault on the end of the php script.
> 
> 
> 
> > I can reproduce the error with this minimal script:
> 
> > <?php
> 
> > echo "Start\n";
> 
> > $conn = db2_connect('BTNSMS', 'xxxx', 'xxxxxx');
> 
> > echo $con;
> 
> > exit;
> 
> > ?>
> 
> > 
> 
> > The output is:
> 
> > Start
> 
> > Recource id #4
> 
> > Segmentation fault (core dump)
> 
> > 
> 
> > .. and a 2MB Core Dump file
> 
> 
> 
> This is really weird. Am I correct that you also get the segfault, when you
> 
> remove the 'exit;' line?
> 
> 
> 
> Right now it is just a guess, but I suspect that some memory pool might be
> 
> freed twice or something similar.
> 
> 
> 
> Can you do one more test for me? Since I haven't seen the backtrace yet, I'm
> 
> trying to narrow down the problem.
> 
> Can you try to replace db2_connect with db2_pconnect ?
> 
> Also, this segfault only happens, if you use a db2_* function, right?
> 
> 
> 
> > I am not familar with backtrace. What have I to do?
> 
> 
> 
> If you don't get the backtrace in some of your logs (httpd, php, syslog), you
> 
> will have to use a debugger. In your case, gdb might be the best choice.
> 
> 
> 
> gdb /path/to/binary /path/to/coredump
> 
> 
> 
> To get a correct code mapping your binary should have been compiled with -g.
> 
> How did you get the coredump?
> 
> 1) httpd + php module + ibm_db2 extension?
> 
> 2) PHP CLI + ibm_db2?
> 
> 
> 
> 1) gdb `which httpd` coredump
> 
> 2) gdb `which php` coredump
> 
> 
> 
> Then you enter 'bt' and you'll get the backtrace for the segfault. The
> 
> backtrace (also called stack trace) basically shows you the chain of events
> 
> (function calls) which lead to the segfault.
> 
> You can also select the stack frame which caused the coredump and use 'list'
> 
> to see the source code. 'print' can be used to show you the value of variables...
> 
> 
> 
> -- 
> 
> Helmut K. C. Tessarek
> 
> DB2 Performance and Development
> 
> IBM Toronto Lab

Hi Helmut,

thanks for your answer!

> This is really weird. Am I correct that you also get the segfault, when you
> remove the 'exit;' line?
Yes i tried it with return, with exit and also without a command.
 

> Can you do one more test for me? 
Yes shure

> Since I haven't seen the backtrace yet, I'm trying to narrow down the problem.
> Can you try to replace db2_connect with db2_pconnect ?
The result is the same -> Segmentation fault

> Also, this segfault only happens, if you use a db2_* function, right?
Yes. Scripts without db2 funktions running with normal end. 


> If you don't get the backtrace in some of your logs (httpd, php, syslog), you
> will have to use a debugger. In your case, gdb might be the best choice.
OK. I have installed the gdb 

> To get a correct code mapping your binary should have been compiled with -g.
Do you mean the gdb compiler must compiled with -g option or the gcc Compiler? 

> How did you get the coredump? 
> 1) httpd + php module + ibm_db2 extension?
NO
> 2) PHP CLI + ibm_db2?
YES
 
> 1) gdb `which httpd` coredump
NO 
> 2) gdb `which php` coredump
YES 

My actual test programm:

<?php
echo "Start\n";
$conn = db2_connect('BTNSMS', 'btn', 'ibmdb281');
exit("This is the last line of the script. Done.".PHP_EOL."\n");
?>


[root@freiburg modem_steuerung]# gdb php
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-56.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/php...(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install php-cli-5.3.3-14.el6_3.x86_64

(gdb) run test.php
Starting program: /usr/bin/php test.php
warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386
warning: Architecture rejected target-supplied description
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaacb000
[Thread debugging using libthread_db enabled]
Start
This is the last line of the script. Done.


Program received signal SIGSEGV, Segmentation fault.
0x00002aaab7f7c5f9 in ?? ()
(gdb) bt
#0  0x00002aaab7f7c5f9 in ?? ()
#1  0xf666caff2228d250 in ?? ()
#2  0x0000000000000000 in ?? ()
(gdb) list
No symbol table is loaded.  Use the "file" command.
(gdb) print
The history is empty.
(gdb)
 

Regards 

   Ulrich  

(IBM employe in Germany from 1978 - 1998)
0
ulrich45131
2/23/2013 9:34:01 AM
>> To get a correct code mapping your binary should have been compiled with -g.
> Do you mean the gdb compiler must compiled with -g option or the gcc Compiler? 

No, the binary, which you want to debug should have been compiled with -g.

>> 2) gdb `which php` coredump
> YES 

Then the command would be:

gdb /usr/bin/php </path/to/coredump>

> Reading symbols from /usr/bin/php...(no debugging symbols found)...done.
> Missing separate debuginfos, use: debuginfo-install php-cli-5.3.3-14.el6_3.x86_64

This tells me that the php version you are using was not compiled with -g, but
RH provides a way to install the correct symbols with:
debuginfo-install php-cli-5.3.3-14.el6_3.x86_64

> (gdb) run test.php

You don't even have to run the program, since you already have a coredump. gdb
can take it as an argument (see above).

> Starting program: /usr/bin/php test.php
> warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386

Hmm, now I am a little bit puzzled. It looks like you have a mixed
environment, some binaries are 32-bit and some others are 64-bit.
So either your php binary or the ibm_db2 module was compiled for a different
architecture.
What is the output of:
rpm -qa |grep php
and
file /usr/bin/php

How did you install ibm_db2? Did you install it as an .rpm or via 'pecl
install' or did you compile it yourself?
What is the output of:
file ibm_db2.so

> Program received signal SIGSEGV, Segmentation fault.
> 0x00002aaab7f7c5f9 in ?? ()
> (gdb) bt
> #0  0x00002aaab7f7c5f9 in ?? ()
> #1  0xf666caff2228d250 in ?? ()
> #2  0x0000000000000000 in ?? ()

Yea, this tells me that the symbols are missing. I can't see any functions
which actually caused the segfault.

The fact that you are using a mixed architecure might explain the segfault,
but to say for sure I'd have to see a correct backtrace.

I'm not really sure how to go on from here. Make sure that all your binaries
and libs in question are in fact 64-bit.
Opening a defect at PECL might also be a problem, since DB2 8.1 is out of
support for quite some time now.
We should try to get a useable backtrace. Also, all the binaries and libraries
should be 64-bit.

> (IBM employe in Germany from 1978 - 1998)

I worked for IBM Austria from 1997-2007 before I started at IBM Canada...

-- 
Helmut K. C. Tessarek
DB2 Performance and Development
IBM Toronto Lab
0
Helmut
2/23/2013 11:03:20 AM
On Fri, 22 Feb 2013 00:56:54 -0800, ulrich45131 wrote:

> I can reproduce the error with this minimal script:
> <?php echo "Start\n";
> $conn = db2_connect('BTNSMS', 'xxxx', 'xxxxxx'); echo $con;
> exit;
> ?>
> 
> The output is:
> Start Recource id #4 Segmentation fault (core dump)
> 
> .. and a 2MB Core Dump file


The problem is in the "exit", I've had it before with Oracle. You should 
do an explicit disconnect before exit, doing db2_close.


-- 
Mladen Gogala
The Oracle Whisperer
http://mgogala.byethost5.com
0
Mladen
2/23/2013 8:42:31 PM
Am Samstag, 23. Februar 2013 12:03:20 UTC+1 schrieb Helmut Tessarek:
> >> To get a correct code mapping your binary should have been compiled with -g.
> 
> > Do you mean the gdb compiler must compiled with -g option or the gcc Compiler? 
> 
> 
> 
> No, the binary, which you want to debug should have been compiled with -g.
> 
> 
> 
> >> 2) gdb `which php` coredump
> 
> > YES 
> 
> 
> 
> Then the command would be:
> 
> 
> 
> gdb /usr/bin/php </path/to/coredump>
> 
> 
> 
> > Reading symbols from /usr/bin/php...(no debugging symbols found)...done.
> 
> > Missing separate debuginfos, use: debuginfo-install php-cli-5.3.3-14.el6_3.x86_64
> 
> 
> 
> This tells me that the php version you are using was not compiled with -g, but
> 
> RH provides a way to install the correct symbols with:
> 
> debuginfo-install php-cli-5.3.3-14.el6_3.x86_64
> 
> 
> 
> > (gdb) run test.php
> 
> 
> 
> You don't even have to run the program, since you already have a coredump. gdb
> 
> can take it as an argument (see above).
> 
> 
> 
> > Starting program: /usr/bin/php test.php
> 
> > warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386
> 
> 
> 
> Hmm, now I am a little bit puzzled. It looks like you have a mixed
> 
> environment, some binaries are 32-bit and some others are 64-bit.
> 
> So either your php binary or the ibm_db2 module was compiled for a different
> 
> architecture.
> 
> What is the output of:
> 
> rpm -qa |grep php
> 
> and
> 
> file /usr/bin/php
> 
> 
> 
> How did you install ibm_db2? Did you install it as an .rpm or via 'pecl
> 
> install' or did you compile it yourself?
> 
> What is the output of:
> 
> file ibm_db2.so
> 
> 
> 
> > Program received signal SIGSEGV, Segmentation fault.
> 
> > 0x00002aaab7f7c5f9 in ?? ()
> 
> > (gdb) bt
> 
> > #0  0x00002aaab7f7c5f9 in ?? ()
> 
> > #1  0xf666caff2228d250 in ?? ()
> 
> > #2  0x0000000000000000 in ?? ()
> 
> 
> 
> Yea, this tells me that the symbols are missing. I can't see any functions
> 
> which actually caused the segfault.
> 
> 
> 
> The fact that you are using a mixed architecure might explain the segfault,
> 
> but to say for sure I'd have to see a correct backtrace.
> 
> 
> 
> I'm not really sure how to go on from here. Make sure that all your binaries
> 
> and libs in question are in fact 64-bit.
> 
> Opening a defect at PECL might also be a problem, since DB2 8.1 is out of
> 
> support for quite some time now.
> 
> We should try to get a useable backtrace. Also, all the binaries and libraries
> 
> should be 64-bit.
> 
> 
> 
> > (IBM employe in Germany from 1978 - 1998)
> 
> 
> 
> I worked for IBM Austria from 1997-2007 before I started at IBM Canada...
> 
> 
> 
> -- 
> 
> Helmut K. C. Tessarek
> 
> DB2 Performance and Development
> 
> IBM Toronto Lab

Hi Helmut,

the problem is fixed! What have I done? It was an Oddysee...

First I have download the latest stabil Version of php 5.4.12
Then I have compieled the php. Many devel Files where missing.
After the config, make and make install was run with success, I could start http with php.
But when I start the php Client I got errors that three moduls could not be loaded.

1. memcache
2. dba
3. ibm_db2

After I had installed new the memcache driver, this works
dba I could not get a 64 bit version to work. I disabled the dba driver.
I installed with pecl also the ibm_db2 driver new, but when I start php I get always the error "not compatibel"

Then I tried to compile the ibm_db2 driver manual
In the configure file I changed the lib path from /opt/IBM/db2/V8.1/lib to
/opt/IBM/db2/V8.1/lib64

After this I compieled the driver without error.

With this manuel compieled driver it works all fine.

I think the problem ist the DB2 Version 8.1 with the internal 32Bit and 64Bit libraries in parallel.
The pecl does nothing know about this double version and takes allways the "normal" /lib/  path. And so I had alway's a 32bit version of the ibm_db2 driver in use.

You are right with:  
> Hmm, now I am a little bit puzzled. It looks like you have a mixed
> environment, some binaries are 32-bit and some others are 64-bit. 

I think, that my own compiled ibm_db2 driver version also will work with the aktual Centos php 5.3.3. 

Thanks for your support.

Regands from the cold Germany

     Ulrich
0
ulrich45131
2/25/2013 9:31:47 AM
Am Samstag, 23. Februar 2013 21:42:31 UTC+1 schrieb Mladen Gogala:
> On Fri, 22 Feb 2013 00:56:54 -0800, ulrich45131 wrote:
> 
> 
> 
> > I can reproduce the error with this minimal script:
> 
> > <?php echo "Start\n";
> 
> > $conn = db2_connect('BTNSMS', 'xxxx', 'xxxxxx'); echo $con;
> 
> > exit;
> 
> > ?>
> 
> > 
> 
> > The output is:
> 
> > Start Recource id #4 Segmentation fault (core dump)
> 
> > 
> 
> > .. and a 2MB Core Dump file
> 
> 
> 
> 
> 
> The problem is in the "exit", I've had it before with Oracle. You should 
> 
> do an explicit disconnect before exit, doing db2_close.
> 
> 
> 
> 
> 
> -- 
> 
> Mladen Gogala
> 
> The Oracle Whisperer
> 
> http://mgogala.byethost5.com

Sorry,

this had I tried without success.

Regards

   Ulrich
0
ulrich45131
2/25/2013 9:33:53 AM
On 25.02.13 4:31 , ulrich45131@googlemail.com wrote:
> the problem is fixed! What have I done? It was an Oddysee...

Nice to hear. I mean the 'problem is fixed' part.

> Then I tried to compile the ibm_db2 driver manual In the configure file I
> changed the lib path from /opt/IBM/db2/V8.1/lib to /opt/IBM/db2/V8.1/lib64

The naming has changed in later versions of DB2 where you have a lib32 and
lib64 directory and a symlink is created in the instance home dir:
sqllib/lib -> /opt/ibm/db2/V10.1/lib64

Setting the PHP ini variable ibm_db2.instance_name might have helped too.

> I think, that my own compiled ibm_db2 driver version also will work with
> the aktual Centos php 5.3.3.

Let me know, if you have any problems.

-- 
Helmut K. C. Tessarek
DB2 Performance and Development
IBM Toronto Lab
0
Helmut
2/25/2013 6:04:23 PM
On Thursday, February 21, 2013 11:56:05 AM UTC+1, ulric...@googlemail.com wrote:
> Hello,
> 
> I have installed on Centos 6.3
> 
> PHP 5.3.3
> 
> DB2 ADCL 8.1 with fixpack 18
> 
> PECL ibm_db2 Driver Version 1.9.5
> 
> 
> 
> All works fine. I can connect to my DB2 Database on commandline.
> 
> I can see the driver in phpinfo()
> 
> The driver will be loaded successfully.
> 
> 
> 
> When I start this PHP Script from commandline:
> 
>  
> $conn = db2_connect('sample','db2inst1',ibmdb2');
> 
> ?>
> 
> I get an Segmentation fault error (Core dump)
> 
> The error comes only, when I use a db2 connection. PHP scripts without db2 connection works fine. The problem must come from the ibm_db2.so driver
> 
> 
> 
> What can I do?
> 
> 
> 
> Regards
> 
>   
> 
>   Ulrich

Ulrich, slight out of topic but I am interested to know if in your configuration your are able to to a full backup without hangs.
Is the server at V8.2 as well (fixpak 14) ? 
If so, are you abe to do a full backup ?
0
Massimiliano
3/3/2013 8:01:52 PM
Reply: