<br>> Message: 3<br>> Date: Sat, 12 Jan 2013 15:15:15 +0530<br>> From: Madhura Jayaratne <<a href="mailto:madhura.cj@gmail.com">madhura.cj@gmail.com</a>><br>> Subject: Re: [Phpmyadmin-devel] ready for 4.0.0-alpha1 ?<br>
> To: <a href="mailto:phpmyadmin-devel@lists.sourceforge.net">phpmyadmin-devel@lists.sourceforge.net</a><br>> Message-ID:<br>> <<a href="mailto:CAC5h4aN7y6FO1QsDkQCbf5FvH7sPYkqSP5fJ92izTcaRM%2Brd6w@mail.gmail.com">CAC5h4aN7y6FO1QsDkQCbf5FvH7sPYkqSP5fJ92izTcaRM+rd6w@mail.gmail.com</a>><br>
<br>> On Wed, Jan 9, 2013 at 9:06 PM, Michal ?iha? <<a href="mailto:michal@cihar.com">michal@cihar.com</a>> wrote:<br>><br>>> Hi<br>>><br>>> Dne Wed, 9 Jan 2013 20:46:54 +0530<br>>> Madhura Jayaratne <<a href="mailto:madhura.cj@gmail.com">madhura.cj@gmail.com</a>> napsal(a):<br>
>><br>>> > I tried bisecting and the first bad commit is 44c12545fc863. Still I have<br>>> > no clue what's causing this.<br>>><br>>> Maybe js/get_scripts.js.php is genererr?<br>>><br>
When large files are gzipped and transported, all together, the Obex limits the amount of memory provided to the zipping thread and hence a memory lekage occurs(see the php's bug : Memory Lekage)<br><br>Well, out of us only few are able to reproduce the problem because we have set the Memory limit value a bit higher on php.ini file or sometimes its the type of processor which can cause this to happen(was in my case) where MIPS limit can delay the process and in turn causing Memory Lekage and number of process running at that instance can also cause this to happen.<br>
<br>Now few would wonder that if a memory Lekage occurs then why on this earth php never generate the error or warning(even in the log file), this is because this whole process occurs out of the notice of php runtime management. The zipping module when runs out of memory and in the meantime if another process need resources, php forcibly deallocate a part of memory that is in use by the Largest Space Occuping thread. In turn the zipped file misses few token which in turn causes a part of zipped output being unzipped at browser end with invalid output I.e. A code like this:<br>
Function foo(){ some code }<br> Will become:<br>Xvsh7@d_djdij .... or something else.<br>>>-<br>>> Michal ?iha? | <a href="http://cihar.com">http://cihar.com</a> | <a href="http://blog.cihar.com">http://blog.cihar.com</a><br>
><br>><br>> I am somewhat confused with the what I noticed. The problem seems to be<br>> related to the size of the JavaScript loaded.<br>> For example, if I divide the JavaScript files loaded in the initial call to<br>
> js/get_scripts.js between two calls with the following code (around Line 74<br>> of libraries/Script.class.php), the problem goes away.<br>><br>> $mid = floor(count($params) / 2);<br>> $static_scripts = sprintf(<br>
> "<script type='text/javascript'<br>> src='js/get_scripts.js.php?%s'></script>",<br>> implode("&", array_slice($params, 0, $mid))<br>> );<br>
> $static_scripts .= sprintf(<br>> "<script type='text/javascript'<br>> src='js/get_scripts.js.php?%s'></script>",<br>> implode("&", array_slice($params, $mid))<br>
> );<br>><br>> <br> This surely works on my old dumb box(Pentium IV) where the MIPS concern the Memory limits.<br><br>Conclusion: This is not a coding bug, instead its a system concern, one of my friends AMD is also having trouble. So compacting the files is a good approach, but we should also take care of some System Level approaches that can limit us in applying our idea.<br>
<br>Regards<br>Dron Rathore