fjricci abandoned this revision.
fjricci added a comment.
I'm not going to get to this
https://reviews.llvm.org/D41909
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg added a comment.
Yeah, the threading was added later. It started out as single threaded and
didn't have this problem.
https://reviews.llvm.org/D41909
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/m
zturner added a comment.
Seems like the high level problem is that the entity which acquires the mutex
is not the same as the entity which decides how data gets into the Module. For
example, we call `SymbolVendor::FindFunctions` and expect that someone is going
to somehow get some functions in
clayborg added a comment.
We will need to pass the mutex down into any call that needs to let the mutex
go. At least that is the only way I could see this working... But then all
functions that do anything lazily will need this same treatment. Lot of trouble
for the logging.
https://reviews.l
fjricci added a comment.
> SymbolVendor::FindFunctions will lazily parse functions from the debug info
> and populate things inside the module, so the lock is required.
Can it give up the lock while it's blocked on worker threads? Holding a lock
while blocked seems like a recipe for deadlocks (
clayborg added a comment.
In https://reviews.llvm.org/D41909#973299, @tberghammer wrote:
> Why do we need to lock the Module mutex in SymbolVendor::FindFunctions? I
> think a better option would be to remove that lock and if it is needed then
> lock it just for the calls where it necessary. The
fjricci added a comment.
> I think a better option would be to remove that lock and if it is needed then
> lock it just for the calls where it necessary. The fact that SymbolVendor
> locks a mutex inside a Module feels like a pretty bad layering violation for
> me what can cause many other dead
tberghammer added a comment.
I think it isn't an A/B locking issue. The problem is that 2 different thread
(main thread and 1 of the DWARF indexer thread) want to lock the mutex at the
same time.
I have a mixed feeling about this change because introducing any sort of race
condition (even if i
clayborg added a comment.
Tough to call on this one. Yes the function is dumping simple stuff, but it is
using m_arch, m_file and m_objname. It could cause crashes in multi-threaded
environments. Is the deadlock caused by an A/B lock issue?
https://reviews.llvm.org/D41909
__
fjricci added a comment.
It's definitely possible to re-design the lock holding in such a way that we
can keep this locked, but I don't want to go through all the work to do that if
there isn't any added value to doing so.
https://reviews.llvm.org/D41909
fjricci added a comment.
Actually I don't think even that is racy, because we just get a pointer to the
const char *, which is immutable anyway.
https://reviews.llvm.org/D41909
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.
fjricci added a comment.
I guess the question is whether we expect that someone will do something like
change the module's filepath while we're printing a log message with that
filepath in it.
https://reviews.llvm.org/D41909
___
lldb-commits maili
zturner added a comment.
`GetDescription` might be read only, but the code that modifies the description
isn't, right?
https://reviews.llvm.org/D41909
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/l
fjricci created this revision.
fjricci added reviewers: clayborg, zturner, tberghammer.
Herald added subscribers: JDevlieghere, aprantl.
When dwarf parse logging is enabled (ie `log enable dwarf info`),
deadlocks can occur during dwarf parsing:
Thread 1:
`SymbolVendor::FindFunctions` (acquires mu
14 matches
Mail list logo
