[LTP] [PATCH] max_map_count: corrected max_map_count condition

[LTP] [PATCH] max_map_count: corrected max_map_count condition

[Stanislav Kholmanskikh]

From: Stanislav kholmanskikh <stanislav.kholmanskikh@oracle.com>

* kernel test for max_map_count_sysctl is:
   /* Too many mappings? */
   if (mm->map_count > sysctl_max_map_count)
     return -ENOMEM;
  so in LTP test map_count should be greater than max_map_count by 1

* only [vsyscall] is allocated without incrementing mm->map_count

Author: Bob Picco <bob.picco@oracle.com>

Signed-off-by: Stanislav kholmanskikh <stanislav.kholmanskikh@oracle.com>
---
 testcases/kernel/mem/tunable/max_map_count.c |   41 +++++++++++++++++--------
 1 files changed, 28 insertions(+), 13 deletions(-)

diff --git a/testcases/kernel/mem/tunable/max_map_count.c b/testcases/kernel/mem/tunable/max_map_count.c
index e948868..01fbe5e 100644
--- a/testcases/kernel/mem/tunable/max_map_count.c
+++ b/testcases/kernel/mem/tunable/max_map_count.c
@@ -14,20 +14,16 @@
  * The program trys to invoke mmap() endless until triggering MAP_FAILED,
  * then read the process's maps file /proc/[pid]/maps, save the line number
  * to map_count variable, and compare it with /proc/sys/vm/max_map_count,
- * map_count should less than max_map_count.
- * Note: There are two special vmas VDSO and VSYSCALL, which are allocated
- * via install_special_mapping(), install_specail_mapping() allows the VMAs
- * to be allocated and inserted without checking the sysctl_map_map_count,
- * and each /proc/<pid>/maps has both at the end:
- * # cat /proc/self/maps
+ * map_count should be greater than max_map_count by 1;
+ *
+ * Note: On some architectures there is a special vma VSYSCALL, which
+ * is allocated without incrementing mm->map_count variable. On these
+ * architectures each /proc/<pid>/maps has at the end:
  * ...
  * ...
- * 7fff7b9ff000-7fff7ba00000 r-xp 00000000 00:00 0           [vdso]
  * ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0   [vsyscall]
  *
- * so during comparing with map_count and /proc/sys/vm/max_map_count,
- * we should except the two special vmas from map_count:
- * map_count -= 2;
+ * so we ignore this line during /proc/[pid]/maps reading.
  *
  * ********************************************************************
  * Copyright (C) 2012 Red Hat, Inc.
@@ -121,6 +117,21 @@ void cleanup(void)
 	TEST_CLEANUP;
 }
 
+/* This is a filter to exclude map entries which aren't accounted
+ * for in the vm_area_struct's map_count.
+ */
+#if defined(__x86_64__) || defined(__x86__)
+static int filter_map(char *buf)
+{
+	return strcmp(buf, "[vsyscall]") == 0;
+}
+#else
+static int filter_map(char *buf)
+{
+	return 0;
+}
+#endif
+
 static long count_maps(pid_t pid)
 {
 	FILE *fp;
@@ -136,8 +147,7 @@ static long count_maps(pid_t pid)
 	while (getline(&line, &len, fp) != -1) {
 		/* exclude vdso and vsyscall */
 		if (sscanf(line, "%*p-%*p %*4s %*p %*2d:%*2d %*d %s", buf) ==
-		    1 && ((strcmp(buf, "[vdso]") == 0) ||
-			  (strcmp(buf, "[vsyscall]") == 0)))
+				1 && filter_map(buf))
 			continue;
 		map_count++;
 	}
@@ -202,7 +212,12 @@ static void max_map_count_test(void)
 			tst_brkm(TBROK, cleanup, "child did not stopped");
 
 		map_count = count_maps(pid);
-		if (map_count == max_maps)
+		/* Note max_maps will be exceeded by one for
+		 * the sysctl setting of max_map_count. This
+		 * is the mm failure point at the time of
+		 * writing this COMMENT!
+		*/
+		if (map_count == (max_maps + 1))
 			tst_resm(TPASS, "%ld map entries in total "
 				 "as expected.", max_maps);
 		else
-- 
1.7.1


------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] max_map_count: corrected max_map_count condition

[Caspar Zhang]

On 07/30/2013 09:47 PM, Stanislav Kholmanskikh wrote:
> From: Stanislav kholmanskikh <stanislav.kholmanskikh@oracle.com>
>
> * kernel test for max_map_count_sysctl is:
>     /* Too many mappings? */
>     if (mm->map_count > sysctl_max_map_count)
>       return -ENOMEM;
>    so in LTP test map_count should be greater than max_map_count by 1
>
> * only [vsyscall] is allocated without incrementing mm->map_count
>
> Author: Bob Picco <bob.picco@oracle.com>
>
> Signed-off-by: Stanislav kholmanskikh <stanislav.kholmanskikh@oracle.com>

Acked-by: Caspar Zhang <caspar@casparzhang.com>

> ---
>   testcases/kernel/mem/tunable/max_map_count.c |   41 +++++++++++++++++--------
>   1 files changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/testcases/kernel/mem/tunable/max_map_count.c b/testcases/kernel/mem/tunable/max_map_count.c
> index e948868..01fbe5e 100644
> --- a/testcases/kernel/mem/tunable/max_map_count.c
> +++ b/testcases/kernel/mem/tunable/max_map_count.c
> @@ -14,20 +14,16 @@
>    * The program trys to invoke mmap() endless until triggering MAP_FAILED,
>    * then read the process's maps file /proc/[pid]/maps, save the line number
>    * to map_count variable, and compare it with /proc/sys/vm/max_map_count,
> - * map_count should less than max_map_count.
> - * Note: There are two special vmas VDSO and VSYSCALL, which are allocated
> - * via install_special_mapping(), install_specail_mapping() allows the VMAs
> - * to be allocated and inserted without checking the sysctl_map_map_count,
> - * and each /proc/<pid>/maps has both at the end:
> - * # cat /proc/self/maps
> + * map_count should be greater than max_map_count by 1;
> + *
> + * Note: On some architectures there is a special vma VSYSCALL, which
> + * is allocated without incrementing mm->map_count variable. On these
> + * architectures each /proc/<pid>/maps has at the end:
>    * ...
>    * ...
> - * 7fff7b9ff000-7fff7ba00000 r-xp 00000000 00:00 0           [vdso]
>    * ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0   [vsyscall]
>    *
> - * so during comparing with map_count and /proc/sys/vm/max_map_count,
> - * we should except the two special vmas from map_count:
> - * map_count -= 2;
> + * so we ignore this line during /proc/[pid]/maps reading.
>    *
>    * ********************************************************************
>    * Copyright (C) 2012 Red Hat, Inc.
> @@ -121,6 +117,21 @@ void cleanup(void)
>   	TEST_CLEANUP;
>   }
>
> +/* This is a filter to exclude map entries which aren't accounted
> + * for in the vm_area_struct's map_count.
> + */
> +#if defined(__x86_64__) || defined(__x86__)
> +static int filter_map(char *buf)
> +{
> +	return strcmp(buf, "[vsyscall]") == 0;
> +}
> +#else
> +static int filter_map(char *buf)
> +{
> +	return 0;
> +}
> +#endif
> +
>   static long count_maps(pid_t pid)
>   {
>   	FILE *fp;
> @@ -136,8 +147,7 @@ static long count_maps(pid_t pid)
>   	while (getline(&line, &len, fp) != -1) {
>   		/* exclude vdso and vsyscall */
>   		if (sscanf(line, "%*p-%*p %*4s %*p %*2d:%*2d %*d %s", buf) ==
> -		    1 && ((strcmp(buf, "[vdso]") == 0) ||
> -			  (strcmp(buf, "[vsyscall]") == 0)))
> +				1 && filter_map(buf))
>   			continue;
>   		map_count++;
>   	}
> @@ -202,7 +212,12 @@ static void max_map_count_test(void)
>   			tst_brkm(TBROK, cleanup, "child did not stopped");
>
>   		map_count = count_maps(pid);
> -		if (map_count == max_maps)
> +		/* Note max_maps will be exceeded by one for
> +		 * the sysctl setting of max_map_count. This
> +		 * is the mm failure point at the time of
> +		 * writing this COMMENT!
> +		*/
> +		if (map_count == (max_maps + 1))
>   			tst_resm(TPASS, "%ld map entries in total "
>   				 "as expected.", max_maps);
>   		else
>


------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] max_map_count: corrected max_map_count condition

[Zhouping Liu]

