[lldb-dev] Assertion failure in DYLDRendezvous::UpdateSOEntries()

[Todd Fiala]

>  I'm not sure if this is a valid transition or not

I'm not sure yet either - can you try another scenario and see if you're
consistently hitting that?  (I mean without Maya --- are you trying to
debug plugins?)  If you are doing some kind of plugin that gets dynamically
loaded, can you write a bare-bones exe that loads a bare-bones shared
library (.so) manually and see if you hit the same issue on that?  I'm just
looking to help isolate the scenario.

The other thing that would be interesting would be to know if maybe there
is an exec (essentially executing another exe) happening in between?  If
that was the case, there might be an issue where a clean sweep call to
reset state isn't doing the right thing.  You might see more info on exec
behavior with 'log enable lldb process'.

Let me know how that goes.

On Fri, Oct 10, 2014 at 7:56 AM, Andrew MacPherson <andrew.macp at gmail.com>
wrote:

> I don't see anything very interesting in the dyld log but it looks like
> we're hitting the breakpoint at
> DynamicLoaderPOSIXDYLD::RendezvousBreakpointHit() where its rendezvous
> state is first eAdd and then hitting it again and the state is eDelete
> without transitioning to eConsistent between eAdd and eDelete. I've never
> looked at this runtime linker stuff before so I'm not sure if this is a
> valid transition or not, this is what's causing the assertion failure
> though. Any idea?
>
> Cheers,
> Andrew
>
> On Thu, Oct 9, 2014 at 5:06 PM, Todd Fiala <tfiala at google.com> wrote:
>
>> I just took a peek at the code around there.  It's not immediately clear
>> whether the assert is entirely useful, but I think it is intending to guard
>> against adding new dynamic library info when the previous state of the data
>> structures are not settled.
>>
>> I think a good starting point for you would be to enable 'log enable lldb
>> dyld' and see what kind of activity is showing up for the existing log
>> lines.  Maybe post that here if that doesn't help.
>>
>> I probably wouldn't remove the assert until we understand the root issue
>> since the assert seems reasonable.
>>
>> Worst case if this doesn't get you further, you can add some if code
>> around the condition and stick a breakpoint in the unexpected case so you
>> can break the debugger in action and inspect what's going on.
>>
>> I hope that gets you started!
>>
>> -Todd
>>
>> On Thu, Oct 9, 2014 at 7:49 AM, Andrew MacPherson <andrew.macp at gmail.com>
>> wrote:
>>
>>> Hi Todd,
>>>
>>> I just backed out your change and the behaviour remained the same. When
>>> I say it's been awhile since I rebuilt though the last build I have around
>>> is from June and it doesn't assert there. Has the default assertion
>>> behaviour changed to enabled by default? I'm building with "cmake -G Ninja
>>> ..".
>>>
>>> In fact checking the June build I don't get an assertion failure (I
>>> assume they're disabled) but the values do differ and I would get one if
>>> they were enabled. So it looks like this issue may have been around for
>>> awhile.
>>>
>>> I can investigate further if you have any pointers around what I might
>>> want to look for.
>>>
>>> Cheers,
>>> Andrew
>>>
>>>
>>> On Thu, Oct 9, 2014 at 3:30 PM, Todd Fiala <tfiala at google.com> wrote:
>>>
>>>> I did a POSIX Dynamic Loader change yesterday.  It might be causing
>>>> this (not obvious yet, but could be.)  r219371.  If you're in a position to
>>>> do a test of your run with that one change reverted out, and if that fixes
>>>> it, I can yank out that change.
>>>>
>>>> Ideally I'd love to isolate if that is the cause of the changed
>>>> behavior.
>>>>
>>>> -Todd
>>>>
>>>> On Thu, Oct 9, 2014 at 4:24 AM, Andrew MacPherson <
>>>> andrew.macp at gmail.com> wrote:
>>>>
>>>>> I just compiled the latest LLDB HEAD on Linux 64-bit and am seeing an
>>>>> assertion failure on launch when debugging a specific application (Autodesk
>>>>> maya):
>>>>>
>>>>> lldb:
>>>>> ../tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp:206:
>>>>> bool DYLDRendezvous::UpdateSOEntries(): Assertion `m_previous.state ==
>>>>> eConsistent' failed.
>>>>>
>>>>> It's been awhile since I've rebuilt from HEAD so not sure when this
>>>>> may have been introduced and simply commenting out the assertion appears to
>>>>> run fine.
>>>>>
>>>>> Does anyone know if this assertion is still relevant and if so have
>>>>> any tips on where I should look to figure out what's happening?
>>>>>
>>>>> Thanks,
>>>>> Andrew
>>>>>
>>>>> _______________________________________________
>>>>> lldb-dev mailing list
>>>>> lldb-dev at cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Todd Fiala | Software Engineer | tfiala at google.com
>>>>
>>>>
>>>
>>
>>
>> --
>> Todd Fiala | Software Engineer | tfiala at google.com
>>
>>
>


-- 
Todd Fiala | Software Engineer | tfiala at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141010/902727da/attachment.html>