This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/20569] GDB segv in follow_exec
- From: "sandra at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Sat, 01 Oct 2016 23:27:24 +0000
- Subject: [Bug gdb/20569] GDB segv in follow_exec
- Auto-submitted: auto-generated
- References: <bug-20569-4717@http.sourceware.org/bugzilla/>
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.