pg_regress running for ~10 hours using 100% CPU
От | Thomas Munro |
---|---|
Тема | pg_regress running for ~10 hours using 100% CPU |
Дата | |
Msg-id | CADLWmXW=yMiy-eeBzpwukpHd7iFywXXqHGt6tZEanLOZStyWXg@mail.gmail.com обсуждение исходный текст |
Список | pgsql-hackers |
Hi Buildfarm machine lyrebird, clang 2.9, amd64, Debian 6, 'HEAD'. I have been unsuccessful in finding out what it's doing using gdb: pg_animal@asterix:~/work/HEAD/pgsql$ gdb --pid=10681 GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Attaching to process 10681 Reading symbols from /home/pg_animal/work/HEAD/pgsql.2325/src/test/regress/pg_regress...done. Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Die: DW_TAG_restrict_type (abbrev 48, offset 0x4adf) parent at offset: 0x3ebe has children: FALSE attributes: DW_AT_type(DW_FORM_ref4) constant ref: 0x4115 (adjusted) Dwarf Error: Cannot find type of die [in module /home/pg_animal/work/HEAD/pgsql.2325/src/test/regress/pg_regress] Asking GDB anything generates similar messages. It seems like this might be related to a known clang/dwarf/gdb bug (apparently experienced by many MacOS users and the Chromium project, based on cursory googling), and possibly not related to whatever difficulty pg_regress is having. So I don't actually have anything useful to report here unfortunately... but thought I should write a note since I'll suppose when I kill it it'll show up as a failure. Unfortunately I don't have time to dig further currently. Thomas
В списке pgsql-hackers по дате отправления: