I decided to publish my code: http://yayel.com/bug/users_postpicture.php.txt

you'll need to cut it down to only the offending code if you want someone look at it.
the good people who work on php have better things to do than wade through other people's code, and even more so as 95% of it turns out to be pilot error.

i know this sounds harsh, but try to look at it from the opposite side.

now to your problem.

the script running 20 times looks like dying httpd processes, but that'd be obvious from the apache logs.
if this is the case, rebuild php with --enable-debug, and post a backtrace.

Oh, one last thing: I talked about a bug which may be turn into a security problem because the *entire* script seems to loop, and because it *crashes* at the end: there is no html output (IE stops, Mozilla alerts "this document contains no data").

Sorry Cynic, I don't really have a debugging experience.
I did not know what to cut (that's why code is not published here), but know that everything gets ok if ImageCreateTrueColor() (line 91) is replaced by ImageCreate().

I'll rebuild php, please tell me how to find the backtrace.

Apache reports several times in error_log strings like that one: [Fri Aug 30 17:00:17 2002] [notice] child pid 29648 exit signal Segmentation fault (11)

imo it's quite obvious which parts of the script are irrelevant:
input checking, database stuff, jpeg/png/... stuff.

as for the backtrace: that's described in the page you should've read before submiting: http://bugs.php.net/how-to-report.php

See http://bugs.php.net/bugs-generating-backtrace.php.
BTW, you might want to try the bundled version of GD2 in PHP 4.3.0-dev. Grab a (non-STABLE) snapshot from http://snaps.php.net.

Starting program: /usr/local/apache/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
0x082318fb in compress (init_bits=3, outfile=0x83c5a98, im=0x83ec238) at gd_lzw_out.c:534
534             if ( HashTabOf (i) == fcode ) {
(gdb) bt
#0  0x082318fb in compress (init_bits=3, outfile=0x83c5a98, im=0x83ec238) at gd_lzw_out.c:534
#1  0x0823178e in GIFEncode (fp=0x83c5a98, GWidth=100, GHeight=35, GInterlace=0, Background=0, Transparent=-1,
    BitsPerPixel=1, Red=0x83ec248, Green=0x83ec648, Blue=0x83eca48, im=0x83ec238) at gd_lzw_out.c:349
#2  0x08231237 in gdImageLzwCtx (im=0x83ec238, out=0x83c5a98) at gd_lzw_out.c:67
#3  0x0823117c in gdImageGifCtx (im=0x83ec238, out=0x83c5a98) at gd_gif_out.c:23
#4  0x080b50aa in _php_image_output_ctx (ht=2, return_value=0x83dac3c, this_ptr=0x0, return_value_used=0,
    image_type=1, tn=0x8243caf "GIF", func_p=0x8231168 <gdImageGifCtx>) at gd_ctx.c:94
#5  0x080b91be in zif_imagegif (ht=2, return_value=0x83dac3c, this_ptr=0x0, return_value_used=0) at gd.c:1462
#6  0x081a67f3 in execute (op_array=0x83c1804) at ./zend_execute.c:1598
#7  0x08182c96 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810
#8  0x0809b0d2 in php_execute_script (primary_file=0xbffff730) at main.c:1381
#9  0x0818e2f6 in apache_php_module_main (r=0x8358814, display_source_mode=0) at sapi_apache.c:90
#10 0x080974b4 in send_php () at eval.c:41
#11 0x0809750d in send_parsed_php () at eval.c:41
#12 0x081b067b in ap_invoke_handler () at eval.c:41
#13 0x081c5243 in process_request_internal () at eval.c:41
#14 0x081c52a4 in ap_process_request () at eval.c:41
#15 0x081bc24d in child_main () at eval.c:41
#16 0x081bc3f8 in make_child () at eval.c:41
#17 0x081bc56c in startup_children () at eval.c:41
#18 0x081bcbe8 in standalone_main () at eval.c:41
#19 0x081bd457 in main () at eval.c:41
#20 0x4031e306 in __libc_start_main (main=0x81bd0a8 <main>, argc=2, ubp_av=0xbffffb64, init=0x8074b50 <_init>,
    fini=0x8237c40 <_fini>, rtld_fini=0x4000d2dc <_dl_fini>, stack_end=0xbffffb5c)
    at ../sysdeps/generic/libc-start.c:129



Ok, gif IS the problem. 
I'm not a C guru, but I can't understand why is there so many mysql inserts and file copies because of the buggy gd function... Again I don't know anything about C :)


Thank you for your help and fixes !!

Wow, it's been I while I could not reach bugs.php.net...
anyway, I solve my problem and also tried to submit my comment to imagecreatetruecolor documentation page.

When you think about it (and I was stupid), a Gif can't be made with ImageCreateTrueColor() since it can only index 256 colors.

BUT: the problem still remains, there is no warning or an error message when ImageGif() is used with ImageCreateTrueColor(), and php crashed instead (and it's really a dirty bug, according that my script loops till it ends with apache child process).

Thank you for fixing it.

Comment added to the documentation.  Closing bug.

Reopening. It crashes, so there's really some bug in there.
(although I believe it's in GD itself..)

Please try this snapshot:

http://snaps.php.net/php4-latest.tar.gz

And configure it same as you did before EXCEPT for --with-gd
use --with-gd=php (thus using our bundled version of gd 2.0.1 which has some fixes in it)

If you still get the segfault, please provide the backtrace
and a SHORT example script which can be used to reproduce it.

But does this build content all the GIF related functions (because of the lzh licence blablabla...) ??

Mmmm according to the Zend Weekly news #83, php4.3 may read Gif files (ImageCreateFromGif) but won't include the function to write them (ImageGif), so this "gd inside!" build is useless for people who still want to use ImageGif() function,  and I'll continue to use it from a patched gd2 or a gd<1.6, that is to say link to an external gd. :(

I bet the patches which enable this gif writing are buggy.
Not PHP problem at all.

Ok, let's consider it's a gd bug. But why did php loops my script (you can look at it, there is no loop written) and tried to write several times the gif file and also insert into mysql (only one INSERT query coded) ??
I do not write in C, Perl, whatever, so I cannot try other language which can use gd to see if it also crashes or not.
I think we should prevent with a php error message like "ImageGif cannot write a file with more than 256 colors"... mmm ? :)