first time installing an SMF,
i did a 1.1.2 version download, untared created a database, and whenever a user tries to register thus viewing the verification code, image generation never completes. and the apache process blocks eating up huge amounts of memory, starts with 40M about 4M/s and seems to never end which is strange since php.ini memory_limit = 16M .
I'm using apache 2.2.4 mpm-worker, php 5.2.1 with threads enabled and bundled gd 2.0.28 compatible (freetype 2.1.10).
I need to pinpoint the culprit ie. part in the code that's doing this. Is adding asserts as checkpoints in code a proper way to do this, is there a function implemented in smf that I could use ?
Try using Apache with prefork, I don't think gd is thread-safe and that might be causing part of the problem.
Sources/Subs-Graphics.php
$fontcord = @imagettftext($code_image, $font_size, $angle, $font_x, $font_y, $char_color, $fontface, $character['id']);
it stops on this one every time.
I've put a syslog(LOG_DEBUG,"checkpoint 1"); before and syslog(LOG_DEBUG,"checkpoint 2"); after and I always get to checkpoint1 and never to checkpoint 2.
mpm-worker has worked nice for me for a long time. I'd like if I could keep it somehow.
it's 1 am local time and I'm drunk, so I'll check the arguments tomorrow,
ttyl guys.
Remove the @ before the line and see what happens. (That is used to suppress error messages that could cause a corrupt image)
removing the @ error suppresion didn't help much, still no output, it just hangs.
added this before the function callsyslog(LOG_DEBUG,serialize($code_image));
syslog(LOG_DEBUG,serialize($font_size));
syslog(LOG_DEBUG,serialize($angle));
syslog(LOG_DEBUG,serialize($font_x));
syslog(LOG_DEBUG,serialize($font_y));
syslog(LOG_DEBUG,serialize($char_color));
syslog(LOG_DEBUG,serialize($fontface));
syslog(LOG_DEBUG,serialize($character['id']));
and it gave me this in the logs May 7 09:58:28 batou apache2: i:0;
May 7 09:58:28 batou apache2: i:18;
May 7 09:58:28 batou apache2: i:-11;
May 7 09:58:28 batou apache2: i:102;
May 7 09:58:28 batou apache2: i:31;
May 7 09:58:28 batou apache2: i:228;
May 7 09:58:28 batou apache2: s:72:"/home/fiore/-censored-.com/forum/Themes/default/fonts/Screenge.ttf";
May 7 09:58:28 batou apache2: s:1:"N";
I can't see anything out of the ordinary apart from $code_image not being serializable because it's a resource (dunno if it should return i:0 though).
Workaround:
So what I did was comment out that line, which actually simulated a clean failure. The rest of the script could then resume and fall back and voila, the image verification works.
I still don't understand why it failed.
Yeah. Awfully strange, and I don't think anything short of a session with gdb would help determine the cause.
My guess is something broken with freetype.
Solution:
Actually, it turns out the bug was in gd or php itself.
Instead of using gd bundled with php, I recompiled php with support for external gd, and installed gd 2.0.34 (instead of 2.0.28 with the same freetype included) and now it works. imagettftext actually returns a usable resource.
Glad to hear it works.
If you used a distribution-specific package, you might want to file a bug on it so the developers there can fix it.
great idea.
I just filed a bug report to gentoo bugzilla with a proposed solution.
Besides all the info mentioned there, I've put a link to this thread too.
It would be interesting to see how soon it will be closed.