Re: Trouble with GDB and specific app on 7.0-CURRENT....

On 10/07/2007 19:09, Tijl Coosemans wrote:
> On Monday 08 October 2007 00:47:00 Eric Schuele wrote:
>> On 10/07/2007 17:44, Kip Macy wrote:
>>> On 9/27/07, Eric Schuele <e.schuele_at_computer.org> wrote:
>>>> On 09/28/2007 00:12, Steve Kargl wrote:
>>>>> On Thu, Sep 27, 2007 at 11:58:35PM -0500, Eric Schuele wrote:
>>>>>> On 09/27/2007 23:29, Steve Kargl wrote:
>>>>>>> On Thu, Sep 27, 2007 at 11:18:01PM -0500, Eric Schuele wrote:
>>>>>>>> Has anyone seen behavior like this?  What else can I provide
>>>>>>>> that might help diagnose this?
>>>>>>> Are you by any chance using tcsh as your shell?
>>>>>> heh... Yes, as a matter of fact.  How is that affecting me?  I've
>>>>>> always used tcsh and not had these troubles.
>>>>> Signal handling in tcsh is broken, and one manifestation of
>>>>> the problem is the behavior you're seeing with gdb.  I've
>>>>> repeatedly asked to have the 6.15.0 version of tcsh backed
>>>>> out of src/ to the previously working 6.14.0 version, but no
>>>>> one who can affect such a change seems to think a default user
>>>>> shell with broken signal handling is a problem.  The only
>>>>> workaround that I've found is "setenv SHELL sh" prior to
>>>>> executing gdb.
>>>> Hmm... yeah.. I found the bug report after you mentioned tcsh.
>>>> However changing that var has no effect for me.  In fact using sh
>>>> as my shell makes no difference either.
>>>>
>>>> Maybe I should rollback my tcsh and see what happens?
>>> You need to actually execute a different shell. Changing the
>>> variable isn't going to help.
>> I did execute a different shell.  Tried several in fact.
> 
> I'm not sure it will help, but you might want to give the patch in
> http://www.freebsd.org/cgi/query-pr.cgi?pr=115469 a try.
> 
> 

To read the description, I don't believe I am experiencing this problem.

After further investigation, I came to the following conclusion. Imagine
one function, main() for example, written to call another function,
my_func(), 10 times.  However on the 6th call to said function... gdb
refuses to step into the function... instead taking 100% of your cpu,
seemingly forever.

That is what I am seeing.  Do you still think the patch is applicable to
my situation?  If so I will give it a shot.

-- 
Regards,
Eric