* Re: [RFA] Fix memory leak in windows_xfer_shared_libraries [not found] <50c9b7e6.25f2440a.3810.3771SMTPIN_ADDED_BROKEN@mx.google.com> @ 2012-12-13 20:16 ` Pedro Alves 2012-12-14 7:53 ` Pierre Muller 0 siblings, 1 reply; 11+ messages in thread From: Pedro Alves @ 2012-12-13 20:16 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches On 12/13/2012 11:11 AM, Pierre Muller wrote: > --- windows-nat.c 13 Nov 2012 09:46:10 -0000 1.236 > +++ windows-nat.c 13 Dec 2012 10:54:18 -0000 > @@ -2411,11 +2411,11 @@ windows_xfer_shared_libraries (struct ta > buf = obstack_finish (&obstack); > len_avail = strlen (buf); > if (offset >= len_avail) > - return 0; > - > - if (len > len_avail - offset) > + len= 0 > + else if (len > len_avail - offset) > len = len_avail - offset; > - memcpy (readbuf, buf + offset, len); > + if (len > 0) > + memcpy (readbuf, buf + offset, len); > You can avoid the last if by writing as: if (offset >= len_avail) len = 0; else { if (len > len_avail - offset) len = len_avail - offset; memcpy (readbuf, buf + offset, len); } I'd prefer that, but patch is okay either way. > obstack_free (&obstack, NULL); > return len; > > I was also wondering if it would not be better to keep the obstack in > between the two calls, but that would probably require some static variable > :( That'd be fine. We actually do that in some cases in gdbserver, like handle_qxfer_threads and handle_qxfer_traceframe_info. It just didn't look like worth it enough to bother when I initially wrote this. -- Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [RFA] Fix memory leak in windows_xfer_shared_libraries 2012-12-13 20:16 ` [RFA] Fix memory leak in windows_xfer_shared_libraries Pedro Alves @ 2012-12-14 7:53 ` Pierre Muller 2012-12-14 10:12 ` Pedro Alves 0 siblings, 1 reply; 11+ messages in thread From: Pierre Muller @ 2012-12-14 7:53 UTC (permalink / raw) To: 'Pedro Alves'; +Cc: gdb-patches > -----Message d'origine----- > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Pedro Alves > Envoyé : jeudi 13 décembre 2012 21:16 > À : Pierre Muller > Cc : gdb-patches@sourceware.org > Objet : Re: [RFA] Fix memory leak in windows_xfer_shared_libraries > > On 12/13/2012 11:11 AM, Pierre Muller wrote: > > --- windows-nat.c 13 Nov 2012 09:46:10 -0000 1.236 > > +++ windows-nat.c 13 Dec 2012 10:54:18 -0000 > > @@ -2411,11 +2411,11 @@ windows_xfer_shared_libraries (struct ta > > buf = obstack_finish (&obstack); > > len_avail = strlen (buf); > > if (offset >= len_avail) > > - return 0; > > - > > - if (len > len_avail - offset) > > + len= 0 > > + else if (len > len_avail - offset) > > len = len_avail - offset; > > - memcpy (readbuf, buf + offset, len); > > + if (len > 0) > > + memcpy (readbuf, buf + offset, len); > > > > You can avoid the last if by writing as: > > if (offset >= len_avail) > len = 0; > else > { > if (len > len_avail - offset) > len = len_avail - offset; > memcpy (readbuf, buf + offset, len); > } > > I'd prefer that, but patch is okay either way. I committed with your modification. Thanks for the approval. > > obstack_free (&obstack, NULL); > > return len; > > > > > I was also wondering if it would not be better to keep the obstack in > > between the two calls, but that would probably require some static > variable > > :( > > That'd be fine. We actually do that in some cases in gdbserver, like > handle_qxfer_threads and handle_qxfer_traceframe_info. It just didn't > look like worth it enough to bother when I initially wrote this. I was wondering if this would become a problem if we later add support for multiple inferior for windows-nat I vaguely remember that I tried to achieve this a long time ago... Anyhow, the memory leak is gone at least! Pierre ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFA] Fix memory leak in windows_xfer_shared_libraries 2012-12-14 7:53 ` Pierre Muller @ 2012-12-14 10:12 ` Pedro Alves 2012-12-14 10:26 ` [RFA] Fix other memory leak in solib_target_current_sos Pierre Muller [not found] ` <43198.6185875305$1355480794@news.gmane.org> 0 siblings, 2 replies; 11+ messages in thread From: Pedro Alves @ 2012-12-14 10:12 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches On 12/14/2012 07:53 AM, Pierre Muller wrote: >>> I was also wondering if it would not be better to keep the obstack in >>> between the two calls, but that would probably require some static >> variable >>> :( >> >> That'd be fine. We actually do that in some cases in gdbserver, like >> handle_qxfer_threads and handle_qxfer_traceframe_info. It just didn't >> look like worth it enough to bother when I initially wrote this. > > I was wondering if this would become a problem if we later add support for > multiple inferior > for windows-nat I don't think so. > I vaguely remember that I tried to achieve this a long time ago... ISTR you had an archer branch for that and other Windows stuff. > > Anyhow, the memory leak is gone at least! Thanks. -- Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFA] Fix other memory leak in solib_target_current_sos 2012-12-14 10:12 ` Pedro Alves @ 2012-12-14 10:26 ` Pierre Muller 2012-12-14 10:55 ` Pedro Alves [not found] ` <43198.6185875305$1355480794@news.gmane.org> 1 sibling, 1 reply; 11+ messages in thread From: Pierre Muller @ 2012-12-14 10:26 UTC (permalink / raw) To: 'Pedro Alves'; +Cc: gdb-patches > -----Message d'origine----- > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Pedro Alves > Envoyé : vendredi 14 décembre 2012 10:45 > À : Pierre Muller > Cc : gdb-patches@sourceware.org > Objet : Re: [RFA] Fix memory leak in windows_xfer_shared_libraries > > On 12/14/2012 07:53 AM, Pierre Muller wrote: > > >>> I was also wondering if it would not be better to keep the obstack in > >>> between the two calls, but that would probably require some static > >> variable > >>> :( > >> > >> That'd be fine. We actually do that in some cases in gdbserver, like > >> handle_qxfer_threads and handle_qxfer_traceframe_info. It just didn't > >> look like worth it enough to bother when I initially wrote this. > > > > I was wondering if this would become a problem if we later add support > for > > multiple inferior > > for windows-nat > > I don't think so. > > > I vaguely remember that I tried to achieve this a long time ago... > > ISTR you had an archer branch for that and other Windows stuff. Oh, no... I completely forgot that :( It's been a loooong time since I last worked on that :( > > > > Anyhow, the memory leak is gone at least! I found another leak, down the same line, solib_target_current_sos calls target_read_stralloc which as its name suggests allocates the result on the heap... But that string was not freed in the current code... This patch fixes that leak. 2012-12-14 Pierre Muller <muller@sourceware.org> * solib-target.c (solib_target_current_sos): Remove 'const' qualifier from type of library_document local variable to be able to free it and avoid a memory leak. Index: src/gdb/solib-target.c =================================================================== RCS file: /cvs/src/src/gdb/solib-target.c,v retrieving revision 1.24 diff -u -p -r1.24 solib-target.c --- src/gdb/solib-target.c 4 Jan 2012 08:17:11 -0000 1.24 +++ src/gdb/solib-target.c 14 Dec 2012 10:17:58 -0000 @@ -246,7 +246,7 @@ static struct so_list * solib_target_current_sos (void) { struct so_list *new_solib, *start = NULL, *last = NULL; - const char *library_document; + char *library_document; VEC(lm_info_p) *library_list; struct lm_info *info; int ix; @@ -261,7 +261,10 @@ solib_target_current_sos (void) /* Parse the list. */ library_list = solib_target_parse_libraries (library_document); if (library_list == NULL) - return NULL; + { + xfree (library_document); + return NULL; + } /* Build a struct so_list for each entry on the list. */ for (ix = 0; VEC_iterate (lm_info_p, library_list, ix, info); ix++) @@ -291,6 +294,9 @@ solib_target_current_sos (void) /* Free the library list, but not its members. */ VEC_free (lm_info_p, library_list); + /* Also free allocated library_document string. */ + xfree (library_document); + return start; } ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFA] Fix other memory leak in solib_target_current_sos 2012-12-14 10:26 ` [RFA] Fix other memory leak in solib_target_current_sos Pierre Muller @ 2012-12-14 10:55 ` Pedro Alves 2012-12-14 13:07 ` [RFA-v2] " Pierre Muller 0 siblings, 1 reply; 11+ messages in thread From: Pedro Alves @ 2012-12-14 10:55 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches On 12/14/2012 10:25 AM, Pierre Muller wrote: > I found another leak, down the same line, > solib_target_current_sos > calls target_read_stralloc > which as its name suggests allocates the result on the heap... > But that string was not freed in the current code... > > This patch fixes that leak. Thanks. > 2012-12-14 Pierre Muller <muller@sourceware.org> > > * solib-target.c (solib_target_current_sos): Remove 'const' > qualifier from type of library_document local variable to be > able to free it and avoid a memory leak. > > Index: src/gdb/solib-target.c > =================================================================== > RCS file: /cvs/src/src/gdb/solib-target.c,v > retrieving revision 1.24 > diff -u -p -r1.24 solib-target.c > --- src/gdb/solib-target.c 4 Jan 2012 08:17:11 -0000 1.24 > +++ src/gdb/solib-target.c 14 Dec 2012 10:17:58 -0000 > @@ -246,7 +246,7 @@ static struct so_list * > solib_target_current_sos (void) > { > struct so_list *new_solib, *start = NULL, *last = NULL; > - const char *library_document; > + char *library_document; > VEC(lm_info_p) *library_list; > struct lm_info *info; > int ix; > @@ -261,7 +261,10 @@ solib_target_current_sos (void) > /* Parse the list. */ > library_list = solib_target_parse_libraries (library_document); > if (library_list == NULL) > - return NULL; > + { > + xfree (library_document); > + return NULL; > + } > > /* Build a struct so_list for each entry on the list. */ > for (ix = 0; VEC_iterate (lm_info_p, library_list, ix, info); ix++) > @@ -291,6 +294,9 @@ solib_target_current_sos (void) > /* Free the library list, but not its members. */ > VEC_free (lm_info_p, library_list); > > + /* Also free allocated library_document string. */ > + xfree (library_document); > + > return start; > } > Parsing XML, within solib_target_parse_libraries, may throw. Thus, a cleanup would be better: + old_chain = make_cleanup (xfree, library_document); library_list = solib_target_parse_libraries (library_document); + do_cleanups (old_chain); -- Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFA-v2] Fix other memory leak in solib_target_current_sos 2012-12-14 10:55 ` Pedro Alves @ 2012-12-14 13:07 ` Pierre Muller 2012-12-14 13:49 ` Pedro Alves 0 siblings, 1 reply; 11+ messages in thread From: Pierre Muller @ 2012-12-14 13:07 UTC (permalink / raw) To: 'Pedro Alves'; +Cc: gdb-patches > -----Message d'origine----- > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Pedro Alves > Envoyé : vendredi 14 décembre 2012 11:55 > À : Pierre Muller > Cc : gdb-patches@sourceware.org > Objet : Re: [RFA] Fix other memory leak in solib_target_current_sos > > On 12/14/2012 10:25 AM, Pierre Muller wrote: > > > I found another leak, down the same line, > > solib_target_current_sos > > calls target_read_stralloc > > which as its name suggests allocates the result on the heap... > > But that string was not freed in the current code... > > > > This patch fixes that leak. > > Thanks. > > > 2012-12-14 Pierre Muller <muller@sourceware.org> > > > > * solib-target.c (solib_target_current_sos): Remove 'const' > > qualifier from type of library_document local variable to be > > able to free it and avoid a memory leak. > > > > Index: src/gdb/solib-target.c > > =================================================================== > > RCS file: /cvs/src/src/gdb/solib-target.c,v > > retrieving revision 1.24 > > diff -u -p -r1.24 solib-target.c > > --- src/gdb/solib-target.c 4 Jan 2012 08:17:11 -0000 1.24 > > +++ src/gdb/solib-target.c 14 Dec 2012 10:17:58 -0000 > > @@ -246,7 +246,7 @@ static struct so_list * > > solib_target_current_sos (void) > > { > > struct so_list *new_solib, *start = NULL, *last = NULL; > > - const char *library_document; > > + char *library_document; > > VEC(lm_info_p) *library_list; > > struct lm_info *info; > > int ix; > > @@ -261,7 +261,10 @@ solib_target_current_sos (void) > > /* Parse the list. */ > > library_list = solib_target_parse_libraries (library_document); > > if (library_list == NULL) > > - return NULL; > > + { > > + xfree (library_document); > > + return NULL; > > + } > > > > /* Build a struct so_list for each entry on the list. */ > > for (ix = 0; VEC_iterate (lm_info_p, library_list, ix, info); ix++) > > @@ -291,6 +294,9 @@ solib_target_current_sos (void) > > /* Free the library list, but not its members. */ > > VEC_free (lm_info_p, library_list); > > > > + /* Also free allocated library_document string. */ > > + xfree (library_document); > > + > > return start; > > } > > > > Parsing XML, within solib_target_parse_libraries, may throw. Thus, a > cleanup would be better: > > + old_chain = make_cleanup (xfree, library_document); > library_list = solib_target_parse_libraries (library_document); > + do_cleanups (old_chain); Of course... library_document isn't needed after that point anymore. New version of the patch below. Pierre 2012-12-14 Pierre Muller <muller@sourceware.org> Pedro Alves <palves@redhat.com> * solib-target.c (solib_target_current_sos): Remove 'const' qualifier from type of library_document local variable to be able to free it and avoid a memory leak. Use cleanup chain to avoid leak even if exceptino is generated. Index: solib-target.c =================================================================== RCS file: /cvs/src/src/gdb/solib-target.c,v retrieving revision 1.24 diff -u -p -r1.24 solib-target.c --- solib-target.c 4 Jan 2012 08:17:11 -0000 1.24 +++ solib-target.c 14 Dec 2012 13:03:13 -0000 @@ -246,7 +246,8 @@ static struct so_list * solib_target_current_sos (void) { struct so_list *new_solib, *start = NULL, *last = NULL; - const char *library_document; + char *library_document; + struct cleanup *old_chain; VEC(lm_info_p) *library_list; struct lm_info *info; int ix; @@ -258,8 +259,15 @@ solib_target_current_sos (void) if (library_document == NULL) return NULL; + /* solib_target_parse_libraries may throw, so we use a cleanup. */ + old_chain = make_cleanup (xfree, library_document); + /* Parse the list. */ library_list = solib_target_parse_libraries (library_document); + + /* library_document string is not needed behind this point. */ + do_cleanups (old_chain); + if (library_list == NULL) return NULL; ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFA-v2] Fix other memory leak in solib_target_current_sos 2012-12-14 13:07 ` [RFA-v2] " Pierre Muller @ 2012-12-14 13:49 ` Pedro Alves 0 siblings, 0 replies; 11+ messages in thread From: Pedro Alves @ 2012-12-14 13:49 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches On 12/14/2012 01:07 PM, Pierre Muller wrote: > New version of the patch below. OK. Thanks. -- Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <43198.6185875305$1355480794@news.gmane.org>]
* Re: [RFA] Fix other memory leak in solib_target_current_sos [not found] ` <43198.6185875305$1355480794@news.gmane.org> @ 2012-12-14 14:14 ` Tom Tromey 2012-12-14 23:29 ` Pierre Muller 0 siblings, 1 reply; 11+ messages in thread From: Tom Tromey @ 2012-12-14 14:14 UTC (permalink / raw) To: Pierre Muller; +Cc: 'Pedro Alves', gdb-patches >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes: Pierre> library_list = solib_target_parse_libraries (library_document); Pierre> if (library_list == NULL) Pierre> - return NULL; Pierre> + { Pierre> + xfree (library_document); Pierre> + return NULL; Pierre> + } It seems to me that you could unconditionally free it here, before the if. Tom ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [RFA] Fix other memory leak in solib_target_current_sos 2012-12-14 14:14 ` [RFA] " Tom Tromey @ 2012-12-14 23:29 ` Pierre Muller 0 siblings, 0 replies; 11+ messages in thread From: Pierre Muller @ 2012-12-14 23:29 UTC (permalink / raw) To: 'Tom Tromey'; +Cc: 'Pedro Alves', gdb-patches > -----Message d'origine----- > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Tom Tromey > Envoyé : vendredi 14 décembre 2012 15:14 > À : Pierre Muller > Cc : 'Pedro Alves'; gdb-patches@sourceware.org > Objet : Re: [RFA] Fix other memory leak in solib_target_current_sos > > >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes: > > Pierre> library_list = solib_target_parse_libraries (library_document); > Pierre> if (library_list == NULL) > Pierre> - return NULL; > Pierre> + { > Pierre> + xfree (library_document); > Pierre> + return NULL; > Pierre> + } > > It seems to me that you could unconditionally free it here, before the if. That's what the committed version does thanks to Pedro's suggestion.... Pierre ^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFA] Fix memory leak in windows_xfer_shared_libraries
@ 2012-12-13 11:11 Pierre Muller
2012-12-13 11:23 ` Pierre Muller
0 siblings, 1 reply; 11+ messages in thread
From: Pierre Muller @ 2012-12-13 11:11 UTC (permalink / raw)
To: gdb-patches
The current mechanism of getting the list of DLLs when command
infl dll
is given to gdb prompt,
info_shared_library function in solib.c calls
windows_xfer_shared_libraries in windows-nat.c
using target_read_stralloc, which calls target_read_alloc_1.
That function reiterates calls to target_read_partial
until the number of transferred bytes is zero...
This results even if the buffer is large enough to contain all data at
first
call in a second call in which the same xml answer is computed again,
and nothing is done, because the offset correspond to the end of the
resulting
string.
The current code has a memory leak that is fixed by the patch below.
I was also wondering if it would not be better to keep the obstack in
between the two calls, but that would probably require some static variable
:(
Pierre Muller
GDB pascal language maintainer
2012-12-13 Pierre Muller <muller@sourceware.org>
* windows-nat.c (windows_xfer_shared_libraries): Avoid
memory leak when OFFSET >= LEN_AVAIL.
Index: windows-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/windows-nat.c,v
retrieving revision 1.236
diff -u -p -r1.236 windows-nat.c
--- windows-nat.c 13 Nov 2012 09:46:10 -0000 1.236
+++ windows-nat.c 13 Dec 2012 10:54:18 -0000
@@ -2411,11 +2411,11 @@ windows_xfer_shared_libraries (struct ta
buf = obstack_finish (&obstack);
len_avail = strlen (buf);
if (offset >= len_avail)
- return 0;
-
- if (len > len_avail - offset)
+ len= 0
+ else if (len > len_avail - offset)
len = len_avail - offset;
- memcpy (readbuf, buf + offset, len);
+ if (len > 0)
+ memcpy (readbuf, buf + offset, len);
obstack_free (&obstack, NULL);
return len;
^ permalink raw reply [flat|nested] 11+ messages in thread* RE: [RFA] Fix memory leak in windows_xfer_shared_libraries 2012-12-13 11:11 [RFA] Fix memory leak in windows_xfer_shared_libraries Pierre Muller @ 2012-12-13 11:23 ` Pierre Muller 0 siblings, 0 replies; 11+ messages in thread From: Pierre Muller @ 2012-12-13 11:23 UTC (permalink / raw) To: gdb-patches Whoops, I forgot to test my patch :( Once again, got bitten by a difference in syntax between C and pascal... a semicolon was missing before the else keyword... Sorry about that, Pierre > -----Message d'origine----- > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Pierre Muller > Envoyé : jeudi 13 décembre 2012 12:11 > À : gdb-patches@sourceware.org > Objet : [RFA] Fix memory leak in windows_xfer_shared_libraries > > The current mechanism of getting the list of DLLs when command > infl dll > is given to gdb prompt, > info_shared_library function in solib.c calls > windows_xfer_shared_libraries in windows-nat.c > > using target_read_stralloc, which calls target_read_alloc_1. > > That function reiterates calls to target_read_partial > until the number of transferred bytes is zero... > > This results even if the buffer is large enough to contain all data at > first > call in a second call in which the same xml answer is computed again, > and nothing is done, because the offset correspond to the end of the > resulting > string. > > The current code has a memory leak that is fixed by the patch below. > > I was also wondering if it would not be better to keep the obstack in > between the two calls, but that would probably require some static variable > :( > Fixed patch: 2012-12-13 Pierre Muller <muller@sourceware.org> * windows-nat.c (windows_xfer_shared_libraries): Avoid memory leak when OFFSET >= LEN_AVAIL. Index: windows-nat.c =================================================================== RCS file: /cvs/src/src/gdb/windows-nat.c,v retrieving revision 1.236 diff -u -p -r1.236 windows-nat.c --- windows-nat.c 13 Nov 2012 09:46:10 -0000 1.236 +++ windows-nat.c 13 Dec 2012 10:54:18 -0000 @@ -2411,11 +2411,11 @@ windows_xfer_shared_libraries (struct ta buf = obstack_finish (&obstack); len_avail = strlen (buf); if (offset >= len_avail) - return 0; - - if (len > len_avail - offset) + len= 0; + else if (len > len_avail - offset) len = len_avail - offset; - memcpy (readbuf, buf + offset, len); + if (len > 0) + memcpy (readbuf, buf + offset, len); obstack_free (&obstack, NULL); return len; ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-12-14 23:29 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <50c9b7e6.25f2440a.3810.3771SMTPIN_ADDED_BROKEN@mx.google.com>
2012-12-13 20:16 ` [RFA] Fix memory leak in windows_xfer_shared_libraries Pedro Alves
2012-12-14 7:53 ` Pierre Muller
2012-12-14 10:12 ` Pedro Alves
2012-12-14 10:26 ` [RFA] Fix other memory leak in solib_target_current_sos Pierre Muller
2012-12-14 10:55 ` Pedro Alves
2012-12-14 13:07 ` [RFA-v2] " Pierre Muller
2012-12-14 13:49 ` Pedro Alves
[not found] ` <43198.6185875305$1355480794@news.gmane.org>
2012-12-14 14:14 ` [RFA] " Tom Tromey
2012-12-14 23:29 ` Pierre Muller
2012-12-13 11:11 [RFA] Fix memory leak in windows_xfer_shared_libraries Pierre Muller
2012-12-13 11:23 ` Pierre Muller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox