This is the mail archive of the gdb@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]

Re: How to catch GDB crash


On Thursday 26 June 2008 03:27:58 Pedro Alves wrote:
> A Wednesday 25 June 2008 09:02:33, Dmitry Smirnov wrote:
> > Hi Pedro,
> >
> > I'll try to figure out, whether skyeye (which is remote target) supports
> > notion of thread ids or pids. Now I just suppose it does not support.
> > Nevertheless, I do not believe this is related to a crash.
> 
> Yes it is.  :-)
> 
> >
> > As I said previously, I was debugging this program (ARM code) for some time
> > previously. 
> 
> But you've certainly upgraded your GDB recently (I can tell by your log
> output on your original post).  As I said, this is a recently introduced
> regression.
> 
> I've was able to reproduce the problem, by connecting to a local
> gdbserver with a GDB with all thread support hacked out in the
> remote target.
> 
> > BTW, I've just realized that command-line interface does not use mi_*
> > interface (neither mi_on_resume nor mi_execute_command were hit) and this
> > is most likely the reason why I cannot reproduce this test case with CLI.
> >
> 
> Yes, that's exactly the reason.
> 
> Anyway, I've posted a patch that fixes the issue in your case
> (it was actually a side effect of something else I was doing),
> although we may need to get rid of the assert you weren't tripping
> at for the time being (there are other targets other than
> remote that will also trip on the assert).
> 
> Vladimir, not sure if you noticed the issue, as it's buried in
> this long thread?  We can always leave the crash in place to
> force targets to follow our evil plot of always registering the
> main thread.  :-)
> I'd post a patch for it, but I don't know if we should output
> thread-id=0 in that case, or not output thread-id
> at all ...

I think that for the time being, we can change the assert to check that
either the program is single-threaded, or the thread is known. If the
program is single-threaded, the the thread id is not registered, omitting
thread-id completely seems right.

I can make this change, or you have something already?

- Volodya


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