attributes array randomly dropping values after 3rd loop

[Greywacke]

hi all,here is the code that sets the array:

$attribsarr = array();//reset($HTTP_POST_VARS);foreach ($_POST as $key => $val) {					// loop quote attributes	if ($key!="submit"&&$key!="contact_name"&&		$key!="email"&&$key!="contact_cell"&&		$key!="province"&&$key!="city_town"&&		$key!="add_reqs"&&$key!="service_id"&&		$key!="quotations_reqd") {			$attribsarr[$key] = $val;	}}

the following screenshot shows the emails sent:Quote Requests Selectedi do not believe the array is set to empty, the first 3 mails contain the value.however the 4th email does not.why would this array be emptied spontaneously?

[justsomeguy]

why would this array be emptied spontaneously?

It wouldn't be, they don't work that way.

i do not believe the array is set to empty

Have you verified that?I'm not sure what I'm looking at in that screenshot or how the code relates to it though.

[Greywacke]

and here is where it is implemented in the handler, several lines down:

$body = getFile("../templat/lead.html");	// load mail template// approximately 191 lines missing, none of them containing $attribsarr$body = str_replace("%PRODUCTMAKEMODEL%",	$attribsarr["vehicle_make_model"].	" - ".	$attribsarr["canopy_style"],$body);		// insert make/model

yes justsomeguy, it is not empty initially. see the screenshot with the first three leads. it seems that line of code just isn't running on the 4th loop :S$attribsarr is used in the 191 lines, but it is not being emptied according to the code up to loop 4, and the last 4 lines of code above. could it be as result of a memory leakage possibly? it is not as result of a script timeout, because this is set to 0 at the start of the script with

set_time_limit(0);

, in the event of many e-mail's being sent as result of many suppliers matching the quote request.can the memory space allocated for a php script be set in the script? let me google on this...okay. i've found the following:

The stack is a place in the computer memory where all the variables that are declared and initialized before runtime are stored. The heap is the section of computer memory where all the variables created or initialized at runtime are stored.

on the first result for "memory space allocated php" located at Maxi-Pedia Heap & Stack Definition.let me read on with php matches...

[Greywacke]

okay ive come up with setting the memory limit to 32M as follows just after setting the timeout to 0.

ini_set(′memory_limit′, ′32M′);

but even after the second submission, it does not fix that "memory leak"...i guess i need to get to bed now, will work on this issue further in the morning.

[justsomeguy]

This isn't a memory problem, I've never seen a memory problem while using PHP. I think the default memory limit is now set to 128MB, maybe 256. These things don't happen for anomalous reasons (at least not anything that is repeatable), there's a specific piece of code doing this. I haven't seen that code in what you've posted so far though, but consider this:$body = str_replace("%PRODUCTMAKEMODEL%", $attribsarr["vehicle_make_model"]. " - ". $attribsarr["canopy_style"],$body);If that code even ran at all, you would not see "%PRODUCTMAKEMODEL%" in the subject line, at a minimum you would see a hyphen with spaces on either side of it. That line isn't being executed at all, it's not a question about what is or is not in $attribsarr. Another possibility is that the code does execute but "%PRODUCTMAKEMODEL%" does not exist in the target string.

[Greywacke]

ISSUE RESOLVED!!! :)i realised that the quote request sent with the missing value, was as result of the line of code not running.upon closer inspection of the code, it turned out that the line was missing alltogether, hence the flag %PRODUCTMAKEMODEL% still being in the subject!i repaired and tested this, and it works now :)lookie:IT WORKS! lol, i've got to get out of the nasty habit of stressing when my coding does not want to work... the difference was it was working on the sandbox, where that line exists.that line was missing in the production - but not anymore

[justsomeguy]

The most problematic things people do when debugging are assuming that the code is correct and that the data is what they think it is. About half of the things people post about here are issues where they just assume the code is correct, and something must be broken with PHP. In my 7 years of using PHP, I can't remember a single time that was the case for me, it's always either the code being incorrect, or the data not being what I thought it was. There are definitely bugs in PHP, but never assume that you are dealing with a PHP bug when you're debugging, always assume the bug is in your code, not PHP. If you think you are dealing with a PHP bug, if the problem is repeatable and is demonstrated with a test case (e.g., if you rewrite your problematic code to only do the one thing, does the problem still exist?), then look in the PHP manual for the functions you're dealing with and check the user comments. If you've run into a bug, chances are you're not the first and there's going to be someone posting comments in the manual about what causes it and how to work around it. If you don't find it there, you can always post a summary of your problem, along with your test code which demonstrates the problem, to the PHP bug tracker and get a determination of whether or not it really is a bug.Don't post problems like people do here in the bug tracker though, that is only for reporting bugs in PHP itself, not in user applications.At least half of the problems posted here are because people assume that the code is correct and that the data is what they think it is, which is nearly always the problem. The other half are generally from people who just don't understand the code in the first place.