Re: GDB 10.1 release: branching early July?

[Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>]

Hi Joel,

>> >   * [RainerO]
>> >     <PR gdb/25939> [10 regression] run fails with ICE on Solaris
>> >
>> >     Not sure if this is still an issue or not. Rainer did push some
>> >     patches to master back in May. To be confirmed.
>> 
>> unfortunately, it is, and I didn't have much success debugging it.  This
>> makes gdb useless on Solaris and was introduced by the multi-target
>> merge.  I'm completely unfamiliar with that code and will need all the
>> help I can get to get this resolved.
>
> Boooo... Understood. Maybe start a dedicated discussion on gdb-patches
> with your current findings? Maybe Pedro can give you some pointers,
> to help us debug and fix this thing?

I guess that's the only option: at the glacial rate I'm currently making
progress, a patch will be ready for GDB 11 at the earliest otherwise.

> I see that you've already provided a bit of information in the PR
> itself (https://sourceware.org/bugzilla/show_bug.cgi?id=25939), but
> perhaps we could start with a summary of the situation, and what
> you have found so far? For instance, IIUC, this affects debugging
> of any program on Solaris. Are you still getting the same error?

I've got to try that first, but assuming that the problem is in procfs.c
(and maybe sol-thread.c), it's unlikely to have gone away in the
meantime.

> Your observation about a large number of threads being created is
> interesting, and perhaps deserves to be dug into a little deeper,
> considering that you think this wasn't happening with a version
> prior to the multitarget patch series?

I've now found where those are coming from: the thread name "gdb worker"
visible in ps -L provided the necessary clue.  They are due to worker
threads now being enabled by default.  On my desktop with 4 cores and
hyperthreading, that's relatively harmless.  However, when I run gdb on
an 8-socket server with 160 cores total, the messages about thread
creation when debugging gdb are killing you ;-)  I traced this to
maint.c (update_thread_pool_size) where the count defaults to
std::thread::hardware_concurrency ().  Maybe a bit over-eager...

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University