Are you using bundled or non-bundled GD library?

I am using the bundled GD library.

Can you generate a backtrace from the core file and please provide the shortest possible version of the script that can be used to duplicate the crash.

I'm really not a Linux developer, and although what you are asking for sounds easy enough, I don't know how to give you what you want.

I would like to reiterate that there are 2 issues here:
1. Configure incorrectly reporting my support for FreeType2
2. gd.c has code that given certain #if conditions, leaves the variable 'error' undefined. The crash is occuring because of the reference to this floating pointer. I assume you want a backtrace to determine the line of code that is crashing, but I'm *giving* you the line of code that is crashing.

What was the configure line ? And exactly what freetype 1.x
version was installed? And how?

PHP build:
configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --enable-track-vars --with-imap=/usr/local/imap --with-gd --enable-ftp --enable-sysvsem --enable-sysvshm --enable-sockets --with-gettext --with-mm=/usr/local/lib/mm --with-jpeg-dir=/usr/lib --with-zlib-dir=/usr/local --with-openssl=/usr/local/ssl --with-ttf --enable-gd-native-ttf --enable-gd-imgstrttf --with-freetype-dir=/usr/local --with-dom

FreeType:
freetype-1.3.1.tar.gz was untarred and built and installed with:
configure
make
make install

The ifdef is correct, because no matter what the value will be assigned to error. There is another ifdef surrounding this code which has an else condition that is used to set a value to error. So the crash you are seeing comes from elsewhere.

The version of gd.c that I have is supposed to be 4.3.0. I still believe it is incorrect.

If you are referring to the statement:

Line 2951:   #else /* !USE_GD_IMGSTRTTF */

that 'else' is related to a "USE_GD_IMGSTRTTF" and is not the same as any "HAVE_GD_STRINGxxx" defines.

I'm saying that if USE_GD_IMGSTRTTF *is* defined, but neither HAVE_GD_STRINGFT nor HAVE_GD_STRINGTTF is defined, it will leave the variable 'error' undefined, and then try to use it (resulting in the possibility of a crash).

Do you still disagree?

If you change char *error; to char *error = NULL; does the segmentation fault you are seeing go away?

I would like to help you, but it would take some time to get my server back in the state where the error was occurring. I have since installed FreeType 2.x so that now things do build and work correctly.

So, I can't confirm the fact that the crash would go away. But, since variable "error" is undefined, it easily could cause a crash. Certainly initializing it to NULL would improve the "random" nature of undefined variables.

My original post was meant to help out the development of PHP by relaying my experience and pointing to specific lines of code that seem problematic. There is clearly a mistake in the gd.c code. You may choose not to do anything about it. And, it may not affect too many installations, but any decent software engineer would say that the code is risky at best.

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

This bug is NOT yet fixed.

In 4.3.1 the code can and still does produce bogus code that doesn't set error.

my main/php_config.h generates with this area (not verbatim):

/*   */
/* #undef HAVE_GD_STRINGTTF */

/*   */
/* #undef HAVE_GD_STRINGFT */

/*   */
/* #undef HAVE_GD_STRINGFTEX */

/*   */
#define USE_GD_IMGSTRTTF 1

/*   */
#define USE_GD_IMGSTRTTF 1


Notice we have neither FT nor the FTEX, nor TTF!

So why in the world does USE_GD_IMGSTRTTF get 1?  TAke a look at gd.c:2937

In this case error still ends up undefined as we never execute any of the four functions!!!!  I traced the calls back up, the bt is included below along with a print error to point out the fact.

GDB OUTPUT:

#0  0x080c114b in xbuf_format_converter (xbuf=0xbfffd1a0, fmt=0x40357707 "s",
    ap=0xbfffd260) at /usr/src/webserver/php-4.3.1/main/spprintf.c:438
#1  0x080c1601 in vspprintf (pbuf=0xbfffd208, max_len=0,
    format=0x40357706 "%s", ap=0xbfffd25c)
    at /usr/src/webserver/php-4.3.1/main/spprintf.c:622
#2  0x080be757 in php_verror (docref=0x0, params=0x80f92af "", type=2,
    format=0x40357706 "%s", args=0xbfffd25c)
    at /usr/src/webserver/php-4.3.1/main/main.c:423
#3  0x080bea1d in php_error_docref0 (docref=0x0, type=2,
    format=0x40357706 "%s") at /usr/src/webserver/php-4.3.1/main/main.c:508
#4  0x403489f6 in php_imagettftext_common (ht=8, return_value=0x817e304,
    this_ptr=0x0, return_value_used=0, mode=0, extended=0)
    at /usr/src/webserver/php-4.3.1/ext/gd/gd.c:2957
