This is the mail archive of the gdb-patches@sources.redhat.com 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]

Re: [RFC] detach properly from process


On Thu, Aug 07, 2003 at 03:35:45PM -0400, Elena Zannoni wrote:
> 
> 
> Say you have 2 processes running: the first process' executable is
> called 'foo' with PID 12345, the second one is called 'bar' with PID 67890.
> 
> Then you do:
> 
> %gdb
> (gdb) attach 12345
> Attaching to process 12345
> Reading symbols from /home/ezannoni/foo...done
> (gdb) detach
> Detaching from program: /home/ezannoni/foo, process 12345
> (gdb) attach 67890
> Attaching to program: /home/ezannoni/foo, process 67890
>                       ^^^^^^^^^^^^^^^^^^
> Cannot access memory at address 0xfb8804
> 
> 
> It didn't read the symbols from the new file 'bar' because the
> exec_bfd was never reset to NULL. :-( exec_bfd is tested in the
> get_exec_file() function which is called by child_attach(). If there
> is an exec_bfd, reuse it. 
> 
> I noticed that also kill would not clean the exec_bfd.
> 
> 
> However, I am not sure what gdb's intended behavior is in these
> circumstances.  If you look at the testsuite, attach.exp, you will see
> that after a 'detach' it does a 'file' (w/o args) to clean the old
> symbols. So maybe it was OK to not get rid of the bfd, etc? I cannot
> find anything  in the docs about what detach is supposed to really do.
> 
> I always found the semantics of detach/kill etc to be quite
> inconsistent. 

I think detach shouldn't close the BFD.  The above is really the
bizarre case - if you've specified a file explicitly, then we should
hold on to it!  User knows what they're doing.

There we've guessed the file implicitly, though.  In that case it might
make sense to close it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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