[lldb-dev] [BUG?] Confusion between translation units?

[Tamas Berghammer via lldb-dev]

I seen very similar error messages when debugging an application compiled
with fission (split/dwo) debug info on Linux with a release version of LLDB
compiled from ToT. When I tested the same with a debug or with a
release+assert build I hit some assertion inside clang. It might worth a
try to check if the same is happening in your case as it might help finding
out the root cause.

In my case the issue is that we somehow end up with 2 FilldDecl object for
a given field inside one of the CXXRecordDecl object and then when we are
doing a pointer based lookup we will go wrong. I haven't figured out why it
is happening and haven't manage to reproduce it reliably either, but plan
to look into it in the near future if nobody beats me.

Tamas

On Wed, Oct 21, 2015 at 4:46 PM Ramkumar Ramachandra via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

> So first, an addendum: I found a way to make the project build without
> using a symlink, and use a direct reference instead. The problem still
> persists. It may be that symlink is one of the problems, but it is
> certainly not the only problem.
>
> On Tue, Oct 20, 2015 at 8:22 PM, Greg Clayton <gclayton at apple.com> wrote:
> > int
> > Declaration::Compare(const Declaration& a, const Declaration& b)
> > {
> >     int result = FileSpec::Compare(a.m_file, b.m_file, true);
> >     if (result)
>
> Wait, won't FileSpec::Compare be true iff a.m_file is the same as
> b.m_file (excluding symlink resolution)? If so, why are we putting the
> symlink-checking logic in the true branch of the original
> FileSpec::Compare? Aren't we expanding the scope of what we match,
> instead of narrowing it?
>
> >     {
> >         int symlink_result = result;
> >         if (a.m_file.GetFilename() == b.m_file.GetFilename())
> >         {
> >             // Check if the directories in a and b are symlinks to each
> other
> >             FileSpec resolved_a;
> >             FileSpec resolved_b;
> >             if (FileSystem::ResolveSymbolicLink(a.m_file,
> resolved_a).Success() &&
> >                 FileSystem::ResolveSymbolicLink(b.m_file,
> resolved_b).Success())
> >             {
> >                 symlink_result = FileSpec::Compare(resolved_a,
> resolved_b, true);
>
> I'm confused. Shouldn't the logic be "check literal equality; if true,
> return immediately; if not, check equality with symlink resolution"?
>
> >             }
> >         }
> >         if (symlink_result != 0)
> >             return symlink_result;
> >     }
> >     if (a.m_line < b.m_line)
> >         return -1;
> >     else if (a.m_line > b.m_line)
> >         return 1;
> > #ifdef LLDB_ENABLE_DECLARATION_COLUMNS
> >     if (a.m_column < b.m_column)
> >         return -1;
> >     else if (a.m_column > b.m_column)
> >         return 1;
> > #endif
> >     return 0;
> > }
>
> Here's my version of the patch, although I'm not sure when the code
> will be reached.
>
> int
> Declaration::Compare(const Declaration& a, const Declaration& b)
> {
>     int result = FileSpec::Compare(a.m_file, b.m_file, true);
>     if (result)
>         return result;
>     if (a.m_file.GetFilename() == b.m_file.GetFilename()) {
>         // Check if one of the directories is a symlink to the other
>         int symlink_result = result;
>         FileSpec resolved_a;
>         FileSpec resolved_b;
>         if (FileSystem::ResolveSymbolicLink(a.m_file,
> resolved_a).Success() &&
>             FileSystem::ResolveSymbolicLink(b.m_file,
> resolved_b).Success())
>         {
>             symlink_result = FileSpec::Compare(resolved_a, resolved_b,
> true);
>             if (symlink_result)
>                 return symlink_result;
>         }
>     }
>     if (a.m_line < b.m_line)
>         return -1;
>     else if (a.m_line > b.m_line)
>         return 1;
> #ifdef LLDB_ENABLE_DECLARATION_COLUMNS
>     if (a.m_column < b.m_column)
>         return -1;
>     else if (a.m_column > b.m_column)
>         return 1;
> #endif
>     return 0;
> }
>
> If you're confident that this solves a problem, I can send it as a
> code review or something (and set up git-svn, sigh).
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151021/f690e9e3/attachment-0001.html>