Re: GDB 10.1 release: branching early July?

Rainer Orth
2020-06-16T13:49:46Z

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