This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/20569] GDB segv in follow_exec


https://sourceware.org/bugzilla/show_bug.cgi?id=20569

--- Comment #1 from sandra at codesourcery dot com ---
I was looking at the other caller of exec_file_find in exec_file_locate_attach
(in exec.c), thinking that I could copy or refactor/share code.  But, I don't
think that is correct either.

(1) It seems to me like returning directly if exec_file_find returns NULL is
likely to leave things in an inconsistent state.  Shouldn't it at least clear
any previous exec file state, if it can't find the new executable?

(2) Ditto for the exception handling logic....  it's catching errors, but not
doing anything to try to clean up state.

(3) The call to IS_ABSOLUTE_PATH should be IS_TARGET_ABSOLUTE_PATH since its
argument is a target pathname, before exec_file_find tries to munge it to a
host pathname.

(4) The implementation of the helper function exception_print_same is clearly
bogus and will likely segfault if either e1.message or e2.message is NULL.  I
suggest

int
exception_print_same (struct gdb_exception e1, struct gdb_exception e2)
{
  return (e1.reason == e2.reason
          && e1.error == e2.error
          && (e1.message == e2.message
              || (e1.message && e2.message
                  && strcmp (e1.message, e2.message) == 0)));
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]