Unambiguous ownership of generic param objects #2237
Conversation
There was a problem hiding this comment.
This was removed under Zoltan's supervision but I'm actually sort of confused-- why did this need to be removed? Is this okay to remove? With all the other changes the assert now fails if it is left in.
b048841 to
4ad753e
Compare
|
Avoid merge commits in PR as much as possible, most git tools suck at presenting those merges in any usable way, making offline reviews a lot harder as it's no longer the case that the PR is made out of the top X commits. |
mono/metadata/image.c
Outdated
There was a problem hiding this comment.
Images don't need to be disk-loaded, there are other ways to load them besides disk files that will in turn produce non-dynamic images. mkbundle'd assemblies and Assembly.Load (byte[]) are two examples of that.
|
The first commit, 2bcb4f001309feed42447f04b340df8018f15999, needs some minor edits, but LGTM otherwise. |
mono/metadata/class-internals.h
Outdated
There was a problem hiding this comment.
"except during container creation" Why? For how long? How will code witness this transitory state?
Please expand this comment on what's the issue around container creation.
Doing it while the knowledge is fresh will save us from a lot of trouble down the line.
mono/metadata/metadata.c
Outdated
There was a problem hiding this comment.
Use g_error with a message.
- New audit-point macro for atomic writes - Check imageset list directly (instead of indirectly through image list) - Check dynamic images and have special rules for them (for the time being we will allow dynamic images to point to non-dynamic ones without auditing, long-term this is a FIXME) - Print image names out with more detail (image sets get full names) - Remove some #if CHECKED_BUILDs - New g_assert_checked asserts for checked builds only
This patch fixes rule violations found by the first batch of mempool-reference audit points. The fix is to remove ambiguities in what image owns or should own any particular generic parameter object. Previously, there were four options for specifying a MonoGenericParam’s image: 1. klass/method union in MonoGenericContainer. 2. image field in MonoGenericContainer. 3. image field in MonoGenericParam. 4. No field; “image” passed in to methods in at time of usage. This patch removes 3 and 4; it preserves the image field from (2), but merges it into the union from (1). It adds a new field, “is_anonymous”, to indicate when the image member of the union should be used. The single source of the “owner" union now always points to the generic param’s image, directly or indirectly. A further change is made to support this: Previously, containers were optional, and the presence or absence of container was incidentally used to determine whether an object was a MonoGenericParam or a MonoGenericParamFull. Now, containers are mandatory for all MonoGenericParams, so a new “is_small_size” bit in the container tracks this information. This change opens some sources of risk: ⁃ Code which creates MonoGenericParams now must make sure to allocate a container early. ⁃ Code that accesses the MonoGenericContainer::owner field must all be correctly updated to look for is_anonymous or there will be a crash. (Much of this code would have previously used a NULL container as the flag for “anonymous”). ⁃ Code that casts MonoGenericParams to MonoGenericParamFull must use the is_small_size field. ⁃ Some generic containers will now exist with NULL type_params and 0 type_argc. Code which reads the type param array must either not receive objects from these containers, or must handle it. ⁃ If code by users of the embedding API exists which somehow depends on particular behavior related to the now-unused image argument of mono_class_from_generic_parameter, it will break. I have audited code around, at least, the first three of these cases and fixed what problems I found.
Comments, variable initialization, formatting. No functional changes.
4ad753e to
ee43692
Compare
|
Rebased, made changes for all comments above (unless I specifically commented to say otherwise), split out the changes into four clearly delineated commits instead of two. |
|
Converted those macros to static inlines as Zoltan suggested |
|
builddeb |
|
|
|
|
Unambiguous ownership of generic param objects
|
Uggg, I had to manually revert this PR as it broke corlib compilation is some weird way I could not easily debug. Sorry. :( |
Unambiguous ownership of generic param objects
This patch adds a small number of mempool-reference audit points to functions in class.c and then performs a large refactor without which those audit points would fail on the standard tests. The goal of the refactor is to remove ambiguities in what image owns or should own any particular generic parameter object. Previously, there were four options for specifying a MonoGenericParam’s image:
1. klass/method union in MonoGenericContainer.
2. image field in MonoGenericContainer.
3. image field in MonoGenericParam.
4. No field; “image” passed in to methods in at time of usage.
This patch removes 3 and 4; it preserves the image field from (2), but merges it into the union from (1). It adds a new field, “is_anonymous”, to indicate when the image member of the union should be used. The single source of the “owner" union now always points to the generic param’s image, directly or indirectly.
A further change is made to support this: Previously, containers were optional, and the presence or absence of container was incidentally used to determine whether an object was a MonoGenericParam or a MonoGenericParamFull. Now, containers are mandatory for all MonoGenericParams, so a new “is_small_size” bit in the container tracks this information.
Some changes were made to checked builds to support all this: there's a g_assert_checked now which asserts but only on checked builds, and a bunch of little changes to the mempool audit feature (see commit #1)
This change opens some sources of risk:
⁃ Code which creates MonoGenericParams now must make sure to allocate a container early.
⁃ Code that accesses the MonoGenericContainer::owner field must all be correctly updated to look for is_anonymous or there will be a crash. (Much of this code would have previously used a NULL container as the flag for “anonymous”).
⁃ Code that casts MonoGenericParams to MonoGenericParamFull must use the is_small_size field.
⁃ Some generic containers will now exist with NULL type_params and 0 type_argc. Code which reads the type param array must either not receive objects from these containers, or must handle it.
⁃ If code by users of the embedding API exists which somehow depends on particular behavior related to the now-unused image argument of mono_class_from_generic_parameter, it will break.
I have audited code around, at least, the first three of these cases and fixed what problems I found.
Monodis is probably completely broken now.