Appears that the problem is with PHP scripts that run through the CLI in general. I have a few scripts who run from the commandline via crond, and some of them now segfault as well, so if the PEAR installer uses some PHP code, it could be that they both fail for the same reason...

Just checked with PHP4.3.3RC4. The problem does not exist there. Most probably it's something that changed between 4.3.3RC4 and the final release, then...

Could you provide a small sample script (besides PEAR make install) that could be used to replicate the crash and generate a backtrace of the crash.

Ok I have a script that searches the web for news, gathers them into a DB, and then creates a nice HTML summary for all of them.

I have now copied sapi/cli/php to the backend creation directory, and ran this:

bash-2.05$ ./php ZZZupdate-60-news.php 
Segmentation fault (core dumped)

<?php
require("Inc/hebdate.php");
require("Inc/config.php");
require("Inc/header.php");
require("Inc/categories.php");
$searchform = fopen("search.html", "r");
while(!feof($searchform)) { $output .= fgets($searchform, 10000); } fclose($searchform);
$panel = $news_label . " | " . cCreateLink($economy_label,$economy_file) . " | " . cCreateLink($technology_label,$technology_file) . " | " . cCreateLink($sport_label,$sport_file) . " | " . cCreateLink($entertainment_label,$entertainment_file);
$output = ereg_replace("___URL___",$news_file,$output);
$output .= "<CENTER><H2>60 &#1492;&#1499;&#1493;&#1514;&#1512;&#1493;&#1514; &#1492;&#1488;&#1495;&#1512;&#1493;&#1504;&#1493;&#1514; &#1489;&#1495;&#1491;&#1513;&#1493;&#1514;</H2></CENTER><BR>\n";
$output .= "<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0 BGCOLOR=\"#9CB8D0\" ALIGN=\"Center\" WIDTH=\"97%\"><TR><TD><TABLE BORDER=0 CELLSPACING=1 CELLPADDING=3 WIDTH=\"100%\">";
$output .= "<TR BGCOLOR=\"#F7F7F7\"><TD COLSPAN=5><FONT FACE=\"Arial\" SIZE=\"-1\">&#1492;&#1510;&#1490; 60 &#1499;&#1493;&#1514;&#1512;&#1493;&#1514; &#1488;&#1495;&#1512;&#1493;&#1504;&#1493;&#1514; &#1489;: ".$panel."</FONT></TD></TR>";
require("Inc/connectdb.php");
$query="SELECT * FROM news WHERE genre='news' ORDER BY unixtime DESC LIMIT 60";
require("Inc/maketable.php");
$output .= "<CENTER><FONT FACE=\"Arial\" SIZE=\"-1\">[ <A HREF=\"today-news.html\">&#1492;&#1510;&#1490; &#1499;&#1493;&#1514;&#1512;&#1493;&#1514; &#1502;24 &#1492;&#1513;&#1506;&#1493;&#1514; &#1492;&#1488;&#1495;&#1512;&#1493;&#1504;&#1493;&#1514;</A> ]</FONT></CENTER><BR>";
require("Inc/footer.php");
$fp=fopen($news_offset.$news_file,"w");
fputs($fp, $output);
fclose($fp);
?>

I know, this include various files. In those files basically there are normal for/while loops and string replaces, just like you saw here, no extra code functionality (besides the DB connection that happens in connectdb.php). 

Anyways...

bash-2.05$ gdb ./php                       
GNU gdb Red Hat Linux (5.2-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-redhat-linux"...
(gdb) run ZZZupdate-60-news.php
Starting program: ./php ZZZupdate-60-news.php

Program received signal SIGSEGV, Segmentation fault.
0x0818e743 in lex_scan (zendlval=0xbfff9c24) at Zend/zend_language_scanner.c:3699
3699    Zend/zend_language_scanner.c: No such file or directory.
        in Zend/zend_language_scanner.c
(gdb) bt
#0  0x0818e743 in lex_scan (zendlval=0xbfff9c24) at Zend/zend_language_scanner.c:3699
#1  0x08198fbc in zendlex (zendlval=0xbfff9c20) at /root/php-4.3.3/Zend/zend_compile.c:2464
#2  0x0818af8f in zendparse () at Zend/zend_language_parser.c:1880
#3  0x0818dc76 in compile_file (file_handle=0xbfffab20, type=8) at Zend/zend_language_scanner.c:3110
#4  0x0818ddc1 in compile_filename (type=8, filename=0x834f5a8) at Zend/zend_language_scanner.c:3164
#5  0x081bacd9 in execute (op_array=0x835055c) at /root/php-4.3.3/Zend/zend_execute.c:2150
#6  0x081bade5 in execute (op_array=0x834b57c) at /root/php-4.3.3/Zend/zend_execute.c:2181
#7  0x081a2d48 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php-4.3.3/Zend/zend.c:885
#8  0x0817ae98 in php_execute_script (primary_file=0xbfffe8a0) at /root/php-4.3.3/main/main.c:1723
#9  0x081be2a0 in main (argc=2, argv=0xbfffe944) at /root/php-4.3.3/sapi/cli/php_cli.c:818
#10 0x402b7657 in __libc_start_main (main=0x81bd968 <main>, argc=2, ubp_av=0xbfffe944, init=0x8077114 <_init>, 
    fini=0x8212ae0 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbfffe93c) at ../sysdeps/generic/libc-start.c:129
(gdb) 

hope this helps more...

I am really puzzled now. Alindeman told me, quoting:
[02:33] <alindeman> shimi: you must have --enable-debug enabled for anything useful tho

So I did make clean distclean, and ran configure again, this time with --enable-debug. When he said "useful", it didn't cross my mind that he means "the segfault would disappear" :) After recompiling - PEAR installation went fine, and my script that segfaulted before, doesn't do that anymore.

Making make clean distclean again and compiling without --enable-debug, and the segfault returns.

I don't care staying in this situation, unless this heavies the load on my CPU which is already quite busy... should I strip the cli executable or something? What about the apache module?

Start by reducing your configure options to bare minimum:

./configure --disable-all --disable-cgi

Then continue by adding the ones you used one by one to see which one causes it. (leave --disable-all there)
Also, you should not try outsmarting the configure..leave those 'tsrm' options out.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

Just installed PHP5 (after having PHP4 in debug mode) - and the phenomena is back!

As per the advise since when I opened this bug - I removed all the TSRM stuff, and currently this is my configure line:
'./configure' '--enable-memory-limit' '--with-gzip' '--enable-yp' '--with-sablot-js' '--enable-wddx' '--enable-snmp' '--enable-shmop' '--with-mysql' '--with-ldap' '--with-imap-ssl' '--with-iconv' '--with-gd' '--enable-gd-native-ttf' '--enable-ftp' '--with-dba' '--enable-calendar' '--enable-bcmath' '--with-bz2' '--with-zlib' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-imap' '--with-gettext' '--with-kerberos' '--enable-exif' '--with-ttf' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/include/freetype2/freetype' '--with-config-file-path=/usr/local/apache2/conf'

Now the installer doesn't segfault in the middle (it did before, when I had openssl in the option, so I removed it), and now only the script mentioned in the bug is segfaulting. Well, not exactly. The script mentioned in the bug actually works fine. The same script, that has exactly the same code, but works with more data (displays more results) - segfaults the php cli.

Again, compiling PHP in debug mode - and the problem vanishes. gdb trace shows again the same error: Zend/zend_language_scanner.c: No such file or directory.

Just thought you people might want to know.