[Phpmyadmin-devel] ready for alpha 4.0 ?

[Dron Rathore]

> Message: 3
> Date: Sat, 12 Jan 2013 15:15:15 +0530
> From: Madhura Jayaratne <madhura.cj at gmail.com>
> Subject: Re: [Phpmyadmin-devel] ready for 4.0.0-alpha1 ?
> To: phpmyadmin-devel at lists.sourceforge.net
> Message-ID:
>         <
CAC5h4aN7y6FO1QsDkQCbf5FvH7sPYkqSP5fJ92izTcaRM+rd6w at mail.gmail.com>

> On Wed, Jan 9, 2013 at 9:06 PM, Michal ?iha? <michal at cihar.com> wrote:
>
>> Hi
>>
>> Dne Wed, 9 Jan 2013 20:46:54 +0530
>> Madhura Jayaratne <madhura.cj at gmail.com> napsal(a):
>>
>> > I tried bisecting and the first bad commit is 44c12545fc863. Still I
have
>> > no clue what's causing this.
>>
>> Maybe js/get_scripts.js.php is genererr?
>>
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)

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.

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:
Function foo(){ some code }
Will become:
Xvsh7 at d_djdij .... or something else.
>>-
>>         Michal ?iha? | http://cihar.com | http://blog.cihar.com
>
>
> I am somewhat confused with the what I noticed. The problem seems to be
> related to the size of the JavaScript loaded.
> For example, if I divide the JavaScript files loaded in the initial call
to
> js/get_scripts.js between two calls with the following code (around Line
74
> of libraries/Script.class.php), the problem goes away.
>
>         $mid = floor(count($params) / 2);
>         $static_scripts = sprintf(
>             "<script type='text/javascript'
> src='js/get_scripts.js.php?%s'></script>",
>             implode("&", array_slice($params, 0, $mid))
>         );
>         $static_scripts .= sprintf(
>             "<script type='text/javascript'
> src='js/get_scripts.js.php?%s'></script>",
>             implode("&", array_slice($params, $mid))
>         );
>
>
This surely works on my old dumb box(Pentium IV) where the MIPS concern the
Memory limits.

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.

Regards
Dron Rathore
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20130113/8f162dc9/attachment.html>