gdb/guile: fix memory leak in gdbscm_parse_command_name

For reference see the previous commit.

Fix a memory leak in gdbscm_parse_command_name when a guile exception
is thrown.  To reveal the memory leak I placed the following content
into a file 'leak.scm':

  (use-modules (gdb))
  (register-command!
   (make-command
    "break cmd"
    #:command-class COMMAND_OBSCURE
    #:invoke (lambda (self arg from-tty)
               (display "Hello World"))))

Then in GDB:

  (gdb) source leak.scm
  ERROR: In procedure register-command!:
  In procedure gdbscm_register_command_x: Out of range: 'break' is not a prefix command in position 1: "break cmd"
  Error while executing Scheme code.

Running this under valgrind reveals a memory leak for 'result' and
'prefix_text' from gdbscm_parse_command_name.

Another leak can be revealed with this input script:

  (use-modules (gdb))
  (register-command!
   (make-command
    "unknown-prefix cmd"
    #:command-class COMMAND_OBSCURE
    #:invoke (lambda (self arg from-tty)
               (display "Hello World"))))

This one occurs earlier in gdbscm_parse_command_name, and now only
'result' leaks.

The problem is that, when guile throws an exception then a longjmp is
performed from the function that raise the exception back to the guile
run-time.  A consequence of this is that no function local destructors
will be run.

In gdbscm_parse_command_name, this means that the two function locals
`result` and `prefix_text` will not have their destructors run, and
any memory managed by these objects will be leaked.

Fix this by assigning nullptr to these two function locals before
throwing an exception.  This will cause the managed memory to be
deallocated.

I could have implemented a fix that made use of Guile's dynwind
mechanism to register a cleanup callback, however, this felt like
overkill.  At the point the exception is being thrown we know that we
no longer need the managed memory, so we might as well just free the
memory at that point.

With this fix in place, the two leaks are now fixed in the valgrind
output.

Approved-By: Tom Tromey <tom@tromey.com>

0 files changed, 0 insertions, 0 deletions