[SERVER-63548] Determine why using SCons.Object affects initializers Created: 10/Feb/22  Updated: 14/Jul/23  Resolved: 14/Jul/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Ryan Egesdahl (Inactive) Assignee: [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Server Development Platform
Operating System: ALL
Participants:

 Description   

While investigating SERVER-63400, we discovered that using SCons.Object to create an object file and then using it as a source file in a builder has a different result than letting SCons chain builders on its own. Specifically, the resulting binary worked with SCons.Object but produced this error when using standard chained builders:

Attempt to add global initializer failed, status: CannotMutateObject: Initializer dependency graph is frozen
[1]    14751 abort (core dumped)  build/install/bin/mongo_csfle_shlib_test

We should investigate why this is happening and determine whether it's a problem to be fixed or is simply behavior to be documented.



 Comments   
Comment by Ryan Egesdahl (Inactive) [ 10/Feb/22 ]

daniel.moody I just realized - I don't think you would see this by running the unit tests. The mongo_csfle_test target would be run, but mongo_csfle_shlib_test, the failing program, would not be because it's not classed as a unit test. It's only run in a specific Evergreen task that ensures the shared library can be debugged with GDB. You would need to run that binary to see what is happening here.

Comment by Ryan Egesdahl (Inactive) [ 10/Feb/22 ]

I was testing some changes for SERVER-62972. This is my invocation:

python buildscripts/scons.py VERBOSE=1 --variables-files=etc/scons/developer_versions.vars --variables-files=etc/scons/mongodbtoolchain_v3_clang.vars --dbg=off --opt=on --link-model=dynamic --sanitize=undefined --ssl --ocsp-stapling=off --install-action=hardlink install-all-meta

One other thing is that I was simply removing the related result files and running the above invocation again to regenerate them. I don't see how either of these facts changes anything, but of course the original problem is just as weird, so ... maybe? All I know is that with SCons.Object, the regenerated result files consistently worked for me and with a chained builder they didn't.

Generated at Thu Feb 08 05:58:03 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.