Re: gdb-6.0/gdb/gdbserver/target.c::set_desired_inferior()

[Albert Ho <alberth@intellambda.com>]

I am trying to decide whether the problem is in the thread library or gdb.
4 facts:
1) The program runs fine on its own.
2) gdbserver can debug the program if let the process starts first 
(hence loading all the library), then use --attach.
3) Run gdb gdbserver, then start the program in gdbserver also works.
4) Run gdbserver alone with the program cause the program's new thread 
died, I suspect it affects gdbserver to segfault too.

I'll get the pthread symbol to look further.

One last question. Does the host suppose to load exactly the same 
library as the target? I see the host loads libthread.so.1, but the 
target's core has libthread_db.so.1.

Thanks.

Daniel Jacobowitz wrote:

>On Fri, Feb 27, 2004 at 12:03:17PM -0800, Albert Ho wrote:
>  
>
>>The first spawn thread died on startup under gdbserver. It has a pid of 
>>1024. System was just started and the main thread has pid 110.
>>    
>>
>
>Sorry, but that isn't enough information to make a guess at what your
>problem is.  It sounds like your system has problems with debugging.
>
>  
>
>>Daniel Jacobowitz wrote:
>>
>>    
>>
>>>On Thu, Feb 26, 2004 at 07:22:59PM -0800, Albert Ho wrote:
>>>
>>>
>>>      
>>>
>>>>Should gdb-6.0/gdb/gdbserver/target.c::set_desired_inferior() always 
>>>>succeed when dealing with 's' in main?
>>>>
>>>>I run into a problem when a thread is not found in 
>>>>set_desired_inferior(), causing &status to become some bogus addr and 
>>>>hence gdbserve segv.
>>>>  
>>>>
>>>>        
>>>>
>>>I've never seen this behavior before.  Please explain how it happens; I
>>>don't see any way to get a bogus pointer unless your thread list is
>>>corrupted.
>>>
>>>
>>>
>>>      
>>>
>>
>>    
>>
>
>  
>