#5  0x4034861b in zif_imagettftext (ht=8, return_value=0x817e304,
    this_ptr=0x0, return_value_used=0)
    at /usr/src/webserver/php-4.3.1/ext/gd/gd.c:2835
#6  0x402fb542 in zend_assign_to_variable_reference ()
   from /usr/local/libexec/php-4.3.1/ZendOptimizer.so
#7  0x40304a02 in zend_oe () from /usr/local/libexec/php-4.3.1/ZendOptimizer.so
#8  0x080c02cb in php_execute_script (primary_file=0xbffffcb0)
    at /usr/src/webserver/php-4.3.1/main/main.c:1576
#9  0x080f8d84 in main (argc=2, argv=0xbffffd54)
    at /usr/src/webserver/php-4.3.1/sapi/cgi/cgi_main.c:1424
<MORE BUT WE'RE ONLY REALLY INTERESTED IN FRAMES 4->0>

(gdb) up
#4  0x403489f6 in php_imagettftext_common (ht=8, return_value=0x817e304,
    this_ptr=0x0, return_value_used=0, mode=0, extended=0)
    at /usr/src/webserver/php-4.3.1/ext/gd/gd.c:2957
2957    /usr/src/webserver/php-4.3.1/ext/gd/gd.c: No such file or directory.
        in /usr/src/webserver/php-4.3.1/ext/gd/gd.c
(gdb) print error
$2 = 0x20 <Address 0x20 out of bounds>
(gdb)


And the PHP script that will reproduce this every time::

mloftis@modwest:/htdocs/www/gd/431$ cat ttf.php
#!/usr/local/bin/php-4.3.1-4
<?php
            header ("Content-type: image/png");
            $im = imagecreate (400, 30);
            $black = imagecolorallocate ($im, 0, 0, 0);
            $white = imagecolorallocate ($im, 255, 255, 255);
            imagettftext ($im, 20, 0, 10, 20, -$white,
                     "/usr/share/fonts/default/TrueType/arib____.ttf", "Ich will muss");
            imagepng ($im);
            imagedestroy ($im);
            exit;
       ?>


And our ./configure statment.

./configure  --disable-debug --disable-rpath --with-pear=/usr/local/lib/php-4.3.1 --with-config-file-path=/etc --prefix=/usr/local --libexecdir=/usr/local/libexec/php-4.3.1 --enable-shared=yes --enable-track-vars --enable-magic-quotes --enable-trans-sid --with-kerberos --enable-all=shared --without-cyrus --without-fbsql --without-fdftk --without-fribidi --without-hwapi --without-informix --without-ingres --without-interbase --without-ircg --without-java --without-mcve --without-msession --without-oracle --without-oci8 --without-ovrimos --without-qtdom --without-readline --without-libedit --without-sybase --without-sybase-ct --without-msql --without-mssql --with-imap-ssl --with-openssl --enable-session --with-sablot-js=/usr --with-xslt-sablot=/usr --with-gdbm=shared,/usr --with-ndbm=shared,/usr --with-db2=shared,/usr --with-db3=shared,/usr --with-unixODBC=shared,/usr --disable-calendar --enable-overload --without-ncurses --disable-mime-magic --with-zlib --with-pcre-regex --disable-yp --disable-path-info-check --enable-discard-path --enable-mw-php-ini --enable-mw-deprecated-extension --with-jpeg-dir=/usr --enable-gd-native-ttf --with-ttf=/usr --with-png-dir=/usr


Relevant output around the GD extension config:

checking for FDF support... no
checking whether to enable the bundled filePro support... yes, shared
checking for FriBidi support... no
checking whether to enable FTP support... yes, shared
checking for GD support... yes, shared
checking for the location of libjpeg... yes, shared
checking for the location of libpng... yes, shared
checking for the location of libXpm... yes, shared
checking for FreeType 1.x support... yes, shared
checking for FreeType 2... yes, shared
checking for T1lib support... yes, shared
checking whether to enable truetype string function in GD... yes, shared
checking for fabsf... yes
checking for floorf... yes
checking for jpeg_read_header in -ljpeg... yes
checking for png_write_image in -lpng... yes
If configure fails try --with-xpm-dir=<DIR>
If configure fails try --with-freetype-dir=<DIR>
checking for GNU gettext support... yes, shared
checking for bindtextdomain in -lintl... no
checking for bindtextdomain in -lc... yes


Need anything else?

Reopening, see also this thread for why:
http://marc.theaimsgroup.com/?l=php-dev&m=105122451028941

See my #24223

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

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.