Tech-illiterate Bleg

Since I know there are professional developers out there, a question. Starting Sunday morning, whenever I attempt to Edit the BJ Lexicon, I’ve been getting the same message:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 122880 bytes) in /home/jcole1/public_html/bal/wp-includes/general-template.php on line 1524

I’ve tried it on two separate systems, so I don’t think it’s my PC. Can anyone out there tell me if there’s something I can do from the peon user end to rectify this? Or at least explain why WordPress has banhammered me in terms I can understand?

Share On Facebook
Share On Twitter
Share On Google Plus
Share On Pinterest
Share On Reddit

37 replies
  1. 1
    General Winfield Stuck says:

    The webmistress is still fiddling with the dials, i suspect. Little things have changed for me. Like I used to be able to just click on a commenters right side date/time stamp to copy it to my comment box, but now have to hit the little curved arrow. If you’re using Vista, then good luck, all sorts of little snafus come and go for me anyway.

  2. 2
    shoutingattherain says:

    Try typing in the words “Fuck you, WordPress”. It won’t fix the problem, but it will make you feel better.

  3. 3
    JK says:


    Have you posted a question to this site?

    Maybe, someone on one of the forums could give you some advice.

  4. 4
    brent says:

    Do you run wordpress updates yourself or does it update automatically? It would seem to be a server side error caused by some specific loop in the application but if the app hasn’t been updated recently then it might just be a server resources issue.

  5. 5
    JK says:

    Have you looked on this page for a possible answer?

  6. 6
    Mister Papercut says:

    I think it’s a job for the webmistress.

  7. 7

    Here is a likely solution:

    May have to increase the amount of memory a PHP script may consume
    1. If you have access to your PHP.ini file, change the line in PHP.ini
    If your line shows 8M try 16M:
    memory_limit = 16M ; Maximum amount of memory a script may consume (16MB)
    2. If you don’t have access to PHP.ini try adding this to an .htaccess file:
    php_value memory_limit 16M
    3. Talk to your host.

    You might also try disabling Plugins if you can’t increase PHP memory. I understand some plugin such as Google Sitemap use quite a bit of memory.

  8. 8
    cleek says:

    Allowed memory size of 33554432 bytes exhausted

    i’d assume your ISP has limited your account to a memory limit of 32MB, and for some reason, WP is hitting than when it tries to allocate a 120K file (which means it’s pretty much right on the edge of failure).

  9. 9
    mai naem says:

    Have no idea what you are asking about but I want to say y’all missed Calvinball and Brooks Brothers Riot in the Lexicon.

  10. 10
    Steeplejack says:

    I concur with Doctor Science. I haven’t doinked with WordPress in a while, and that was a one-time deal, but I would try what the good doctor suggests.

  11. 11
    Steeplejack says:

    Shorter version: It’s not you, it’s WordPress.

  12. 12
    sujal says:

    Dr. Science’s comment is right on. PHP limits the amount of memory it will use on the server. Your server looks to be set for 32M already, so you may need to have whoever maintains the server set it to 48M or 64M.

  13. 13
    Poicephalus says:

    a first step towards wisdom, recognition of one’s place.
    Best of luck with all the help you will receive from our motley crew. You’d be better off pasting the error message into your search-engine of choice.



  14. 14
    The Other Steve says:

    This is WordPress saying “It’s not you, it’s me.”

  15. 15
    Martin says:

    32MB is a pretty high PHP limit. See if the webmistress can look into places to optimize a bit. WP has a pretty bad reputation – is it known for being memory inefficient?

  16. 16
    AW says:

    Ask your Server Overloads to kill any zombie php / fcgi processes. Or just reboot the server, if that’s an option (it is on some virtual private servers).

  17. 17
    Hob says:

    That’s a really humungous amount of memory for WP to be using, which makes me think there’s a bug causing a script to chew up more and more memory till it inevitably dies. In that case, increasing the memory limit won’t help. I don’t know why it would’ve suddenly started breaking, if nothing was recently installed or upgraded. Basically I’m no goddamn help at all.

  18. 18
    bago says:

    Cleek is right about the system being close to failure when loading a 120k file gives you an allocation error. I’m guessing only the cms admins can make a page request that large though.

  19. 19
    sidereal says:

    Don’t ask to reboot the server. The PHP memory cap is a per-process limit. You can try jacking it up to 48, per sujal’s suggestion, but 32 is already a pretty big cap, and if a bunch of requests are going simultaneously and using a big chunk of memory, you’re likely to start running out of memory and/or swapping and/or crashing your server.

    I would investigate why your requests want to use such an absurd amount of memory. If your webmistress is very clever, this will involve dropping occasional error_log(memory_get_usage()) calls throughout the script to see where the memory usage is spiking up.

  20. 20

    Shorter Word Press: me no like you. me ban you. nothing you can do about it. bwahahaahaha.

  21. 21
    HankP says:

    cleek, Martin and sidereal have it right, you have 32M allocated to PHP and you’ve exhausted your memory pool. You can ask the webmaster/mistress to increase the PHP memory allocation. You can also ask them to install APC, it caches PHP requests, lowers the memory requirements for PHP and speeds up the site as well. WordPress (like Drupal at our site) can use a lot of PHP memory.

  22. 22

    If you’ve edited that document very heavily, it might be that wordpress is freaking out about 100s (or 1000s) of edits to the doc. In otherwords, it might be specific to the lexicon page.

    I’m not a php dev, but I am a dev…


  23. 23
    JGabriel says:


    Short version: Doctor Science and Cleek have the right take on it. It’s a memory allocation error; i.e., the application is looking for memory to work with and can’t find enough. Whether it’s looking for RAM, as Doc Science suggests, or Hard Drive space, as Cleek suggests, I don’t know.

    Shorter version: It’s a job for your webmistress.


  24. 24
    bago says:

    Cleek didn’t suggest hard drive space. He was just saying that if loading a 120k file pops your memory limit, you’re already on the edge of a cliff.

  25. 25
    JGabriel says:


    Cleek didn’t suggest hard drive space.

    You could be right. Cleek suggested that the problem was due to a limit set by the ISP, which I read as hard drive space rather than RAM. If not, my bad. Apologies for the confusion or incorrect assumption if I’m wrong.


  26. 26
    bago says:

    @JGabriel: The error clearly states that on line 1524 on the general_template.php script there is a memory allocation of 120k that pushes it past the defined limit of 32 mb (ish. . It’s 2^25th bytes allowed to be allocated, a weird number)

  27. 27
    MelodyMaker says:

    No. Upping the php limits is one wrong way to go. Remove them. ask the hosting co’s FAQ. do it at a high level, and it trickles down. if you’re lucky. take notes. Can’t fix it in WordPress. Or I’m wrong. thanks.

  28. 28
    mistermix says:

    Doctor Science has the right answer, but the number you want to use is 48M (and if that doesn’t work, 64M), as sujal points out. Hard drive space has nothing to do with it.

    After that’s done, your WordPress install will use more memory on the server. If your server doesn’t have enough RAM to handle the new, bigger B-J, your webmistress will need to adjust for that (buy a bigger slice, add more RAM to your server, whatever).

  29. 29
    Egypt Steve says:

    hey, you should put “bleg” in your lexicon — I assume a hybrid of “blog” and “beg???? Or was it just a misspelling.

  30. 30
    polyorchnid octopunch says:

    Dr. Science etc have the right answer. For the purposes of memory allocation on the server, RAM and HD space are basically the same thing… memory for the process comes from RAM, backed up by swap space on the hard drive.

    I’m with the people who suggest that perhaps there’s a script that’s eating up a lot of memory; it’s pretty easy to create memory leaks in long running processes if you’re not careful. As WP (which I have no experience with, in all truth) is a server process, there are long running scripts there in all likelihood.

    I’m going to agree that just upping the memory limit without knowing what’s chewing up the memory is a mistake… it only puts off the problem instead of solving it. It might be that there’s just too many toys on and there’s no memory leak, and it’s only because (as mentioned above) you have a large doc with a lot of edits being saved; one possible solution might be to turn down the undo level (though again, I’ve no experience with WP, so I don’t know if that’s possible, or even a feature). This is a case where you need someone that understands WP internals to take a look at your config and the libraries you’re loading (someone mentioned Googly stuff up above, for example) and do some app profiling and observation of it as it runs and see what they can figure out… if it turns out that your chosen set of libs plus the basic WP stuff runs up to 28MB but doesn’t grow, in fact turning up the memory limit on PHP to 48 MB might be the right solution.

  31. 31
    nick says:

    As I’m assuming that not many people working on the Balloon Juice system are programmers, I doubt there’s anybody who can go into the depths of WordPress’s PHP code to see what is filling up memory (objects, copies of arrays being passed around, etc.). Disabling a few plugins may help; there might be a few being run on the site that are taking up the 32 MB limit.

    But frankly, I’ve found that it’s easier to simply up the memory_limit setting in the php.ini file when analyzing similar issues. Frankly, when it comes down to it, WordPress is an open-source package that’s designed to be fairly simple to extend with plugins. That comes with a design that’s easier for a programmer to read than efficiency of memory usage. And adding memory is often cheaper than developer time these days.

    Understand that this is simply a memory limit setting for PHP programs; scripts that are using less than 32 MB per run will still use the same amount of RAM as before. It’s those scripts that go past those limits that we are worried about. In this case, editing the lexicon dictionary seems to surpass the limit, so it’s best to increase in small intervals until whatever you’re trying to do works.

    In other words, this is something the server administrator (or webmaster/webmistress) needs to take care of. There’s not much an end user can do at this point until you can actually edit the lexicon page.

  32. 32
    Chuck says:

    I’ve looked into WordPress’s code before. It’s some of the worst I’ve ever seen, and I’ve worked on MediaWiki which is full of ugly hacks. It not only uses no template layer and thus escapes nothing by default, leaving it wide open to XSS and CSRF attacks, there is virtually no .php file in there that doesn’t spit out some html as a side effect. Just changing themes can break code or open security holes. God only knows what it’s using for the db layer, but I have to imagine it’s full of SQL injection holes.

    You might be stuck with WP for the features it has and the fact that all your data’s in it, but never be under the illusion that it has any semblance of quality whatsoever.

  33. 33
    twiffer says:

    upping a memory allocation limit is a short term fix. if you’ve got a memory leak, you’ll wind up with the same problem again. eventually.

    i’m by no means an expert on the tech side (too much of a generalist, alas), but my job is managing troubleshooting, restoration of service and root cause analysis. if you’re going to go with the temp fix, make sure you use the time it buys to find and fix the actual problem.

  34. 34
    fishbane says:

    Chuck –

    That’s a bit harsh – WP isn’t *that* bad. You may prefer to use layer upon layer and play API poker, but that is generally incompatible with a design goal of running on cheap VPSes.

    If you know of XSS/injection/whatever attacks, by all means point them out. I kinda doubt you know of any, at least in recent versions, though; the code is public, highly used, and not all that complex. The incidence of actual exploits is higher than I like to see, but hardly the worst in the field.

    Back on topic, yes, science got it right.

  35. 35
    terry chay says:

    Actually upping the memory allocation probably won’t fix the problem. The PHP script used 33MB of memory to process it which should be enough unless it’s caught in some loop. Processing your post takes more resources than serving pages (especially since you turned on a caching plugin), but not THAT much more.

    BTW, PHP releases memory back to Apache after it finishes processing a request so memory leaks don’t hurt it permanently or affect other requests.

    I don’t think this is WordPress’s problem, it is more likely a poorly written plug-in or the install was hacked. (Disclaimer: I’m biased since I work for the company that developed it). The first thing you guys should do is upgrade your install from 2.7.1 to 2.8.4. Continuing to run 2.7.1 in a self-hosted install is just asking for trouble. ;-)

  36. 36
    vdibart says:

    What specific text are you trying to add to the page? For instance, if you keep trying to paste the same thing in and you get that message it’s possible that whatever you are trying to add is somehow involved. Is it always the same text that causes it or is it *any* text?

  37. 37
    p m says:

    this has happened to me using both WP 2.7 and 2.8.

    here are a few ways to fix the problem (at least temporarily).

    #1 on that list worked for me.

    good luck!

Comments are closed.