diff options
| author | Philippe Waroquiers <philippe.waroquiers@skynet.be> | 2019-01-01 20:54:52 +0100 |
|---|---|---|
| committer | Philippe Waroquiers <philippe.waroquiers@skynet.be> | 2019-01-02 22:10:39 +0100 |
| commit | e3319240732bc9543af8ced9d80ec89d0b629b2e (patch) | |
| tree | 32a5d194bf7a25ee10727823865140809a46c03a /gdb/probe.c | |
| parent | 5d36dfb949751663bcb814b3cc780ed8f47442b4 (diff) | |
| download | gdb-e3319240732bc9543af8ced9d80ec89d0b629b2e.zip gdb-e3319240732bc9543af8ced9d80ec89d0b629b2e.tar.gz gdb-e3319240732bc9543af8ced9d80ec89d0b629b2e.tar.bz2 | |
Fix leak of struct call_thread_fsm in call_function_by_hand_dummy.
When the call does not complete, the call_thread_fsm allocated
by new_call_thread_fsm is not cleaned up and deleted, which causes
the following leak e.g. in gdb.base/callfuncs.exp:
==29263== 560 bytes in 7 blocks are definitely lost in loss record 2,833 of 3,341
==29263== at 0x4C2E0BC: calloc (vg_replace_malloc.c:762)
==29263== by 0x405110: xcalloc (common-utils.c:84)
==29263== by 0x4E67EB: xcnew<call_thread_fsm> (poison.h:122)
==29263== by 0x4E67EB: new_call_thread_fsm (infcall.c:516)
==29263== by 0x4E67EB: call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) (infcall.c:1154)
==29263== by 0x4E784E: call_function_by_hand(value*, type*, gdb::array_view<value*>) (infcall.c:693)
==29263== by 0x496111: eval_call(expression*, noside, int, value**, char const*, type*) [clone .isra.5] (eval.c:835)
Fix the leak by similarly doing cleanup/destroy when restoring
previous state machine.
Tested on debian/amd64, natively and under valgrind.
2019-01-02 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* infcall.c (call_function_by_hand_dummy): cleanup/destroy sm
in case of call that did not complete.
Diffstat (limited to 'gdb/probe.c')
0 files changed, 0 insertions, 0 deletions