[mingw] gdb eat a lot of memory and slowly when start an inferior

[mingw] gdb eat a lot of memory and slowly when start an inferior

[asmwarrior]

I have two version of gdb build under mingw. One is build from gdb cvs 2012-01-19, and the other is from gdb cvs 2012-01-27.

The former one works OK, when I debug Codeblocks, the start the inferior(Codeblocks with many plugin dlls) time is about 30 seconds, and gdb eat about 130M memory when the inferior start-up(I can see it from Windows task manager).

The later one works badly, it takes more than 90 seconds to start the inferior, and gdb eat about 500+M memory.

I guess that the total debug information of all the Codeblocks.exe and many dlls were loaded to memory in the second case.

Any one can give a direction? I guess the commits between 2012-01-19 and 2012-01-27 cause this issue. Mostly the handling shared library patches?

Thanks.

asmwarrior
ollydbg from codeblocks' forum

Re: [mingw] gdb eat a lot of memory and slowly when start an inferior

[Joel Brobecker]

> I have two version of gdb build under mingw. One is build from gdb cvs
> 2012-01-19, and the other is from gdb cvs 2012-01-27.
[...]
> Any one can give a direction? I guess the commits between 2012-01-19
> and 2012-01-27 cause this issue. Mostly the handling shared library
> patches?

8 days worth of commits is a very small number. So if you have git,
you could try bisect'ing until you find the commit that's responsible.
That might help narrow down the source of the problem.

-- 
Joel

Re: [mingw] gdb eat a lot of memory and slowly when start an inferior

[xunxun]

于 2012/1/27 18:58, asmwarrior 写道:
> I have two version of gdb build under mingw. One is build from gdb cvs 
> 2012-01-19, and the other is from gdb cvs 2012-01-27.
>
> The former one works OK, when I debug Codeblocks, the start the 
> inferior(Codeblocks with many plugin dlls) time is about 30 seconds, 
> and gdb eat about 130M memory when the inferior start-up(I can see it 
> from Windows task manager).
>
> The later one works badly, it takes more than 90 seconds to start the 
> inferior, and gdb eat about 500+M memory.
>
> I guess that the total debug information of all the Codeblocks.exe and 
> many dlls were loaded to memory in the second case.
>
> Any one can give a direction? I guess the commits between 2012-01-19 
> and 2012-01-27 cause this issue. Mostly the handling shared library 
> patches?
You can try gdb without python to check if it is related with python 
modules?
>
> Thanks.
>
> asmwarrior
> ollydbg from codeblocks' forum


-- 
Best Regards,
xunxun

Re: [mingw] gdb eat a lot of memory and slowly when start an inferior

[asmwarrior]

On 2012-1-27 21:17, xunxun wrote:
> You can try gdb without python to check if it is related with python
> modules?
No, it is not related to python, because both two version of gdb has the same python enabled.
I'm currently doing bisect on gdb git.

At least this revision does not have problem:

Author: Jan Kratochvil
Date: 2012-1-25 4:56:33
Message:
gdb/

Code cleanup.
     * cli/cli-cmds.c (source_script_from_stream): Never fclose STREAM.
     Update the function comment for it.
     (source_script_with_search): Call make_cleanup_fclose for STREAM.
     * cli/cli-script.c (script_from_file): Do not call make_cleanup_fclose
     for STREAM.
----
Modified : gdb/ChangeLog
Modified : gdb/cli/cli-cmds.c
Modified : gdb/cli/cli-script.c

asmwarrior
ollydbg from codeblocks' forum

Re: [mingw] gdb eat a lot of memory and slowly when start an inferior

[asmwarrior]

On 2012-1-27 19:01, Joel Brobecker wrote:
>> I have two version of gdb build under mingw. One is build from gdb cvs
>> 2012-01-19, and the other is from gdb cvs 2012-01-27.
> [...]
>> Any one can give a direction? I guess the commits between 2012-01-19
>> and 2012-01-27 cause this issue. Mostly the handling shared library
>> patches?
> 8 days worth of commits is a very small number. So if you have git,
> you could try bisect'ing until you find the commit that's responsible.
> That might help narrow down the source of the problem.
>
Hi, Joel, I did what you suggest. Finally, I definitely found that this issue was introduced by your patch in:


