On Ilia Alshanetsky's blog today, there's this new post where he explains some interesting "implications" of the use of var_export and print_r and the potential for problems with their combined use.

Yesterday I've discovered an "interesting" implication of using user input inside var_export() and print_r() functions. To those who have never used the two, a brief overview of their functionality. The var_export() function takes a variable and represents the data found within as a valid PHP string. The print_r() function is similar in function, except the returned data is intended for debugging and not storage.

Herein lies the problem, when it comes to storing the data, this is done by enabling output buffering of the content without a set buffer size limit. Consequently, by forcing the function to generate a massive string it is possible to launch a denial of service attack aimed at exhausting both processor and memory.

So, basically - var_export returning a string, print_r returning a string as well, and something like a str_repeat combined with a little output buffering could cause big problems for any web host out there. He suggests one method to help avoid this - just not use the var_export/print_r function with the optional second parameters. He also hints at using count() to check the input and ensure that you're getting what you want...