> I'm runnning PHP 4.3.8 in CLI on Redhat 9 in this particular case.
> PHP compiled with --enable-ftp (among other things). PHP is installed
> as an Apache2 module, but (obviously since this is CLI), Apache isn't
> involved here. All other scripts work fine (CLI and web-based).
> Server is a dual MP 1600+. I've got the same setup running on a
> non-SMP server and it also seg faults at about the same place.
>
> I assume this is PHP seg faulting as I'm running CLI here. No error
> messages or anything (not hiding them or anything like that). Nothing
> in the sys logs. The script runs for a while (I've got it echoing
> what file it is d/l'ing), but then displays "Segmentation Fault" after
> it downloads several files.
>
> It does not die after a specific file, e.g. it dies randomly. Also,
> if I reduce the number of files to be d/l'ed, it won't seg fault.
> Usually it faults after d/ling about 210 files (it varies), but I've
> seen it go as high as 290. Its actually made it all the way through
> the script once today, but seg faults most of them time.
>
OK. Sounds like a genuine segfault to me. The CLI version will simply print
"Segmentation fault" to the screen or "Segmentation fault (core dumped)"
when configured with debugging enabled.
You will need to recompile and install PHP with the --enable-debug option.
If you compiled from source you can usually go to your source tree and run
./config.nice --enable-debug && make && make install
You need to have gdb installed (most likely, you already do). Since you are
running a CLI script this will be super easy. This is the best way to go
about it IMHO with your particular problem:
At the prompt type:
$> gdb php
This will fire up the debugger and give you a prompt like so: (gdb). Type
the following at the gdb prompt:
(gdb) run /path/to/crashing/script.php
This will run the application and will produce some kind of message
indicating that there was a segfault like so "Program received signal
SIGSEGV, Segmentation fault." In the example below it was clearly
mysqli_read_property() that caused the problem.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 17763)]
0x080d9e48 in mysqli_read_property (object=0x83b8184, member=0x83b5fb0,
type=0)
at /usr/local/src/php/php-5.0.1/ext/mysqli/mysqli.c:204
204 if (!obj->ptr ||
Once you receive a message like that, type the following at the gdb prompt:
(gdb) bt
This will produce a backtrace with one instruction per line with the last
instruction at the top of the list.
Alternately, if you run your code in CLI mode, and it segfaults, a file
called "core" will be created in the directory you are working in. You can
perform the same task using the core file like by running the following
command: (replace /usr/local/bin/php with the path to your php executable)
$> gdb /usr/local/bin/php /path/to/core
Then type "bt" at the (gdb) prompt.
The problem with running gdb and bt is that you have to have an intimate
understanding of the PHP source code to get anything more than just a hint
about the problem. If you can reproduce the segfault and capture a backtrace
consistently you might have found a PHP bug. *Most* segfaults are caused by
bugs since PHP is interpreted.
What to do:
If any of the output from gdb give you a hint what the problem could be (ftp
functions or something) research each of the functions you are using on the
PHP site reading the user added comments. Look for any mention of a possible
segfault. Search the PHP bugs on http://bugs.php.net for your PHP version
using the name of the function and/or the name of the commands in the
backtrace. Chances are someone has already found the bug and there may be a
workaround or the problem has been fixed in CVS or in a newer version (in
your case PHP 4.3.9RC2).
If you can't find anything relating to your problem on PHP.net,
bugs.php.net, or google then you should follow the proceedure for reporting
bugs on http://bugs.php.net/ . It's a thankless job, but it helps everyone
out in the long run if done properly. It will be much appreciated if you
follow the above steps and include sample code and gdb information when
submitting a bug. Leave it to the real pros to read the backtrace output!
:-)
Good luck,
Jim Grill
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
