[lldb-dev] [Bug 38687] New: Crash when dumping symbols from DSYM using Python API
https://bugs.llvm.org/show_bug.cgi?id=38687 Bug ID: 38687 Summary: Crash when dumping symbols from DSYM using Python API Product: lldb Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: radu.la...@me.com CC: llvm-b...@lists.llvm.org Created attachment 20763 --> https://bugs.llvm.org/attachment.cgi?id=20763&action=edit crash log Description: When looping through the architectures present in a DSYM file, querying the target GetDescription() crashes. The DSYM file has symbols for armv7, armv7s, arm64. The crash occurs on the second iteration when creating the armv7s target. The crash does not occur if I loop without parsing the symbols Steps: for arch in getArchitectures(dsymFile): error = lldb.SBError() target = debugger.CreateTarget(dsymFile, 'none-none-' + arch, None, False, error) targetDescr = lldb.SBStream() target.GetDescription(targetDescr, lldb.eDescriptionLevelFull); -> crash #enumerate all compile units #enumerate all symbols Actual result: Segmentation fault: 11 Expected result: Get the description and not crash MacOS High Sierra 10.13.6 Xcode 9.3(9E145) -- 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
Re: [lldb-dev] [7.0.0 Release] rc2 has been tagged
On Wed, Aug 22, 2018 at 4:59 PM, Hans Wennborg wrote: > > Please run the test script, share the results, and upload binaries. Note: to upload, we now need to use prereleases-origin.llvm.org instead of prereleases.llvm.org. This is because the latter now points to the CDN. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Announcing some new bots on green-dragon
Some of you may have noticed that green dragon underwent some changes this last week. On http://green.lab.llvm.org/green/view/LLDB/ we now have the following configurations that are being tested: - http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/ [New configuration in zorg] Release+Asserts build of the most current llvm/clang/lldb. - http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-clang-5.0.2/ [New!] Release+Asserts build of the most current LLDB, running the testsuite against clang 5.0.2. - http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-clang-6.0.1/ [New!] Release+Asserts build of the most current LLDB, running the testsuite against clang 6.0.1. - http://green.lab.llvm.org/green/view/LLDB/job/lldb-sanitized/ [New!] RelWithDebInfo build of the most current LLDB with address and undefined behavior sanitizer enabled, running the testsuite against the latest (non-sanitized) stage1 compiler. - http://green.lab.llvm.org/green/view/LLDB/job/lldb-xcode/ LLDB being built from the Xcode project. (This one hasn't changed). Note that the sanitizer bot is currently failing because it actually detected some UB issues in the data formatters — so it already payed for itself. I hope that especially the sanitizer bot will prove to be very useful for the community. All of the new bots are incremental; they produce a new result ~ every 15 min depending on how much changed. Please let me know if you run into any issues with the new configurations! -- adrian ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [7.0.0 Release] rc2 has been tagged
On Wed, Aug 22, 2018 at 4:59 PM, Hans Wennborg wrote: > Please run the test script, share the results, and upload binaries. Windows: $ sha1sum LLVM-7.0.0-rc2*.exe e9e241eea5ded7692b0d57a4943b56dce293634f LLVM-7.0.0-rc2-win32.exe 75ebb78fa75254287090baa4ab0b0911fc16fa47 LLVM-7.0.0-rc2-win64.exe They were built with the attached batch file. build_llvm_700-rc2._bat_ Description: Binary data ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged
On Wed, Aug 22, 2018 at 10:33 PM, Dimitry Andric wrote: > On 22 Aug 2018, at 18:45, Hans Wennborg wrote: >> >> On Wed, Aug 22, 2018 at 3:48 AM, Dimitry Andric wrote: >>> On 22 Aug 2018, at 05:58, Wei Mi wrote: On Fri, Aug 17, 2018 at 1:27 PM, Dimitry Andric wrote: On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev wrote: > On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev > wrote: >> This is a regression caused by https://reviews.llvm.org/rL323281: >> >> >> r323281 | wmi | 2018-01-23 23:27:57 + (Tue, 23 Jan 2018) | 12 lines >> >> Adjust MaxAtomicInlineWidth for i386/i486 targets. >> >> This is to fix the bug reported in >> https://bugs.llvm.org/show_bug.cgi?id=34347#c6. >> Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. >> However, >> i386 doesn't support any cmpxchg related instructions. i486 only >> supports cmpxchg. >> So in this patch MaxAtomicInlineWidth is reset as follows: >> For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is >> supported. >> For i486, the MaxAtomicInlineWidth should be 32 because it supports >> cmpxchg. >> For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 >> because of cmpxchg8b. > > This seems to be somewhat undesirable. Does *anyone* care about real > i386 support at this point? NetBSD certainly doesn't and I think we are > already the odd man for a number of cases like this. Yes, and since this causes quite a number of regressions for us, I would really prefer this revision to be reverted, at least in the 7.0.0 branch. I have already reverted it locally in our FreeBSD project branch for importing llvm/clang 7.0.0. Hans, what is your opinion about this? -Dimitry Sorry I missed the thread for quite a while. Dimitry, I am very confused because you reported the issue in https://bugs.llvm.org/show_bug.cgi?id=34347#c6, so you want r323281 to be reverted and let llvm to generate cmxchg8b instruction for i486? >>> >>> Since it's been doing this for a number of years now, I don't think it >>> would be bad at all, at least not for FreeBSD. At least, a lot more effort >>> is needed to supply properly working atomic libcalls for 64 bit values on >>> i386. (They can't be implemented without at least a bit of kernel >>> assistance.) >> >> According to the release schedule we should tag RC2 today. Do you >> think there's any chance of getting this figured out by today? > > Since I'm testing on FreeBSD 11.x, and that will take quite a while to get > any new changes, I'd say it's safer to revert for now, at least on the > branch. At least then I can build and test the RCs on i386-freebsd. :) I've reverted on trunk in r340666 and merged to the 7.0 branch in r340667. Also +Craig fyi for X86. Unfortunately this happened after RC2 which was tagged yesterday, but perhaps you can do a test run against the tip of the branch, and then later RC3 of coures? Also, is there a bug filed somewhere to track fixing the FreeBSD side? It would be great if we could reinstate this patch again before the next release. Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
