https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #14 from Tom de Vries ---
Author: vries
Date: Fri Dec 28 03:43:26 2018
New Revision: 267443
URL: https://gcc.gnu.org/viewcvs?rev=267443&root=gcc&view=rev
Log:
[libbacktrace] Fix memory leak in loop in build_address_map
When failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #13 from Tom de Vries ---
Comment on attachment 45063
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45063
combined patch
>+ // We only kept the list of units to free them on failure. On
>+ // success the units are retained,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #12 from Tom de Vries ---
Created attachment 45063
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45063&action=edit
combined patch
> Can you attach one single patch from trunk?
Patch combining:
- Updated patch
https://gcc.gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #11 from Ian Lance Taylor ---
Sorry, I've gotten confused. Can you attach one single patch from trunk?
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #10 from Tom de Vries ---
(In reply to Tom de Vries from comment #9)
> Created attachment 45059 [details]
> Second followup patch
>
> > [ OTOH, that's a memory leak in the fail
> > case, but corresponds to unused memory in the succes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #9 from Tom de Vries ---
Created attachment 45059
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45059&action=edit
Second followup patch
> [ OTOH, that's a memory leak in the fail
> case, but corresponds to unused memory in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
Tom de Vries changed:
What|Removed |Added
Attachment #45057|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #7 from Tom de Vries ---
Created attachment 45057
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45057&action=edit
Followup patch
> [ Btw, note that if we move the u and pu allocations to before read_abbrevs,
> we can read the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #6 from Tom de Vries ---
Created attachment 45055
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45055&action=edit
Updated patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #5 from Tom de Vries ---
(In reply to Tom de Vries from comment #4)
> Comment on attachment 45048 [details]
> Proposed patch
>
> >@@ -1476,6 +1483,15 @@ build_address_map (struct backtrace_stat
> >backtrace_alloc (state, size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #4 from Tom de Vries ---
Comment on attachment 45048
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45048
Proposed patch
>@@ -1476,6 +1483,15 @@ build_address_map (struct backtrace_stat
> backtrace_alloc (state, sizeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> However, the allocation and deallocation is done in a loop over units, so if
> find_address_ranges succeeds for the first unit, but fails for the second,
> then onl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #1 from Tom de Vries ---
Created attachment 45027
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45027&action=edit
Detection patch
Output:
...
$ ./btest 2>&1 | sed 's%/.*/%%'
alloc at state.c:66: addr: 0x7f9addf62000, size: 72
15 matches
Mail list logo