On 07/30/2013 09:47 PM, Stanislav Kholmanskikh wrote:
> From: Stanislav kholmanskikh <stanislav.kholmanskikh@oracle.com>
>
> * kernel test for max_map_count_sysctl is:
>     /* Too many mappings? */
>     if (mm->map_count > sysctl_max_map_count)
>       return -ENOMEM;
>    so in LTP test map_count should be greater than max_map_count by 1
>
> * only [vsyscall] is allocated without incrementing mm->map_count
>
> Author: Bob Picco <bob.picco@oracle.com>
>
> Signed-off-by: Stanislav kholmanskikh <stanislav.kholmanskikh@oracle.com>
> ---
>   testcases/kernel/mem/tunable/max_map_count.c |   41 +++++++++++++++++--------
>   1 files changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/testcases/kernel/mem/tunable/max_map_count.c b/testcases/kernel/mem/tunable/max_map_count.c
> index e948868..01fbe5e 100644
> --- a/testcases/kernel/mem/tunable/max_map_count.c
> +++ b/testcases/kernel/mem/tunable/max_map_count.c
> @@ -14,20 +14,16 @@
>    * The program trys to invoke mmap() endless until triggering MAP_FAILED,
>    * then read the process's maps file /proc/[pid]/maps, save the line number
>    * to map_count variable, and compare it with /proc/sys/vm/max_map_count,
> - * map_count should less than max_map_count.
> - * Note: There are two special vmas VDSO and VSYSCALL, which are allocated
> - * via install_special_mapping(), install_specail_mapping() allows the VMAs
> - * to be allocated and inserted without checking the sysctl_map_map_count,
> - * and each /proc/<pid>/maps has both at the end:
> - * # cat /proc/self/maps
> + * map_count should be greater than max_map_count by 1;
> + *
> + * Note: On some architectures there is a special vma VSYSCALL, which
> + * is allocated without incrementing mm->map_count variable. On these
> + * architectures each /proc/<pid>/maps has at the end:
>    * ...
>    * ...
> - * 7fff7b9ff000-7fff7ba00000 r-xp 00000000 00:00 0           [vdso]


Why you removed VDSO map? AFAIK VDSO map is also calculated by 
install_special_maping(),
so the VMA  is allocated and inserted without checking the 
sysctl_max_map_count.

Thanks,
Zhouping

>    * ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0   [vsyscall]
>    *
> - * so during comparing with map_count and /proc/sys/vm/max_map_count,
> - * we should except the two special vmas from map_count:
> - * map_count -= 2;
> + * so we ignore this line during /proc/[pid]/maps reading.
>    *
>    * ********************************************************************
>    * Copyright (C) 2012 Red Hat, Inc.
> @@ -121,6 +117,21 @@ void cleanup(void)
>   	TEST_CLEANUP;
>   }
>   
> +/* This is a filter to exclude map entries which aren't accounted
> + * for in the vm_area_struct's map_count.
> + */
> +#if defined(__x86_64__) || defined(__x86__)
> +static int filter_map(char *buf)
> +{
> +	return strcmp(buf, "[vsyscall]") == 0;
> +}
> +#else
> +static int filter_map(char *buf)
> +{
> +	return 0;
> +}
> +#endif
> +
>   static long count_maps(pid_t pid)
>   {
>   	FILE *fp;
> @@ -136,8 +147,7 @@ static long count_maps(pid_t pid)
>   	while (getline(&line, &len, fp) != -1) {
>   		/* exclude vdso and vsyscall */
>   		if (sscanf(line, "%*p-%*p %*4s %*p %*2d:%*2d %*d %s", buf) ==
> -		    1 && ((strcmp(buf, "[vdso]") == 0) ||
> -			  (strcmp(buf, "[vsyscall]") == 0)))
> +				1 && filter_map(buf))
>   			continue;
>   		map_count++;
>   	}
> @@ -202,7 +212,12 @@ static void max_map_count_test(void)
>   			tst_brkm(TBROK, cleanup, "child did not stopped");
>   
>   		map_count = count_maps(pid);
> -		if (map_count == max_maps)
> +		/* Note max_maps will be exceeded by one for
> +		 * the sysctl setting of max_map_count. This
> +		 * is the mm failure point at the time of
> +		 * writing this COMMENT!
> +		*/
> +		if (map_count == (max_maps + 1))
>   			tst_resm(TPASS, "%ld map entries in total "
>   				 "as expected.", max_maps);
>   		else


------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] max_map_count: corrected max_map_count condition

[Stanislav Kholmanskikh]

On 08/05/2013 07:16 AM, Zhouping Liu wrote:
> On 07/30/2013 09:47 PM, Stanislav Kholmanskikh wrote:
>> From: Stanislav kholmanskikh <stanislav.kholmanskikh@oracle.com>
>>
>> * kernel test for max_map_count_sysctl is:
>>     /* Too many mappings? */
>>     if (mm->map_count > sysctl_max_map_count)
>>       return -ENOMEM;
>>    so in LTP test map_count should be greater than max_map_count by 1
>>
>> * only [vsyscall] is allocated without incrementing mm->map_count
>>
>> Author: Bob Picco <bob.picco@oracle.com>
>>
>> Signed-off-by: Stanislav kholmanskikh 
>> <stanislav.kholmanskikh@oracle.com>
>> ---
>>   testcases/kernel/mem/tunable/max_map_count.c |   41 
>> +++++++++++++++++--------
>>   1 files changed, 28 insertions(+), 13 deletions(-)
>>
>> diff --git a/testcases/kernel/mem/tunable/max_map_count.c 
>> b/testcases/kernel/mem/tunable/max_map_count.c
>> index e948868..01fbe5e 100644
>> --- a/testcases/kernel/mem/tunable/max_map_count.c
>> +++ b/testcases/kernel/mem/tunable/max_map_count.c
>> @@ -14,20 +14,16 @@
>>    * The program trys to invoke mmap() endless until triggering 
>> MAP_FAILED,
>>    * then read the process's maps file /proc/[pid]/maps, save the 
>> line number
>>    * to map_count variable, and compare it with 
>> /proc/sys/vm/max_map_count,
>> - * map_count should less than max_map_count.
>> - * Note: There are two special vmas VDSO and VSYSCALL, which are 
>> allocated
>> - * via install_special_mapping(), install_specail_mapping() allows 
>> the VMAs
>> - * to be allocated and inserted without checking the 
>> sysctl_map_map_count,
>> - * and each /proc/<pid>/maps has both at the end:
>> - * # cat /proc/self/maps
>> + * map_count should be greater than max_map_count by 1;
>> + *
>> + * Note: On some architectures there is a special vma VSYSCALL, which
>> + * is allocated without incrementing mm->map_count variable. On these
>> + * architectures each /proc/<pid>/maps has at the end:
>>    * ...
>>    * ...
>> - * 7fff7b9ff000-7fff7ba00000 r-xp 00000000 00:00 0 [vdso]
>
>
> Why you removed VDSO map? AFAIK VDSO map is also calculated by 
> install_special_maping(),
> so the VMA  is allocated and inserted without checking the 
> sysctl_max_map_count.
>

Sorry, I've missed your message. Please take a look at my message to 
Cyril about this.


> Thanks,
> Zhouping
>
>>    * ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0   
>> [vsyscall]
>>    *
>> - * so during comparing with map_count and /proc/sys/vm/max_map_count,
>> - * we should except the two special vmas from map_count:
>> - * map_count -= 2;
>> + * so we ignore this line during /proc/[pid]/maps reading.
>>    *
>>    * 
>> ********************************************************************
>>    * Copyright (C) 2012 Red Hat, Inc.
>> @@ -121,6 +117,21 @@ void cleanup(void)
>>       TEST_CLEANUP;
>>   }
>>   +/* This is a filter to exclude map entries which aren't accounted
>> + * for in the vm_area_struct's map_count.
>> + */
>> +#if defined(__x86_64__) || defined(__x86__)
>> +static int filter_map(char *buf)
>> +{
>> +    return strcmp(buf, "[vsyscall]") == 0;
>> +}
>> +#else
>> +static int filter_map(char *buf)
>> +{
>> +    return 0;
>> +}
>> +#endif
>> +
>>   static long count_maps(pid_t pid)
>>   {
>>       FILE *fp;
>> @@ -136,8 +147,7 @@ static long count_maps(pid_t pid)
>>       while (getline(&line, &len, fp) != -1) {
>>           /* exclude vdso and vsyscall */
>>           if (sscanf(line, "%*p-%*p %*4s %*p %*2d:%*2d %*d %s", buf) ==
>> -            1 && ((strcmp(buf, "[vdso]") == 0) ||
>> -              (strcmp(buf, "[vsyscall]") == 0)))
>> +                1 && filter_map(buf))
>>               continue;
>>           map_count++;
>>       }
>> @@ -202,7 +212,12 @@ static void max_map_count_test(void)
>>               tst_brkm(TBROK, cleanup, "child did not stopped");
>>             map_count = count_maps(pid);
>> -        if (map_count == max_maps)
>> +        /* Note max_maps will be exceeded by one for
>> +         * the sysctl setting of max_map_count. This
>> +         * is the mm failure point at the time of
>> +         * writing this COMMENT!
>> +        */
>> +        if (map_count == (max_maps + 1))
>>               tst_resm(TPASS, "%ld map entries in total "
>>                    "as expected.", max_maps);
>>           else
>


