There is an assert in DWARFDIE.cpp (lines 189 - 191) that we’re hitting on the OS X side somewhat frequently nowadays:
assert ((id&0xffffffff00000000ull) == 0 ||
(cu_id&0xffffffff00000000ll) == 0 ||
(id&0xffffffff00000000ull) == (cu_id&0xffffffff00000000ll));
It does not seem to get hit consistently. We’re trying to tease apart what it is trying to do. It’s a bit strange since it is saying that the assert should not fire if any one of three clauses is true. But it’s hard to figure out what exactly is going on there.
Can you elucidate what this is trying to do? Thanks!
The 64 bit ID of a DIE is built up in the following way:
- The offset of the DIE is in the lower 32 bit
- If we are using SymbolFileDWARF then the higher 32 bit is the offset of the compile unit this DIE belongs to
- If we are using SymbolFileDWARFDwo then the higher 32 bit is the offset of the base compile unit in the parent SymbolFileDWARF
- If we are using SymbolFileDWARFDebugMap then the higher 32 bit is the ID of the SymbolFileDWARF this DIE belongs to
- If the higher 32 bit is 0 then that means that the source of the DIE isn’t specified
The assert then tries to verify that one of the following conditions holds:
- The higher 32 bit of “id” is 0 what means that we don’t have a symbol file pointer (AFAIK shouldn’t happen) or we are coming from a SymbolFileDWARF
- The higher 32 bit of “cu_id” is 0 what means that the compile unit is at 0 offset what is the case for the single compile units in SymbolFileDWARFDwo (and I think for SymbolFileDWARFDebugMap)
- The higher 32 bit of “id” (what is the ID of the SymbolFileDWARF we are belonging to) matches with the higher 32 bit of “cu_id” (what is the offset of the compile unit in the base object file)
After thinking a bit more about the assert I think the problem is that the way I calculate cu_id is incompatible for the case when we are using SymbolFileDWARFDebugMap.
I think changing line 188 to the following should fix the issue:
lldb::user_id_t cu_id = m_cu->GetID()&0xffffffff00000000ull;
Please give it a try on OSX and let me know if it helps. I tested it on Linux and it isn’t cause any regression there.
Okay! I’ll give that a shot now and report back what I find.
I’m re-running the tests to make sure, but I think that fixed it. I had always seen it at least once on test runs locally, but didn’t see it on the last one.
This seems to be working. I put it up for review here, Tamas: