This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2] Fix logic in exec_file_locate_attach
- From: Gary Benson <gbenson at redhat dot com>
- To: Luis Machado <lgustavo at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org, Pedro Alves <palves at redhat dot com>
- Date: Mon, 22 Feb 2016 10:40:34 +0000
- Subject: Re: [PATCH v2] Fix logic in exec_file_locate_attach
- Authentication-results: sourceware.org; auth=none
- References: <20160219102447 dot GA29870 at blade dot nx> <1455880879-310-1-git-send-email-gbenson at redhat dot com> <56C736ED dot 9040505 at codesourcery dot com>
Luis Machado wrote:
> On 02/19/2016 09:21 AM, Gary Benson wrote:
> > This is an updated version of the patch I posted yesterday.
> > It fails silently rather than throwing if the executable is
> > not in the sysroot, which both fixes the sysroot-escape issue
> > and results in a better GDB session for the user.
> >
> > Built and regtested on RHEL 6.6 x86_64.
> >
> > Luis, I think this patch will fix your connection drop without
> > any further changes. Could you test it please?
>
> Unfortunately it doesn't completely solve the problem i saw, as
> exec_file_find will still potentially throw errors and will disrupt
> the connection attempt or stop execution of a custom sequence of
> commands (as Pedro noted) when "attach" is part of the sequence.
>
> define foo
> attach <pid>
> >>>> execution stops here if an error is thrown
> info threads
> info registers
> end
>
> It still looks like a TRY/CATCH block is needed around at least
> exec_file_find.
What is throwing in exec_file_find? I'm just seeing lots of calls
to gdb_open_cloexec and openp, and I don't think either of those
should throw except for assertion failures or running out of memory.
Cheers,
Gary
--
http://gbenson.net/