------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] max_map_count: corrected max_map_count condition

[chrubis]

Hi!
> * kernel test for max_map_count_sysctl is:
>    /* Too many mappings? */
>    if (mm->map_count > sysctl_max_map_count)
>      return -ENOMEM;

Hmm, that looks like we allow the map_count to became one greater than
max_map_count, is this known bug?

>   so in LTP test map_count should be greater than max_map_count by 1
>
> * only [vsyscall] is allocated without incrementing mm->map_count

That also looks strange, do you know why one is allocated without
incrementing it and another with?

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] max_map_count: corrected max_map_count condition

[chrubis]

Hi!
> Guys, could anybody approve or disapprove this? I'm not sure where to go 
> to complete this subject.

I have this in my TODO, stay tuned.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] max_map_count: corrected max_map_count condition

[Wanlong Gao]

On 08/14/2013 04:28 PM, Zhouping Liu wrote:
> On 08/14/2013 01:32 PM, Stanislav Kholmanskikh wrote:
>>
>> On 08/14/2013 07:56 AM, Zhouping Liu wrote:
>>> On 08/13/2013 09:29 PM, Stanislav Kholmanskikh wrote:
>>>>
>>>> On 08/06/2013 10:52 AM, Stanislav Kholmanskikh wrote:
>>>>> On 08/05/2013 07:41 PM, chrubis@suse.cz wrote:
>>>>>> Hi!
>>>>> Hi, Cyril.
>>>>>>> * kernel test for max_map_count_sysctl is:
>>>>>>>      /* Too many mappings? */
>>>>>>>      if (mm->map_count > sysctl_max_map_count)
>>>>>>>        return -ENOMEM;
>>>>>> Hmm, that looks like we allow the map_count to became one greater 
>>>>>> than
>>>>>> max_map_count, is this known bug?
>>>>> I'm not sure whether this is a bug or feature but in fact mm/mmap.c 
>>>>> contains
>>>>> this strict condition.
>>>>>
>>>>>>>     so in LTP test map_count should be greater than max_map_count 
>>>>>>> by 1
>>>>>>>
>>>>>>> * only [vsyscall] is allocated without incrementing mm->map_count
>>>>>> That also looks strange, do you know why one is allocated without
>>>>>> incrementing it and another with?
>>>>>>
>>>>> [vdso] is allocated this way:
>>>>> 1) load_elf_binary (fs/binfmt_elf.c)
>>>>> 2) arch_setup_additional_pages (arch/x86/vdso/vdso32-setup.c)
>>>>> 3) install_special_mapping (mm/mmap.c)
>>>>> 4) insert_vm_struct (mm/mmap.c)
>>>>> 5) vma_link (mm/mmap.c) increases mm->map_count++
>>>
>>> Sorry for lately replying, as I'm a little busy these days...
>>>
>>> we all know (you have explained) VDSO vma is inserted by 
>>> install_special_mapping(), and the sysctl_max_map_count
>>> don't check the special vma, that's the reason why map_count is to 
>>> became one greater than max_map_count,
>>
>> The function install_special_mapping() __does__ increase mm->map_count.
>> [vdso] is mapped one of the first vmas when a binary is executed so 
>> it's not a problem or bug that sysctl_max_map_count is not checked in
>> install_special_mapping().
> 
> yeah, it sounds reasonable.
> 
>>
>> So we should not filter out [vdso] string from /proc/[pid]/maps (as we 
>> have in git test version).
>>
>> I mean that the reason why map_count could be one greater than 
>> max_map_count is not related to [vdso] or [vsyscall]. It's caused by 
>> the kernel
>> test I posted above.
> 
> I think so after I recheck the code again and again... sorry for the 
> misunderstanding.
> 
> so your patch looks good for me.
> 
> Reviewed-by: Zhouping Liu <zliu@redhat.com>

Applied, thank you all involved.

Wanlong Gao

> 
> Thanks,
> Zhouping
> 
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead. 
> Download for free and get started troubleshooting in minutes. 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list
> 


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list