Re: [lldb-dev] [3.8 Release] RC2 has been tagged
Here's a quick update > clang+llvm-3.8.0-rc2-x86_64-linux-gnu-debian8.tar.xz (sha1sum: > 2b546efa5bab19d6711771ef31711d07b4a3f23f) > Native: > All ok > Cross compiling to various MIPS targets: > 16 out of 23 configs passed > 1 out of the remaining 7 failed a small number of tests with a > timeout. I expect these will pass when I re-run them. > Remaining 6 configs still running... For cross-compilation, it's now 22 out of 23 passing. The remaining config had fewer timeouts on the re-run but not all of them went away. I'm re-running the last two timeouts while my machine is less busy. > clang+llvm-3.8.0-rc2-mips-linux-gnu.tar.xz (sha1sum: > b46221e1bb54255e9e060f06bb72bb2ba630ff15) > Failed to run check-all due to tsan'd libc++ build failing > PR26278 - My fix for this was committed just after the rc2 tag > so in order to get some check-all results, I applied those four patches > (r25966[1456]) and re-ran check-all. > PR26369 - Several failures related to the lack of -latomic > which is needed for 64-bit atomics. > PR26476 - One new failure in libc++ (I probably just missed it > amongst the others). Apparently std::regex_traits says that '-' doesn't belong > to the 'w' class but only on big-endian. > check-all appears to hang at 99%. I'll look into this. > LNT (using the clean rc2) > 1 of 3 passed successfully, the other two are still running LNT finished successfully and everything passed. I've identified the hanging test. It's a mips64 msan test so I'm planning to mark it UNSUPPORTED (XFAIL will still hang) since this isn't a regression on the last release. We're still investigating PR26476, and we're also trying to get PR26369 committed+merged. > clang+llvm-3.8.0-rc2-mipsel-linux-gnu.tar.xz (sha1sum: > 9f89cccfdb5cf6a27138b84a631003c4a04f456d) > Build almost ok. I only have failures related to PR26369. > LNT just started. All ok aside from PR26369. > > -Original Message- > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Hans > > Wennborg via lldb-dev > > Sent: 02 February 2016 21:16 > > To: release-test...@lists.llvm.org > > Cc: llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB > Dev > > Subject: [lldb-dev] [3.8 Release] RC2 has been tagged > > > > Dear testers, > > > > Release Candidate 2 has just been tagged [1]. Please build, test, and > > upload to the sftp. > > > > I know there are still outstanding issues from RC1, but there have > > been a lot of merges going into the branch and I think it's time for > > another round of RC testing. > > > > This RC comes a little behind schedule, sorry about that, but I'm > > still optimistic about hitting the target of releasing towards the end > > of February. > > > > Thanks for all the work you've put into this release so far! > > > > Hans > > > > [1] http://lists.llvm.org/pipermail/llvm-branch-commits/2016- > > February/009739.html > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB does some deep recursion into external modules to resolve name lookups
Hi Sean, Can you gave us some more context on this because without access to the referenced rdar bug I don't really understand your previous e-mail (and I think I am not alone with this) Thanks, Tamas On Wed, Feb 10, 2016 at 2:54 AM Sean Callanan via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I’ve been investing the “po performance bug” ( po > when debugging Xcode is extremely slow) in recent Xcode, and I discovered > this problem. > > We are looking at pch files that are generated on Xcode’s behalf and it > looks like we’re recursing through their dependencies when we don’t find > something, but we’re probably not searching efficiently because this is > super slow. > > This would be an Everest regression. > > I’m going to keep working on the original Radar because I haven’t gotten > Brent’s backtrace yet; that said, this one is going to affect users’ > perception of expression parser performance as well so I’ve filed it > separately. > > Sean > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB does some deep recursion into external modules to resolve name lookups
Is it related to the regression that Greg was talking about here: http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20160208/027449.html On Wed, Feb 10, 2016 at 2:20 AM, Tamas Berghammer via lldb-dev wrote: > Hi Sean, > > Can you gave us some more context on this because without access to the > referenced rdar bug I don't really understand your previous e-mail (and I > think I am not alone with this) > > Thanks, > Tamas > > On Wed, Feb 10, 2016 at 2:54 AM Sean Callanan via lldb-dev > wrote: >> >> I’ve been investing the “po performance bug” ( po >> when debugging Xcode is extremely slow) in recent Xcode, and I discovered >> this problem. >> >> We are looking at pch files that are generated on Xcode’s behalf and it >> looks like we’re recursing through their dependencies when we don’t find >> something, but we’re probably not searching efficiently because this is >> super slow. >> >> This would be an Everest regression. >> >> I’m going to keep working on the original Radar because I haven’t gotten >> Brent’s backtrace yet; that said, this one is going to affect users’ >> perception of expression parser performance as well so I’ve filed it >> separately. >> >> Sean >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 26565] New: test_expr_with_macros_dwarf (TestMacros.TestMacros) failing on FreeBSD 11
https://llvm.org/bugs/show_bug.cgi?id=26565 Bug ID: 26565 Summary: test_expr_with_macros_dwarf (TestMacros.TestMacros) failing on FreeBSD 11 Product: lldb Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: ema...@freebsd.org CC: llvm-b...@lists.llvm.org Classification: Unclassified Command invoked: /usr/home/user/llvm/tools/lldb/test/dotest.py -q --arch=x86_64 --executable /usr/home/user/llvm/build/bin/lldb -s /usr/home/user/llvm/build/lldb-test-traces -u CXXFLAGS -u CFLAGS -C /usr/bin/cc --results-port 52272 --inferior -p TestMacros.py /usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test --event-add-entries worker_index=2:int FAIL: LLDB (/usr/bin/cc-x86_64) :: test_expr_with_macros_dwarf (TestMacros.TestMacros) == FAIL: test_expr_with_macros_dwarf (TestMacros.TestMacros) -- Traceback (most recent call last): File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1452, in dwarf_test_method return attrvalue(self) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/decorators.py", line 92, in wrapper func(*args, **kwargs) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/decorators.py", line 92, in wrapper func(*args, **kwargs) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/decorators.py", line 92, in wrapper func(*args, **kwargs) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/expression_command/macros/TestMacros.py", line 50, in test_expr_with_macros self.assertTrue(result.IsValid() and result.GetValue() == "100", "MACRO_1 = 100") AssertionError: False is not True : MACRO_1 = 100 Config=x86_64-/usr/bin/cc -- Ran 1 test in 0.248s Found while getting the tests running again on the FreeBSD buildbot; system compiler is "FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906" This test does not fail for me on my desktop running a FreeBSD 10.x snapshot (around FreeBSD 10.3); system compiler is "FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512". -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 26566] New: test_with_run_command_dwarf (TestDataFormatterLibcxxListLoop.LibcxxListDataFormatterTestCase) failing on FreeBS 11
https://llvm.org/bugs/show_bug.cgi?id=26566
Bug ID: 26566
Summary: test_with_run_command_dwarf
(TestDataFormatterLibcxxListLoop.LibcxxListDataFormatt
erTestCase) failing on FreeBS 11
Product: lldb
Version: unspecified
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: ema...@freebsd.org
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
Command invoked: /usr/home/user/llvm/tools/lldb/test/dotest.py -q --arch=x86_64
--executable /usr/home/user/llvm/build/bin/lldb -s
/usr/home/user/llvm/build/lldb-test-traces -u CXXFLAGS -u CFLAGS -C /usr/bin/cc
--results-port 52272 --inferior -p TestDataFormatterLibcxxListLoop.py
/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test
--event-add-entries worker_index=3:int
FAIL: LLDB (/usr/bin/cc-x86_64) :: test_with_run_command_dwarf
(TestDataFormatterLibcxxListLoop.LibcxxListDataFormatterTestCase)
==
FAIL: test_with_run_command_dwarf
(TestDataFormatterLibcxxListLoop.LibcxxListDataFormatterTestCase)
--
Traceback (most recent call last):
File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1452, in dwarf_test_method
return attrvalue(self)
File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/decorators.py",
line 121, in wrapper
func(*args, **kwargs)
File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/loop/TestDataFormatterLibcxxListLoop.py",
line 42, in test_with_run_command
self.expect("frame variable *numbers_list", substrs=['[0] = 1', '[1] = 2',
'[2] = 3', '[3] = 4', '[5] = 6'])
File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1904, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : '[0] = 1' returns expected result
Config=x86_64-/usr/bin/cc
Found while getting the tests running again on the FreeBSD buildbot; system
compiler is "FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257)
20150906"
This test does not fail for me on my desktop running a FreeBSD 10.x snapshot
(around FreeBSD 10.3); system compiler is "FreeBSD clang version 3.4.1
(tags/RELEASE_34/dot1-final 208032) 20140512".
--
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 26567] New: Backtrace missing frames while debugging breakpad generated minidump
https://llvm.org/bugs/show_bug.cgi?id=26567 Bug ID: 26567 Summary: Backtrace missing frames while debugging breakpad generated minidump Product: lldb Version: unspecified Hardware: PC OS: other Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: joshual...@google.com CC: llvm-b...@lists.llvm.org Classification: Unclassified I am trying out the minidump target on the windows lldb builds. My test was to debug a windows minidump generated through breakpad using lldb/trunk@259885 I've attached: The executable with debug symbols (cross compiled from linux with mingw-gcc). This was used to generate the breakpad symbols. The minidump generated through breakpad The stack trace that I get from lldb Using breakpad's stackwalk tool I see the following stack trace (truncated) which has the correct stack trace. Report ID859ac030 Total Threads43 Processed Threads43 Thread 1 CRASHED [EXCEPTION_ACCESS_VIOLATION_READ @ 0x ] 0x005c1f13(emulator-x86.exe -console.c:2606 )do_crash 0x005be45b(emulator-x86.exe -console.c:427 )control_client_do_command 0x005be713(emulator-x86.exe -console.c:513 )control_client_read_byte 0x005bea56(emulator-x86.exe -console.c:572 )control_client_read 0x00459d65(emulator-x86.exe -Looper.cpp:129 ) android::qemuQemuLooper::FdWatch::fire 0x0045aac0(emulator-x86.exe -Looper.cpp:329 ) android::qemuQemuLooper::handleBottomHalf 0x00408942(emulator-x86.exe -async.c:150 )qemu_bh_poll 0x004a2f3a(emulator-x86.exe -main-loop.c:307 )main_loop_wait 0x004a2f83(emulator-x86.exe -main-loop.c:333 )main_loop 0x004bd73a(emulator-x86.exe -vl-android.c:3853 )qemu_main 0x0045c0e6(emulator-x86.exe -main.c:155 )enter_qemu_main_loop 0x007fb32d(emulator-x86.exe -emulator-qt-window.h:64 ) MainLoopThread::run 0x6696291d(Qt5Core.dll + 0x0002291d ) 0x76e67faf(msvcrt.dll + 0x00017faf ) 0x76e680f4(msvcrt.dll + 0x000180f4 ) 0x75677c03(kernel32.dll + 0x00017c03 ) 0x778fad6e(ntdll.dll + 0x0005ad6e ) 0x778fad39(ntdll.dll + 0x0005ad39 ) Thread 0 0x778dc9ec(ntdll.dll + 0x0003c9ec ) 0x7550dcc2(user32.dll + 0xdcc2 ) 0x66b6d1af(Qt5Core.dll + 0x0022d1af ) 0x6dee4580(qwindows.dll + 0x00024580 ) 0x66b164a5(Qt5Core.dll + 0x001d64a5 ) 0x66b1e467(Qt5Core.dll + 0x001de467 ) 0x0053d116(emulator-x86.exe -winsys-qt.cpp:115 ) skin_winsys_enter_main_loop 0x0045e4e5(emulator-x86.exe -main.c:1030 )qt_main 0x0053e997(emulator-x86.exe -winsys-qt.cpp:397 )qMain 0x00402801(emulator-x86.exe -qtmain_win.cpp:113 )WinMain 0x0089f3ec(emulator-x86.exe -crt0_c.c:18 )main 0x00401401(emulator-x86.exe -crtexe.c:315 )__tmainCRTStartup 0x75677c03(kernel32.dll + 0x00017c03 ) 0x778fad6e(ntdll.dll + 0x0005ad6e ) 0x778fad39(ntdll.dll + 0x0005ad39 ) Thread 2 0x778dc47c(ntdll.dll + 0x0003c47c ) 0x77222c01(KERNELBASE.dll + 0x2c01 ) 0x005e7637(emulator-x86.exe -ConditionVariable_win32.cpp:91 ) android::base::ConditionVariable::wait 0x005b4297(emulator-x86.exe -WearAgent.cpp:261 ) android::wear::WearAgentImpl::connectToAdbHostWorker 0x005b4a84(emulator-x86.exe + 0x001b4a84 ) 0x005b5197(emulator-x86.exe -functional:2057 ) std::_Function_handler::_M_invoke 0x00845ce9(emulator-x86.exe -functional:2471 ) std::function::operator() 0x005e19c5(emulator-x86.exe -FunctorThread.cpp:29 ) android::base::FunctorThread::main 0x005e7e0c(emulator-x86.exe -Thread_win32.cpp:127 ) android::base::Thread::thread_main 0x75677c03(kernel32.dll + 0x00017c03 ) 0x778fad6e(ntdll.dll + 0x0005ad6e ) 0x778fad39(ntdll.dll + 0x0005ad39 ) Thread 3 0x778dc47c(ntdll.dll + 0x0003c47c ) 0x77222c01(KERNELBASE.dll + 0x2c01 ) 0x005e7637(emulator-x86.exe -ConditionVariable_win32.cpp:91 ) android::base::ConditionVariable::wait 0x005dcfcd(emulator-x86.exe -MessageChannel.cpp:51 ) android::base::MessageChannelBase::beforeRead 0x00823812(emulator-x86.exe -MessageChannel.h:87 ) android::base::MessageChannel::receive 0x007f9f61(emulator-x86.exe -camera-capture-windows.cpp:905 ) CameraThread::main 0x005e7e0c(emulator-x86.exe -Thread_win32.cpp:127 ) android::base::Thread::thread_main 0x75677c03(kernel32.dll + 0x00017c03 ) 0x778fad6e(ntdll.dll + 0x0005ad6e ) 0x778fad39(ntdll.dll + 0x0005ad39 ) When I use lldb, I get the following backtrace which has some similar frames but some threads are basically empty. For example, Thread 2 below is Thread 1 in the above stacktrace due to start at 0 count but there are only kernel frames even though
