Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subsequent write operations create different outputs #859

Open
tom-englert opened this issue Jun 16, 2022 · 6 comments
Open

Subsequent write operations create different outputs #859

tom-englert opened this issue Jun 16, 2022 · 6 comments

Comments

@tom-englert
Copy link

Calling ModuleDefinition.Write multiple times generates different outputs.
The first output is binary different from all subsequent outputs.

This is not a blocking issue, since both outputs seem to work fine, but might be a hint to some inconsistency in the write operation.

tom-englert added a commit to tom-englert/cecil that referenced this issue Jun 16, 2022
tom-englert added a commit to Fody/cecil that referenced this issue Jun 16, 2022
@Zastai
Copy link
Contributor

Zastai commented Jun 17, 2022

I suppose I'm surprised it becomes stable after the first. I could understand each Write generating a new MVID (in fact, arguably it should, just like recompiling does even though everything else remains the same).

@ltrzesniewski
Copy link
Contributor

I could understand each Write generating a new MVID (in fact, arguably it should, just like recompiling does even though everything else remains the same).

The MVID can be made deterministic. See #810.

@vitek-karas
Copy link
Contributor

As per @ltrzesniewski comment - you need to ask for deterministic behavior. But if you still get different outputs after that I would be very interested (as it would break lot of things in our usage potentially).

@jbevain
Copy link
Owner

jbevain commented Sep 30, 2022

Interesting. Thanks for the test @tom-englert. Did you have a chance to look at what's happening?

@tom-englert
Copy link
Author

I once tried to dig through the code, but gave up.

I remember for one experiment that there were some blocks shifted in the file, and an empty block with only 00 had appeared after the second save

However in the test that I've added in #860 the difference is more subtle:
image

Looks like it's not the MVID that changes.

@Zastai
Copy link
Contributor

Zastai commented Oct 1, 2022

Given that second file has a high(ish) value at the start makes me wonder if there's a static or instance field somewhere that does not get reset.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants