[SERVER-24001] Add a RocksDB+ASan build variant to Evergreen Created: 01/May/16 Updated: 26/Sep/18 Resolved: 26/Sep/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Minor - P4 |
| Reporter: | Max Hirschhorn | Assignee: | DO NOT USE - Backlog - Test Infrastructure Group (TIG) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | tig-evgconfig | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Description |
|
Was suggested by acm in
Patch to apply to mongodb-partners/mongo-rocksThe ASSERT*() macros require that the arguments are ostream-able. It isn't clear why this only fails when compiling with clang and not gcc.
|
| Comments |
| Comment by Max Hirschhorn [ 26/Sep/18 ] |
|
We've removed the RocksDB build variant in |
| Comment by Max Hirschhorn [ 02/Dec/16 ] |
My impression is that there'd still be value in having a RocksDB+ASan build variant running in Evergreen given that it tends to be more aggressive about freeing memory returned from the storage engine after subsequent calls to the cursor. This leads to issues such as
If we aren't actually interested in periodically running this build variant in Evergreen, then I think we should strongly consider adding a wrapper for SortedDataInterface::Cursor and RecordCursor that conditionally frees the memory previously returned on subsequent function calls, as was effectively done to the WiredTiger integration layer via the patch from this comment. We could then enable that mode when running our concurrency tests (and possibly others). This would help to ensure that the query subsystem is using the storage engine in a way that doesn't violate the API contract. |
| Comment by Alexander Gorrod [ 29/Nov/16 ] |
|
We have been able to create ASAN patch builds with the RocksDB storage engine in Evergreen. There is no goal of adding a regular ASAN RocksDB builder since ASAN capable machine resources are very limited. The diff file used to generate an ASAN build is attached to this ticket. |
| Comment by Igor Canadi [ 02/May/16 ] |
|
Hi Max, thanks for trying this out. Looks like the cause of compile errors could be the difference in rocks and mongo's libc++. Can you please try two things: Also, can you please add V=1 to the 'compile_flags_rocksdb' (v as in 'verbose')? That will cause our compile process to output exact compiler invocation command. |