[lldb-dev] [Bug 50814] New: Several tests fail with GCC as LLDB can't properly call constructors from expressions
https://bugs.llvm.org/show_bug.cgi?id=50814 Bug ID: 50814 Summary: Several tests fail with GCC as LLDB can't properly call constructors from expressions Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: teempe...@gmail.com CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org Several tests are failing with errors or incorrect results after trying to call a ctor: ``` error: expression failed to parse: error: Couldn't lookup symbols: Foo::MyClass::MyClass() ``` TestCppConstructors TestNamespaceDefinitions TestDeletingImplicitCopyConstructor TestCppOperators (this one can be evaluated but doesn't end up calling the correct ctor as the side effect of calling the ctor can't be observed). -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] Mailing List Status Update
On Wed, Jun 23, 2021 at 12:51 AM Chris Lattner via cfe-dev wrote: > > On Jun 22, 2021, at 6:01 PM, James Y Knight wrote: > > On Mon, Jun 21, 2021 at 3:53 PM Chris Lattner via cfe-dev > wrote: >> >> On Jun 9, 2021, at 10:50 AM, Philip Reames via llvm-dev >> wrote: >> >> Specific to the dev lists, I'm very hesitant about moving from mailing lists >> to discourse. Why? >> >> Well, the first and most basic is I'm worried about having core >> infrastructure out of our own control. For all their problems, mailing >> lists are widely supported, there are many vendors/contractors available. >> For discourse, as far as I can tell, there's one vendor. It's very much a >> take it or leave it situation. The ability to preserve discussion archives >> through a transition away from discourse someday concerns me. I regularly >> and routinely need to dig back through llvm-dev threads which are years old. >> I've also recently had some severely negative customer experiences with >> other tools (most recently discord), and the thought of having my >> employability and ability to contribute to open source tied to my ability to >> get a response from customer service teams at some third party vendor I have >> no leverage with, bluntly, scares me. >> >> Second, I feel that we've overstated the difficulty of maintaining mailing >> lists. I have to acknowledge that I have little first hand experience >> administering mailman, so maybe I'm way off here. >> >> Hi Philip, >> >> First, despite the similar names, Discord is very different than Discourse. >> Here I’m only commenting about Discourse, I have no opinion about Discord. >> >> >> In this case, I think we need to highly weight the opinions of the people >> actively mainlining the existing systems. It has become clear that the >> priority isn’t “control our own lists”, it is “make sure they stay up” and >> “get LLVM people out of maintaining them”. >> >> The ongoing load of maintaining these lists (including moderation) and of >> dealing with the security issues that keep coming up are carried by several >> individuals, not by the entire community. I’m concerned about those >> individuals, but I’m also more broadly concerned about *any* individuals >> being solely responsible for LLVM infra. Effectively every case we’ve had >> where an individual has driving LLVM infra turns out to be a problem. LLVM >> as a project isn’t good at running web scale infra, but we highly depend on >> it. > > > I agree that the maintenance issue is definitely a problem which needs to be > solved. And there is some urgency, given the recent problems which resulted > in a need to manually subscribe people to the lists. > > But, the proposal on the table doesn't appear to actually address this issue, > because the maintainers of llvm mailman will still continue to be responsible > for keeping it functioning, for the mailing lists which were not proposed to > be migrated. On the other hand, having osci.io run a mailman3 service for us > does seem to be a way to solve this -- and doesn't require discarding mailing > lists entirely. > > > I’m not deeply familiar with osci.io, but hosted mailman services all suffer > from a major problem: they don’t solve the moderation problem. Can you explain the moderation problem a bit? As a current mailing list moderator, I'm unaware of unsolved issues in this space and the only mentions about moderation on this thread are vague "we could have better moderation tools" kind of comments without justification as to why they're important enough to necessitate a switch away from email. > More generally, I don’t see how that addresses the many other issues that > were raised repeatedly on this thread. We went through many of these same discussions a while ago about moving away from IRC and email at the same time. There was no community consensus during that discussion, but for various reasons the end result was a fracturing of the community (some people went to Discord, some people stayed on IRC, and now both communities have to tell members "if you don't get an answer here, try on the other service or the mailing lists"). IMO, this left us with a community that's less approachable because new people are never really certain if they're asking their questions "in the right place", especially when a failure to get an answer to their question requires them to try again on a different service. I am worried that a switch from email on the -dev mailing lists to using Discourse will result in a similar fracturing, as discussions will still be possible via email on -commits. To me personally, the possibility of further fracturing the community is a concern I think we need to take very seriously. ~Aaron > > -Chris > > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ lldb-d
Re: [lldb-dev] Reporting bugs which only affect (semi-proprietary) downstream consumers.
Hi Raphael, Thanks for the advice! > I think the best idea is to comment on the commit on Phabricator ( reviews.llvm.org ) as it seems to be a relatively recent change. Otherwise if you can somehow provide way to reproduce the deadlock using only code you can share + LLVM.org sources then filing a bug would be an option too. I'll definitely leave a comment then, as at the very least I should be able to get some feedback on the commit itself. I can't (sadly) reproduce the deadlock using public code - I'm still looking into how we can share our (private) llvm/lldb dependencies so that public parties can build them, so I may hold off on filing a bug until I have sorted that. > At least the backtrace of all threads in the deadlocked state would be good to know. And of course the commit your bisect stopped at if it's a bug report. I can absolutely share all of these, and I'll make sure to include them in any bug report I file. > And I believe you can't use the reproducer feature here as that requires having the respective LLDB binary to replay (which you probably can't share). Our LLDB binaries are publicly available, however there are a number static libraries that we link into our LLVM backend whose source is proprietary, hence why I cannot reproduce the bug using public code. Thanks, Adam On Tue, 22 Jun 2021 at 18:33, Raphael “Teemperor” Isemann < teempe...@gmail.com> wrote: > Hi Adam, > > I think the best idea is to comment on the commit on Phabricator ( > reviews.llvm.org ) as it seems to be a relatively recent change. > Otherwise if you can somehow provide way to reproduce the deadlock using > only code you can share + LLVM.org sources then filing a bug would be an > option too. > > Regarding what information you should provide: Pretty much everything that > you can share would help. At least the backtrace of all threads in the > deadlocked state would be good to know. And of course the commit your > bisect stopped at if it's a bug report. From there people might have an > idea how to reproduce the issue in a unit test or via the SB API (or what > could be going wrong in your downstream fork). > > And I believe you can't use the reproducer feature here as that requires > having the respective LLDB binary to replay (which you probably can't > share). > > - Raphael > > On 22 Jun 2021, at 19:10, Adam HARRIES via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Hi all, > > I've recently taken over maintenance of my company's llvm+lldb branch, > where we have added support for our in-house architecture (in llvm) as well > as support for debugging through both hardware and our simulator. Our llvm > fork is public/open source, however many of our runtime libraries and > drivers (which are linked into lldb, clang, etc, and provide built-ins and > driver support etc) are not. > > While attempting to update our branch from llvm-11 to llvm-12 we came > across a commit[1] in lldb which quite reliably causes a deadlock when we > launch a process to debug a core dump. Luckily, said commit simply modifies > some concurrency primitives, and reverting it is sufficient to fix the bug > without any further effects. We are quite confident that the commit is the > issue, as we performed a thorough bisect which maintained "our" code > unchanged throughout. > > Unfortunately, however, we are unable to reproduce this bug in any "open" > architectures (such as x86-64, AArch64, etc), so are not entirely sure how > we should go about reporting the bug. Additionally, it makes it difficult > to open a discussion regarding whether the commit is correct (and thus we > may need to modify our additions to lldb to match new implicit behaviour), > as third parties may be unable to reproduce the issue. Finally, as the bug > results in a deadlock (which requires a sigkill to end) we won't (as I > understand it) be able to use a "Reproducer" to demonstrate the bug to > third parties. > > Although we are able to "solve" the issue locally (by reverting the > commit), we feel that the better solution would be to feed back our > findings to the community and solve the issue, rather than (privately) > sweeping it under the rug. As components of our compiler are proprietary, > however, this process becomes difficult due to the reasons listed above. > > To summarise, there are two main questions that I feel unable to answer: > - Is there an existing process for reporting bugs that only affect third > parties, and which cannot be reproduced in "core" targets. > - To what extend is it possible to discuss (or report) bugs "on faith" - > as in without any concrete evidence that a third party can reproduce. > > We are currently looking into opening up our build process so that we are > able to distribute binary libraries to enable third parties to build our > compiler + debugger, but as this is currently a work-in-progress it is > unfortunately not a solution to this issue. > > Many thanks in advance for any and all advice. > Yours, > > -- > *A
Re: [lldb-dev] Reporting bugs which only affect (semi-proprietary) downstream consumers.
Hi Greg, Thanks for the advice! > [...] I would suggest just submitting a bug and attaching stack traces of your deadlock. Loading a core file is very similar across all targets, so I can't imagine this being hard to reproduce with another core file? Glad to hear this - I'll do so soon then. I also imagine that this bug affects other "backends", but I can't confirm that myself (due to lack of experience with other lldb backends), so hopefully others will be able to verify it if I file a bug. > Is there something special about your core file or setup? As I understand it there is not that much "weird" about our LLDB integrations. We have made some specific additions to be able to debug threads/processes running on our co-processor and allow printf/debugging information to be passed back to the host, but aside from that we haven't touched any of the core code. It is, however, possible that we've incorrectly subclassed one of the native thread/process classes incorrectly and violated some concurrency invariant. This is part of my hesitation for filing a bug report, as I'm not sure whether the commit itself was at fault, or whether we accidentally relied on some incorrect concurrency behaviour which has now been corrected, leaving our plugin broken. > I would go ahead and debug the deadlock, attach repro steps for how you are loading your core file (exact commands or APIs that are being used) and then maybe attach the output "bt all" so we can see all of the threads and see what is deadlocking your LLDB. Okay, thanks for the advice regarding what would be good to include. I'll make sure to add as much of this as I can when I file the bug report. Thanks again, Adam On Tue, 22 Jun 2021 at 18:34, Greg Clayton wrote: > > > On Jun 22, 2021, at 10:10 AM, Adam HARRIES via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Hi all, > > I've recently taken over maintenance of my company's llvm+lldb branch, > where we have added support for our in-house architecture (in llvm) as well > as support for debugging through both hardware and our simulator. Our llvm > fork is public/open source, however many of our runtime libraries and > drivers (which are linked into lldb, clang, etc, and provide built-ins and > driver support etc) are not. > > While attempting to update our branch from llvm-11 to llvm-12 we came > across a commit[1] in lldb which quite reliably causes a deadlock when we > launch a process to debug a core dump. Luckily, said commit simply modifies > some concurrency primitives, and reverting it is sufficient to fix the bug > without any further effects. We are quite confident that the commit is the > issue, as we performed a thorough bisect which maintained "our" code > unchanged throughout. > > Unfortunately, however, we are unable to reproduce this bug in any "open" > architectures (such as x86-64, AArch64, etc), so are not entirely sure how > we should go about reporting the bug. Additionally, it makes it difficult > to open a discussion regarding whether the commit is correct (and thus we > may need to modify our additions to lldb to match new implicit behaviour), > as third parties may be unable to reproduce the issue. Finally, as the bug > results in a deadlock (which requires a sigkill to end) we won't (as I > understand it) be able to use a "Reproducer" to demonstrate the bug to > third parties. > > Although we are able to "solve" the issue locally (by reverting the > commit), we feel that the better solution would be to feed back our > findings to the community and solve the issue, rather than (privately) > sweeping it under the rug. As components of our compiler are proprietary, > however, this process becomes difficult due to the reasons listed above. > > To summarise, there are two main questions that I feel unable to answer: > - Is there an existing process for reporting bugs that only affect third > parties, and which cannot be reproduced in "core" targets. > > > I don't believe there is a formal process for this. Though I would suggest > just submitting a bug and attaching stack traces of your deadlock. Loading > a core file is very similar across all targets, so I can't imagine this > being hard to reproduce with another core file? Is there something special > about your core file or setup? I know that logging used to be able to cause > deadlocks due to the Module::GetDescription(...) that tried to take the > module lock. It no longer does this on top of tree. > > - To what extend is it possible to discuss (or report) bugs "on faith" - > as in without any concrete evidence that a third party can reproduce. > > We are currently looking into opening up our build process so that we are > able to distribute binary libraries to enable third parties to build our > compiler + debugger, but as this is currently a work-in-progress it is > unfortunately not a solution to this issue. > > Many thanks in advance for any and all advice. > Yours, > > > I would go ahead and debug the deadlock, attac
Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing List Status Update
On Wed, 23 Jun 2021 at 13:59, Tobias Hieta via llvm-dev < llvm-...@lists.llvm.org> wrote: > I am very active in the Discord and try my best to help people and > while I often refer people to post to the mailing list if they can't > find an answer, I have never and never seen anyone direct new people > to the IRC channel. > Well, it's not surprising that people who use Discord don't propose the use of IRC (and vice versa), but this doesn't make the community less fractured. One thing I haven't seen in this discussion is the fact that Discord > and Discourse is way more approachable for people who haven't used IRC > and email their whole life. I understand there must be a balance > between keeping current contributors happy and attracting new ones. > But keeping discussions in the mail-list over discourse would (In MY > opinion) favor current/older contributors way higher than newer ones. > Attracting new people is very important for open source projects. Older people (like me) tend to be a lot less passionate about changes. But this is not a goal per se, just a constraint on other goals. The main objective of the list is to discuss the project, long and hard issues, and both old and new people can use mailing lists with pretty much any mail client out there. If the argument to move to Discourse is because it's better for long and hard discussions for the majority of the community, then that's a clear signal. If it's just because it's where all the cool kids are these days, then I think we're looking for the wrong goals. 5 years ago, all cool kids (*) were using Slack, now they're using Discourse / Discord, who knows where they'll all be in 5 years time? I don't think popularity should be a factor in choosing a new tool, or we'll be eternally chasing doomed platforms. cheers, -renato PS (*): My definition of "cool kids" may be different than yours, Slack probably was never "cool" for the masses... But we're hopefully not considering Instagram any time soon. :D ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Mailing List Status Update
On 6/21/21 12:53 PM, Chris Lattner wrote: On Jun 9, 2021, at 10:50 AM, Philip Reames via llvm-dev mailto:llvm-...@lists.llvm.org>> wrote: Specific to the dev lists, I'm very hesitant about moving from mailing lists to discourse. Why? Well, the first and most basic is I'm worried about having core infrastructure out of our own control. For all their problems, mailing lists are widely supported, there are many vendors/contractors available. For discourse, as far as I can tell, there's one vendor. It's very much a take it or leave it situation. The ability to preserve discussion archives through a transition away from discourse someday concerns me. I regularly and routinely need to dig back through llvm-dev threads which are years old. I've also recently had some severely negative customer experiences with other tools (most recently discord), and the thought of having my employability and ability to contribute to open source tied to my ability to get a response from customer service teams at some third party vendor I have no leverage with, bluntly, scares me. Second, I feel that we've overstated the difficulty of maintaining mailing lists. I have to acknowledge that I have little first hand experience administering mailman, so maybe I'm way off here. Hi Philip, Hi Chris, First, despite the similar names, Discord is very different than Discourse. Here I’m only commenting about Discourse, I have no opinion about Discord. I'm aware, thank you. I'm sorry that my wording seems to have caused confusion on this point. In this case, I think we need to highly weight the opinions of the people actively mainlining the existing systems. It has become clear that the priority isn’t “control our own lists”, it is “make sure they stay up” and “get LLVM people out of maintaining them”. The ongoing load of maintaining these lists (including moderation) and of dealing with the security issues that keep coming up are carried by several individuals, not by the entire community. I’m concerned about those individuals, but I’m also more broadly concerned about *any* individuals being solely responsible for LLVM infra. Effectively every case we’ve had where an individual has driving LLVM infra turns out to be a problem. LLVM as a project isn’t good at running web scale infra, but we highly depend on it. It seems clear to me that we should outsource this to a proven vendor. I agree with everything you said up to here. The goals make sense, and I fully support them. Your concerns about discourse seem very similar to the discussion about moving to Github (being a single vendor who was once much smaller than Microsoft). I think your concerns are best addressed by having the IWG propose an answer to “what is our plan if Discourse-the-company goes sideways?" This is where I disagree. The key point for me is that mailman3 exists and there are commercial vendors who specialize in exactly what we need. I don't object at all to having a proven vendor. I just don't see discourse as being the obvious choice. Now, as I said in my first email, you don't actually need to convince me here. If the move is made to discourse, I will follow. At the end of the day, a decision does need to be made, and I'm willing to defer to those putting in the work. Philip ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
