I ran everything with LD_DEBUG=all to see what was being loaded around the
assertion and tracked it down to a dlopen() on a library that exists but
that has unmet dependencies of its own. Writing a trivial C program causes
the same assertion failure:
#include <dlfcn.h>
int main()
{
dlopen("./libqmng.so", RTLD_NOW);
return 0;
}
Where "ldd libqmng.so" gives:
linux-vdso.so.1 => (0x00007fffe61fe000)
libmng.so.1 => not found
...
So it looks like this may be a valid transition on a failed dlopen() call?
On Fri, Oct 10, 2014 at 5:12 PM, Todd Fiala <tfi...@google.com> wrote:
> > 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.m...@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 <tfi...@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.m...@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 <tfi...@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.m...@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@cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Todd Fiala | Software Engineer | tfi...@google.com
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Todd Fiala | Software Engineer | tfi...@google.com
>>>
>>>
>>
>
>
> --
> Todd Fiala | Software Engineer | tfi...@google.com
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
