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

[Andrew MacPherson]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141010/ded473b6/attachment.html>