Re: GCC Bugzilla (and other) timeouts
On Tue, 25 Feb 2020 at 18:25, Martin Sebor wrote: > > Bugzilla has been slow lately, and today to the point of timing out > (I see the same problem with Git). This seems to be a recurring theme > around the time of a GCC release. Is anyone else experiencing this > problem and if so, does anyone know what the cause it and an ETA for > a solution? Is the upcoming hardware upgrade expected to solve it? > > Thanks > Martin > > $ git pull > Connection closed by 209.132.180.131 port 22 > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. What URL are you using to pull? (git remote get-url origin) Bugzilla and httpd are very slow, but I haven't had any git timeouts. If you're using anonymous access that gets throttled more aggressively than authenticated access (using git+ssh:// for the protocol).
issue with GDB python pretty-printers for libstdc++
Hi all. I was seeing a strange error in GDB (8.2.1) debugging some C++ code while trying to print a value. The pretty printer was throwing Python exceptions. Debugging it I discovered the problem, which is here (from GCC 9.2): libstdc++-v3/python/libstdcxx/v6/printers.py: # Starting with the type ORIG, search for the member type NAME. This # handles searching upward through superclasses. This is needed to # work around http://sourceware.org/bugzilla/show_bug.cgi?id=13615. def find_type(orig, name): typ = orig.strip_typedefs() while True: # Strip cv-qualifiers. PR 67440. --> search = '%s::%s' % (typ.unqualified(), name) try: return gdb.lookup_type(search) except RuntimeError: pass # The type was not found, so try the superclass. We only need # to check the first superclass, so we don't bother with # anything fancier here. field = typ.fields()[0] (First that GDB bug was fixed in 2012 so I'm not sure if we still need this method, but anyway...) The issue is on the marked line above. Here we are using the __str__() method on a gdb.Type to obtain the string name of the type. However, I've discovered that (at least on my system) the __str__() representation of a gdb.Type prepends the keyword "class " or "struct " (as appropriate) to the output. So the above will result in a string like: search = 'class std::unordered_map...::...' The prepended "class " causes the code to break: it doesn't find the type, then we try to use typ.fields()[0] which doesn't work as follows: Traceback (most recent call last): ... File "/cc/python/libstdcxx/v6/printers.py", line 97, in find_type field = typ.fields()[0] IndexError: list index out of range I think that it's not correct for the Python macros here to be using the gdb.Type.__str__() method to obtain the type name for anything other than displaying to users. They should always be using the gdb.Type.name data member instead. If I change the marked line above to be: search = '%s::%s' % (typ.unqualified().name, name) then it all works as expected. However, I took a quick look through the code and it _appears_ to me that this type of thing (using the implied, or explicit, gdb.Type.__str__() to obtain the type name) is done in a number of places. This makes me wonder whether (a) for some reason no one noticed this before, or (b) there's something bizarre about my GDB which is prepending this "class" or "struct" where other peoples' don't do that?
Re: GCC Bugzilla (and other) timeouts
On Wed, Feb 26, 2020 at 3:39 AM Jonathan Wakely wrote: > On Tue, 25 Feb 2020 at 18:25, Martin Sebor wrote: > > > > Bugzilla has been slow lately, and today to the point of timing out > > (I see the same problem with Git). This seems to be a recurring theme > > around the time of a GCC release. Is anyone else experiencing this > > problem and if so, does anyone know what the cause it and an ETA for > > a solution? Is the upcoming hardware upgrade expected to solve it? > > > > Thanks > > Martin > > > > $ git pull > > Connection closed by 209.132.180.131 port 22 > > fatal: Could not read from remote repository. > > > > Please make sure you have the correct access rights > > and the repository exists. > > What URL are you using to pull? (git remote get-url origin) > > Bugzilla and httpd are very slow, but I haven't had any git timeouts. > If you're using anonymous access that gets throttled more aggressively > than authenticated access (using git+ssh:// for the protocol). > Yes, I used to use git:// for pulls and ssh:// for pushes, but switched to ssh:// for both because I was getting too many rejected connections. Jason
Re: GCC Bugzilla (and other) timeouts
Hi - > > Bugzilla and httpd are very slow, but I haven't had any git timeouts. > > If you're using anonymous access that gets throttled more aggressively > > than authenticated access (using git+ssh:// for the protocol). Yeah, we're aware of reduced performance lately. Suspecting one disk is on the fritz, which doesn't help. The switchover to the new server can't happen soon enough - next week or two. - FChE
Re: GCC Bugzilla (and other) timeouts
On 2/26/20 1:32 AM, Jonathan Wakely wrote: On Tue, 25 Feb 2020 at 18:25, Martin Sebor wrote: Bugzilla has been slow lately, and today to the point of timing out (I see the same problem with Git). This seems to be a recurring theme around the time of a GCC release. Is anyone else experiencing this problem and if so, does anyone know what the cause it and an ETA for a solution? Is the upcoming hardware upgrade expected to solve it? Thanks Martin $ git pull Connection closed by 209.132.180.131 port 22 fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. What URL are you using to pull? (git remote get-url origin) I use git+ssh (from our documentation): $ git remote get-url origin git+ssh://mse...@gcc.gnu.org/git/gcc.git Bugzilla and httpd are very slow, but I haven't had any git timeouts. If you're using anonymous access that gets throttled more aggressively than authenticated access (using git+ssh:// for the protocol). Thanks for the confirmation. Sounds like it's a known problem and it's just a coincidence that it's happening again as we near a GCC release. I think I remember last year there was also a disk problem, and ditto the year before then: https://gcc.gnu.org/ml/gcc/2018-01/msg00125.html Maybe we should proactively replace the disks every December ;-) Martin
Re: GCC Bugzilla (and other) timeouts
On Wed, 26 Feb 2020 at 14:42, Jason Merrill wrote: > > On Wed, Feb 26, 2020 at 3:39 AM Jonathan Wakely wrote: >> >> On Tue, 25 Feb 2020 at 18:25, Martin Sebor wrote: >> > >> > Bugzilla has been slow lately, and today to the point of timing out >> > (I see the same problem with Git). This seems to be a recurring theme >> > around the time of a GCC release. Is anyone else experiencing this >> > problem and if so, does anyone know what the cause it and an ETA for >> > a solution? Is the upcoming hardware upgrade expected to solve it? >> > >> > Thanks >> > Martin >> > >> > $ git pull >> > Connection closed by 209.132.180.131 port 22 >> > fatal: Could not read from remote repository. >> > >> > Please make sure you have the correct access rights >> > and the repository exists. >> >> What URL are you using to pull? (git remote get-url origin) >> >> Bugzilla and httpd are very slow, but I haven't had any git timeouts. >> If you're using anonymous access that gets throttled more aggressively >> than authenticated access (using git+ssh:// for the protocol). > > > Yes, I used to use git:// for pulls and ssh:// for pushes, but switched to > ssh:// for both because I was getting too many rejected connections. Another trick I use to improve round trip time of git operations is to use an ssh control path, see ControlMaster in man 5 ssh_config. In my ~/.ssh/config I have: Host gcc.gnu.org User redi Protocol 2 ForwardX11 no ForwardAgent no Compression yes # instead of ControlMaster=auto you can open a master connection with ssh -M -N -f r...@gcc.gnu.org ControlMaster auto # OpenSSH 5.6 and later: ControlPersist yes ControlPath /tmp/ssh_%h This keeps a persistent connection open to the server which gets reused every time I connect over ssh. The downside is that sometimes after a network change the control path gets stuck and needs to be manually closed with 'ssh -O exit gcc.gnu.org' (it will get automatically recreated by the next ssh connection or git fetch/push).
Re: issue with GDB python pretty-printers for libstdc++
On Wed, 26 Feb 2020 at 14:32, Paul Smith wrote: > > Hi all. I was seeing a strange error in GDB (8.2.1) debugging some C++ > code while trying to print a value. The pretty printer was throwing Python > exceptions. > > Debugging it I discovered the problem, which is here (from GCC 9.2): > > libstdc++-v3/python/libstdcxx/v6/printers.py: > # Starting with the type ORIG, search for the member type NAME. This > # handles searching upward through superclasses. This is needed to > # work around http://sourceware.org/bugzilla/show_bug.cgi?id=13615. > def find_type(orig, name): > typ = orig.strip_typedefs() > while True: > # Strip cv-qualifiers. PR 67440. > --> search = '%s::%s' % (typ.unqualified(), name) > try: > return gdb.lookup_type(search) > except RuntimeError: > pass > # The type was not found, so try the superclass. We only need > # to check the first superclass, so we don't bother with > # anything fancier here. > field = typ.fields()[0] > > (First that GDB bug was fixed in 2012 so I'm not sure if we still need this > method, but anyway...) > > The issue is on the marked line above. Here we are using the __str__() > method on a gdb.Type to obtain the string name of the type. However, I've > discovered that (at least on my system) the __str__() representation of a > gdb.Type prepends the keyword "class " or "struct " (as appropriate) to the > output. So the above will result in a string like: > > search = 'class std::unordered_map...::...' I don't think I've seen that problem before. Are you sure that's the cause, and not something like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997 ? > The prepended "class " causes the code to break: it doesn't find the type, > then we try to use typ.fields()[0] which doesn't work as follows: > > Traceback (most recent call last): > ... > File "/cc/python/libstdcxx/v6/printers.py", line 97, in find_type > field = typ.fields()[0] > IndexError: list index out of range > > I think that it's not correct for the Python macros here to be using the > gdb.Type.__str__() method to obtain the type name for anything other than > displaying to users. They should always be using the gdb.Type.name data > member instead. If I change the marked line above to be: > > search = '%s::%s' % (typ.unqualified().name, name) > > then it all works as expected. > > However, I took a quick look through the code and it _appears_ to me that > this type of thing (using the implied, or explicit, gdb.Type.__str__() to > obtain the type name) is done in a number of places. I'm never clear whether we should be using Type.name or Type.tag or Type.__str__() because they all seem to do the wrong thing in different situations. > This makes me wonder whether (a) for some reason no one noticed this > before, or (b) there's something bizarre about my GDB which is prepending > this "class" or "struct" where other peoples' don't do that?
Re: issue with GDB python pretty-printers for libstdc++
On Wed, 26 Feb 2020 at 17:01, Jonathan Wakely wrote:
>
> On Wed, 26 Feb 2020 at 14:32, Paul Smith wrote:
> >
> > Hi all. I was seeing a strange error in GDB (8.2.1) debugging some C++
> > code while trying to print a value. The pretty printer was throwing Python
> > exceptions.
> >
> > Debugging it I discovered the problem, which is here (from GCC 9.2):
> >
> > libstdc++-v3/python/libstdcxx/v6/printers.py:
> > # Starting with the type ORIG, search for the member type NAME. This
> > # handles searching upward through superclasses. This is needed to
> > # work around http://sourceware.org/bugzilla/show_bug.cgi?id=13615.
> > def find_type(orig, name):
> > typ = orig.strip_typedefs()
> > while True:
> > # Strip cv-qualifiers. PR 67440.
> > --> search = '%s::%s' % (typ.unqualified(), name)
> > try:
> > return gdb.lookup_type(search)
> > except RuntimeError:
> > pass
> > # The type was not found, so try the superclass. We only need
> > # to check the first superclass, so we don't bother with
> > # anything fancier here.
> > field = typ.fields()[0]
> >
> > (First that GDB bug was fixed in 2012 so I'm not sure if we still need this
> > method, but anyway...)
> >
> > The issue is on the marked line above. Here we are using the __str__()
> > method on a gdb.Type to obtain the string name of the type. However, I've
> > discovered that (at least on my system) the __str__() representation of a
> > gdb.Type prepends the keyword "class " or "struct " (as appropriate) to the
> > output. So the above will result in a string like:
> >
> > search = 'class std::unordered_map...::...'
>
> I don't think I've seen that problem before. Are you sure that's the
> cause, and not something like
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997 ?
I compiled this program:
#include
int main()
{
std::unordered_map m;
m[3] = 5;
return m[1];
}
And with Fedora 31's GDB 8.3.50 I get this behaviour:
(gdb) py m = gdb.parse_and_eval('m')
(gdb) py print(m.type)
std::unordered_map, std::equal_to,
std::allocator > >
(gdb) py print(str(m.type))
std::unordered_map, std::equal_to,
std::allocator > >
There's no 'class' being added. But I also tried changing the
printers.py script to use .name and all our tests still pass, so I'm
not opposed to that change.
Re: issue with GDB python pretty-printers for libstdc++
On Wed, 2020-02-26 at 17:23 +, Jonathan Wakely wrote:
> I compiled this program:
>
> #include
>
> int main()
> {
> std::unordered_map m;
> m[3] = 5;
> return m[1];
> }
>
> And with Fedora 31's GDB 8.3.50 I get this behaviour:
I can't reproduce with a simple test either. But in my full system I
have something like this:
class Obj {
typedef uint64_t GroupId;
typedef uint64_t ObjectId;
typedef std::unordered_map GroupIdToObjectIdMap;
GroupIdToObjectIdMap objMap;
};
then in GDB I do this:
(gdb) ptype $v->objMap
type = std::unordered_map
Fine, but then when I do this:
(gdb) py v = gdb.parse_and_eval('$v')
(gdb) py print str(v.type)
Obj::GroupIdToObjectIdMap
OK, but then when I do this:
(gdb) py print str(v.type.strip_typedefs())
class std::unordered_map, std::equal_to, std::allocator > >
Note the "class " prefix here. And:
(gdb) py t = gdb.lookup_type(str(v.type.strip_typedefs())
Traceback (most recent call last):
File "", line 1, in
gdb.error: No type named class std::unordered_map, std::equal_to,
std::allocator > >::__node_type.
Error while executing Python code.
If I use v.type.strip_typedefs().name it works.
I haven't been able to reproduce this in a small separate test case. I
have no idea what the difference is :(
Thanks!!
GCC 8.4 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 8.4 is available from https://gcc.gnu.org/pub/gcc/snapshots/8.4.0-RC-20200226/ ftp://gcc.gnu.org/pub/gcc/snapshots/8.4.0-RC-20200226/ and shortly its mirrors. It has been generated from git commit r8-10091-gf80c40f93f9e8781b14f1a8301467f117fd24051. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 8.4 on Wednesday, March 4th.
GCC 8.4 Status Report (2020-02-26)
Status == The GCC 8 branch is now frozen for blocking regressions and documentation fixes only, all changes to the branch require a RM approval now. Quality Data Priority # Change from last report --- --- P10 - 2 P2 258 - 26 P3 36 - 2 P4 155 + 4 P5 22 --- --- Total P1-P3 294 - 30 Total 471 - 26 Previous Report === https://gcc.gnu.org/ml/gcc/2019-02/msg00122.html
Mathematical Statistics Functions for libgo
I was wondering if libgo contained any modules for high precision statistics functions. If it doesn't, would implementing something like that really necessary?
Make LTO Patch for Job Server Thread Detection Agnostic
Greetings Martin,
This patch:
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/lto-wrapper.c;h=353187c60434f43a445e708dcfbf53c857f8cdc1;hp=946897726d03716f7c93f955c438ee4f8190044c;hb=f12fbeb535f192f742025cc4f9b69a48136730f1;hpb=80c7cb9d2c8090f8d165ee2ca5f8d401090c1d06
May have a small problem with the lines:
+ const char *makeflags = getenv ("MAKEFLAGS");
+ if (makeflags == NULL)
+return false; I'm not sure if ninja or other build systems use that
for detection or have it as a variable you can use. This may be an issue
with ninja, cmake and other build systems that may not have it. Maybe
I'm wrong but it may be good to check that, Nick
