verification code brings down apache

Started by risk, May 06, 2007, 03:53:57 AM

Previous topic - Next topic

risk

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.
Motoko-chan
Director, Simple Machines

Note: Unless otherwise stated, my posts are not representative of any official position or opinion of Simple Machines.


risk

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)
Motoko-chan
Director, Simple Machines

Note: Unless otherwise stated, my posts are not representative of any official position or opinion of Simple Machines.


risk

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.
Motoko-chan
Director, Simple Machines

Note: Unless otherwise stated, my posts are not representative of any official position or opinion of Simple Machines.


risk

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.
Motoko-chan
Director, Simple Machines

Note: Unless otherwise stated, my posts are not representative of any official position or opinion of Simple Machines.


risk

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.

Advertisement: