[SERVER-48348] ninja next is incorrectly generating header file dependencies Created: 21/May/20 Updated: 29/Oct/23 Resolved: 26/May/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Build |
| Affects Version/s: | None |
| Fix Version/s: | 4.4.0-rc7, 4.7.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kevin Pulo | Assignee: | Andrew Morrow (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Backport Requested: |
v4.4
|
||||||||||||
| Sprint: | Dev Platform 2020-06-01 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
This is on 6696c3edd28, with ninja 1.8.2 on Ubuntu 18.04, and a scons cmdline of:
and a full working build of install-core. I made a change to VectorClock in db/vector_clock.h to add an unused protected pure virtual function, and then implementations in db/vector_clock_mongod.cpp, db/vector_clock_trivial.cpp, and s/commands/vector_clock_mongos.cpp:
After making this change, running ninja install-core with ninja next rebuilds only 40 targets
which reliably crashes (for me) with a MONGO_UNREACHABLE in the JournalFlusher on the first config server. Again, this crash does not happen if the procedure is repeated with ninja stable instead of next. If the change applied is even further reduced to just:
then running ninja reports:
which is clearly incorrect, since the cpp files that #include "mongo/db/vector_clock.h" need to be rebuilt, and everything that depends on them relinked and reinstalled. Looking at the targets built in each case (for the first patch) confirms this hypothesis — ninja next is correctly rebuilding the changed cpp files, but not the cpp files (and associated libs) that include the changed header file, eg. rpc/metadata.cpp and the rpc/metadata lib. Since the in-memory layout of the class has changed, the not-rebuilt object files are using the (now incorrect) original layout, which leads to incorrect memory usages, and so explains the segfaults and/or other weird problems. cc acm |
| Comments |
| Comment by Githook User [ 26/May/20 ] |
|
Author: {'name': 'Andrew Morrow', 'email': 'acm@mongodb.com', 'username': 'acmorrow'}Message: (cherry picked from commit 18cbf0d581162b2d15d66577b1fe08fe22006699) |
| Comment by Githook User [ 26/May/20 ] |
|
Author: {'name': 'Andrew Morrow', 'email': 'acm@mongodb.com', 'username': 'acmorrow'}Message: |
| Comment by Githook User [ 26/May/20 ] |
|
Author: {'name': 'Andrew Morrow', 'email': 'acm@mongodb.com', 'username': 'acmorrow'}Message: |
| Comment by Andrew Morrow (Inactive) [ 21/May/20 ] |
|
I can reliably reproduce this only with CCFLAGS=-gsplit-dwarf, and I have identified a fix that I should have out for code review shortly. |
| Comment by Andrew Morrow (Inactive) [ 21/May/20 ] |
|
kevin.pulo - Does this still reproduce if you remove -gsplit-dwarf from your CCFLAGS? |