segmentation fault at the end of script

Hi,

I'm writing a php script which deals with 3 ORACLE databases.
This script is launch by a script shell on an linux machine like this :
/../php/bin/php ./MySript.php (PHP 4.3.3)

My script works fine and do all what I need.
But at the end of the execution, I can read "Segmentation Fault".

The segmentation fault appear at the end of my script execution,
no line code is responsible of this. Somebody has been confronted
with this problem ?

Best regards

Jérôme

On 3 Nov 2003 02:36:34 -0800, jsivignon@ifrance.com (sivignon) wrote:

>I'm writing a php script which deals with 3 ORACLE databases.
>This script is launch by a script shell on an linux machine like this :
>/../php/bin/php ./MySript.php (PHP 4.3.3)
>
>My script works fine and do all what I need.
>But at the end of the execution, I can read "Segmentation Fault".
>
>The segmentation fault appear at the end of my script execution,
>no line code is responsible of this. Somebody has been confronted
>with this problem ?

What distribution of Linux, and what version(s) of Oracle? (Oracle's only
officially certified on a few commercial Linux distributions e.g. RedHat
Advanced Server - but it works on many others, if you set it up right. It has
more trouble on some distributions than others ... )

What's in the code? Have you tried examining the core dump with gdb to give
you some idea where the segfault happened?

For example, using a program that'll deliberately crash:

andyh@server:~/tmp$ cat dumpy.c
int crash() {
char* crashycrashy = 12345;
*crashycrashy = 100;
}

int main() {
crash();
}
andyh@server:~/tmp$ gcc -o dumpy dumpy.c
dumpy.c: In function `crash':
dumpy.c:2: warning: initialization makes pointer from integer without a cast
andyh@server:~/tmp$ ./dumpy
Segmentation fault (core dumped)

OK - so it's crashed, and dumped out a 'core' file.

You can use gdb (the debugger) to load up the program and the core file, and
it'll be able to give clues as to what happened at the time of the crash:

andyh@server:~/tmp$ gdb dumpy core
GNU gdb 5.2
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-slackware-linux"...
Core was generated by `./dumpy'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x080483d0 in crash ()
(gdb)


Here it's saying that the crash happened in the crash() function. (If it were
compiled with debugging options it'd give even more information).

You can use the 'bt' (backtrace) command to get the stack of calls that lead
up to the crash:

(gdb) bt
#0 0x080483d0 in crash ()
#1 0x080483e3 in main ()
#2 0x4003317d in __libc_start_main () from /lib/libc.so.6

--
Andy Hassall (andy@andyh.co.uk) icq(5747695) (http://www.andyh.co.uk)
Space: disk usage analysis tool (http://www.andyhsoftware.co.uk/space)

> What distribution of Linux, and what version(s) of Oracle? (Oracle's only
> officially certified on a few commercial Linux distributions e.g. RedHat
> Advanced Server - but it works on many others, if you set it up right. It has
> more trouble on some distributions than others ... )

It's a Red Hat 9 distribution with ORACLE 8.1.6 client-side.
This web-server is used for a big application in php/ORACLE, and works
well, without crash.


>
> What's in the code? Have you tried examining the core dump with gdb to give
> you some idea where the segfault happened?

No core dump are created ! the application works fine, the commit
action is done on the database. Really, except the message
"segmentation fault" all is OK. I think it's only where php programm
free the memory at the end that this message gone.

Yes, this bug is not critical for my application, but the end-users
said each time "WOHH, a bug ! your programm doesn't work !"

At the beginning, I Saw that I have forgotten to close 1 cursor, and since
I close this cursor, the application doesn't crash all the the time, but in
some cases , BOUMM, the message appear.

I have read many times the program source to find a database cursor not close
or a database connexion not close, nothing.


strange no ?

thank you for your response, and I offer one's apologies for my english !