Author: Joel Brobecker
Date: 2012-1-26 12:20:31
Message:
Ada: allow unqualified function names in linespecs

This is the meat, where we replace the old la_symbol_name_compare
language method with the new ada_get_symbol_name_match_p.
It fixes the problem when trying to insert a breakpoint on "+".

gdb/ChangeLog:

         * language.h (symbol_name_match_p_ftype): New typedef.
         (struct language_defn): Replace field la_symbol_name_compare
         by la_get_symbol_name_match_p.
         * ada-lang.c (ada_get_symbol_name_match_p): New function.
         (ada_language_defn): Use it.
         * linespec.c (struct symbol_matcher_data): New type.
         (iterate_name_matcher): Rewrite.
         (iterate_over_all_matching_symtabs): Pass a pointer to
         a symbol_matcher_data struct to expand_symtabs_matching
         instead of just the lookup name.
         * c-lang.c, d-lang.c, jv-lang.c, m2-lang.c, objc-lang.c,
         opencl-lang.c, p-lang.c, language.c: Delete field
         la_symbol_name_compare, and replace by NULL for new field
         la_get_symbol_name_match_p.
         * symfile.h (struct quick_symbol_functions): Update comment.
----
Modified : gdb/ChangeLog
Modified : gdb/ada-lang.c
Modified : gdb/c-lang.c
Modified : gdb/d-lang.c
Modified : gdb/f-lang.c
Modified : gdb/jv-lang.c
Modified : gdb/language.c
Modified : gdb/language.h
Modified : gdb/linespec.c
Modified : gdb/m2-lang.c
Modified : gdb/objc-lang.c
Modified : gdb/opencl-lang.c
Modified : gdb/p-lang.c
Modified : gdb/symfile.h


Can you have a look at this patch? Thanks.



asmwarrior
ollydbg from codeblocks' forum

Re: [mingw] gdb eat a lot of memory and slowly when start an inferior

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 350 bytes --]

> Hi, Joel, I did what you suggest. Finally, I definitely found that this issue was introduced by your patch in:
> 
> 
> Author: Joel Brobecker
> Date: 2012-1-26 12:20:31
> Message:
> Ada: allow unqualified function names in linespecs

Can you try the attached patch? This should restore the only effective
change I made for non-Ada units.

-- 
Joel

[-- Attachment #2: linespec.diff --]
[-- Type: text/x-diff, Size: 420 bytes --]

diff --git a/gdb/linespec.c b/gdb/linespec.c
index dc9dfc6..d0a35a4 100644
--- a/gdb/linespec.c
+++ b/gdb/linespec.c
@@ -365,7 +365,7 @@ iterate_over_all_matching_symtabs (const char *name,
   matcher_data.symbol_name_match_p =
     current_language->la_get_symbol_name_match_p != NULL
     ? current_language->la_get_symbol_name_match_p (name)
-    : strcmp_iw;
+    : strcmp_iw_ordered;
 
   ALL_PSPACES (pspace)
   {

Re: [mingw] gdb eat a lot of memory and slowly when start an inferior

[Joel Brobecker]

> Can you try the attached patch? This should restore the only effective
> change I made for non-Ada units.

Never mind. I think Jan found the source of the problem:
http://www.sourceware.org/ml/gdb-patches/2012-01/msg00953.html

-- 
Joel

Re: [mingw] gdb eat a lot of memory and slowly when start an inferior

[asmwarrior]

On 2012-1-28 3:08, Joel Brobecker wrote:
>> Can you try the attached patch? This should restore the only effective
>> change I made for non-Ada units.
> Never mind. I think Jan found the source of the problem:
> http://www.sourceware.org/ml/gdb-patches/2012-01/msg00953.html
>
Hi, Joel.

Thanks for the info.
Now I just test the latest gdb cvs code, and I can confirm that this issue is fixed.
Thank you!


asmwarrior
ollydbg from codeblocks' forum