And what was the configure line you used to configure PHP?
(note: This does NOT crash for me)

This was my configure command:
configure --with-gd=/usr --enable-gd-native-ttf --with-jpeg-dir=/usr --with-xpm-dir=/usr/X11R6 --with-t1lib --with-ttf=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-freetype-dir=/usr 

What is the version libgd do you use ? Maybe this is problem on my side...

I would recomment to use the bundled GD library which you can enable by using --with-gd (without path). Can you try that?

And if you get the same segfault with --with-gd (ie. the bundled GD), then provide a GDB backtrace.

I did what you asked me. I even got computer for tests. I install last version s of gd-2.0.15 and php4-STABLE-200306161530. When i use the bundled GD library everything is ok, but if i use external GD then happens segfault.

There is the solution then, use the bundled library (which has some bugs fixed the external one hasn't)

This is  not the solution at all. Then next bug is: i can't use function imagegif() in your solution. Can i post it ?

<Then next bug is: i can't use function
imagegif() in your solution. Can i post it ?>

No, this is not a bug. Even Boutell does not support gif export.

I strongly suggest you to use only the bundled GD (and thinking about alternatives for the gif format), its quality and its integration to php is really better.

pierre

This is the official position of mantainers of this module ? You don't support external GD library and use your own fork. Am i right ?

Not really, but what do you want us to do?  We can't fix segfaults in 3rd-party libraries.  Well, we can, we can fix them and redistribute them, exactly like we are doing.  So either use the 3rd-party stuff and hope you get one which doesn't segfault or use the one we bundle that we have tested and fixed.

I ran into this same issue and went and spent some time debugging it.

Here is the backtrace:

#0  0x40359f9d in _int_free () from /lib/libc.so.6
#1  0x40358dda in free () from /lib/libc.so.6
#2  0x400c3e3f in gdFree (ptr=0x8224114) at gdhelpers.c:100
#3  0x400bae28 in gdFreeDynamicCtx (ctx=0x8224114) at gd_io_dp.c:154
#4  0x0806dcaa in _php_image_create_from_string (data=0x82105c4, tn=0x81922e2 "JPEG", 
    ioctx_func_p=0x806433c <gdImageCreateFromJpegCtx>) at /usr/local/build/php-4.3.2/ext/gd/gd.c:1286
#5  0x0806de1f in zif_imagecreatefromstring (ht=1, return_value=0x8215ed4, this_ptr=0x0, return_value_used=1)
    at /usr/local/build/php-4.3.2/ext/gd/gd.c:1315
#6  0x08189f24 in execute (op_array=0x8216074) at /usr/local/build/php-4.3.2/Zend/zend_execute.c:1606
#7  0x0817838c in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/build/php-4.3.2/Zend/zend.c:869
#8  0x081442d3 in php_execute_script (primary_file=0xbffff830) at /usr/local/build/php-4.3.2/main/main.c:1671
#9  0x081908dc in main (argc=2, argv=0xbffff8e4) at /usr/local/build/php-4.3.2/sapi/cgi/cgi_main.c:1501
#10 0x402fadc4 in __libc_start_main () from /lib/libc.so.6


It looks like the cause of the seg fault is the GD library (I used gd-2.0.15gif) trying to free some of the memory that php is using.  Specifically php's pointer to the image data.

So the work around was to null out the data pointer on php's side before it made its call to GD to free up stuff it was using.

Details:

The call made from php that eventually causes the seg fault is in ext/gd/gd.c around line 1284 in the _php_image_create_from_string function:

io_ctx->gd_free(io_ctx);

This calls the gdFreeDynamicCtx function in gd_io_dp.c (line 141 in my copy).

To null out the data pointer contained under the io_ctx variables to prevent GD from trying to free the memory I added the following above the gd_free call:

**((void***)(io_ctx+1)) = NULL;

Its kinda messy since we don't have access to any of the GD structs.  The equivalent code on the GD side of things, for example in the gdFreeDynamicCtx function, would be something like:

((dynamicPtr*)((dpIOCtx*)ctx)->dp)->data = NULL;


Here is what the whole section of code in ext/gd/gd.c looks like (in my copy):

...
        if (!im) {
                php_error_docref(NULL TSRMLS_CC, E_WARNING, "Passed data is not in '%s' format", tn);
                return NULL;
        }
        // tp - 7/2/2003  - we don't want gd trying to free() our data
        **((void***)(io_ctx+1)) = NULL;
#if HAVE_LIBGD204
        io_ctx->gd_free(io_ctx);
#else
        io_ctx->free(io_ctx);
#endif
...


PHP's built in Gd library doesn't try to free the PHP's data so this work around shouldn't effect any of the built in stuff (assuming the structs have the same layouts).