Avoid setting @tc in thread_begin event

[st0012]

This event will be triggered before the new thread even has a ThreadClient. So in this case, the @tc will be overridden to just nil,
which is wrong.

However, we also don't want to just set @tc to the new thread's newly created ThreadClient. This is because a thread's creation can happen during a subsession, and promptly switching @tc to another thread's ThreadClient will misfire thread suspension.

Fixes #725

[ko1]

00ec229
It's my fault can not checking this bug.

[ko1]

Could you add a test program or repro- small code?

[ko1]

I'm not sure the issue and why the patch solves yet.

1. Stop at TC1: @tc = TC1
2. eval Thread.new{} on TC1
3. receive thread_begin and @tc = nil
4. receive result event and @tc = T1 (maybe)

In this case, there is no issue. Could you describe what's happens?

[ko1]

ah, https://github.com/ruby/debug/blob/master/lib/debug/session.rb#L1537 this comparison requires @tc.

[ko1]

Another threads can resume by some events so that current code is unstable for that even if the patch is merged.
Anyway I'll merge it (and modify them soon) if you wrote can write a test code.

[st0012]

I've added a test that'd hang and timeout on master.

[ianterrell]

@ko1 @st0012 — Thanks so much for this fix, it really helps our workflows. I expect this is impacting a lot of Rails apps in the wild. Is there anything else I can do to help get this merged in and released?