* [mingw] gdb eat a lot of memory and slowly when start an inferior
@ 2012-01-27 10:54 asmwarrior
2012-01-27 11:01 ` Joel Brobecker
2012-01-27 13:17 ` xunxun
0 siblings, 2 replies; 8+ messages in thread
From: asmwarrior @ 2012-01-27 10:54 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [mingw] gdb eat a lot of memory and slowly when start an inferior
2012-01-27 10:54 [mingw] gdb eat a lot of memory and slowly when start an inferior asmwarrior
@ 2012-01-27 11:01 ` Joel Brobecker
2012-01-27 14:06 ` asmwarrior
[not found] ` <4F22AFF5.1000609@gmail.com>
2012-01-27 13:17 ` xunxun
1 sibling, 2 replies; 8+ messages in thread
From: Joel Brobecker @ 2012-01-27 11:01 UTC (permalink / raw)
To: asmwarrior; +Cc: gdb
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [mingw] gdb eat a lot of memory and slowly when start an inferior
2012-01-27 11:01 ` Joel Brobecker
@ 2012-01-27 14:06 ` asmwarrior
[not found] ` <4F22AFF5.1000609@gmail.com>
1 sibling, 0 replies; 8+ messages in thread
From: asmwarrior @ 2012-01-27 14:06 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb, Xun Xun
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
^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <4F22AFF5.1000609@gmail.com>]
* Re: [mingw] gdb eat a lot of memory and slowly when start an inferior
[not found] ` <4F22AFF5.1000609@gmail.com>
@ 2012-01-27 15:38 ` Joel Brobecker
2012-01-27 19:09 ` Joel Brobecker
0 siblings, 1 reply; 8+ messages in thread
From: Joel Brobecker @ 2012-01-27 15:38 UTC (permalink / raw)
To: asmwarrior; +Cc: gdb, Xun Xun
[-- 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)
{
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [mingw] gdb eat a lot of memory and slowly when start an inferior
2012-01-27 10:54 [mingw] gdb eat a lot of memory and slowly when start an inferior asmwarrior
2012-01-27 11:01 ` Joel Brobecker
@ 2012-01-27 13:17 ` xunxun
2012-01-27 13:30 ` asmwarrior
1 sibling, 1 reply; 8+ messages in thread
From: xunxun @ 2012-01-27 13:17 UTC (permalink / raw)
To: asmwarrior; +Cc: gdb
äº 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [mingw] gdb eat a lot of memory and slowly when start an inferior
2012-01-27 13:17 ` xunxun
@ 2012-01-27 13:30 ` asmwarrior
0 siblings, 0 replies; 8+ messages in thread
From: asmwarrior @ 2012-01-27 13:30 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-01-28 1:33 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-27 10:54 [mingw] gdb eat a lot of memory and slowly when start an inferior asmwarrior
2012-01-27 11:01 ` Joel Brobecker
2012-01-27 14:06 ` asmwarrior
[not found] ` <4F22AFF5.1000609@gmail.com>
2012-01-27 15:38 ` Joel Brobecker
2012-01-27 19:09 ` Joel Brobecker
2012-01-28 1:33 ` asmwarrior
2012-01-27 13:17 ` xunxun
2012-01-27 13:30 ` asmwarrior
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).