Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

rmadsen-ks
Copy link
Owner

What does this implement/fix? Explain your changes.

...

Does this close any currently open issues?

...

Any other comments?

...

Checklist

Check all those that are applicable and complete.

  • Make sure to include one or more tests for your change
  • If an enhancement PR, please create docs and at best an example
  • Ensure you have signed the .NET Foundation CLA
  • Add yourself to AUTHORS
  • Updated the CHANGELOG

gertdreyer and others added 30 commits February 26, 2024 12:20
* Use non-BOM encodings

The documentation of the used `PyUnicode_DecodeUTF16` states that not passing `*byteorder` or passing a 0 results in the first two bytes, if
they are the BOM (U+FEFF, zero-width no-break space), to be interpreted and skipped, which is incorrect when we convert a known "non BOM" string, which all strings from C# are.
* Expose an API for users to specify their own formatter

Adds post-serialization and pre-deserialization hooks for additional
customization.

* Add API for capsuling data when serializing

* Add NoopFormatter and fall back to it if BinaryFormatter is not available

---------

Co-authored-by: Benedikt Reinartz <[email protected]>
When nulling the GC handles on shutdown the reference count of all objects pointed to by the IntPtr in the `CLRObject.reflectedObjects` are zero.
This caused an exception in some scenarios because `Runtime.PyObject_TYPE(reflectedClrObject)` is called while the reference counter is at zero.

After `TypeManager.RemoveTypes();` is called in the `Runtime.Shutdown()` method, reference count decrements to zero do not invoke `ClassBase.tp_clear` for managed objects anymore which normally is responsible for removing references from `CLRObject.reflectedObjects`. Collecting objects referenced in `CLRObject.reflectedObjects` only after leads to an unstable state in which the reference count for these object addresses is zero while still maintaining them to be used for further pseudo-cleanup. In that time, the memory could have been reclaimed already which leads to the exception.
Otherwise, collecting all at this earlier point results in corrupt memory for derived types.
* Use non-BOM encodings

* Copy potential BOM to the output of PyString_FromString

The documentation of the used `PyUnicode_DecodeUTF16` states that not
passing `*byteorder` or passing a 0 results in the first two bytes, if
they are the BOM (U+FEFF, zero-width no-break space), to be interpreted
and skipped, which is incorrect when we convert a known "non BOM"
string, which all strings from C# are.

* Default to UTF8 for StrPtr
…or some other internal errors (pythonnet#2409)

* not all events have Add method

fixes pythonnet#2405

* give users some idea of why we might be unable to reflect .NET types to Python for them

* mentioned event Add method crash fix in changelog
Otherwise if you have a Python object that needs to temporarily create a .NET object in its destructor (for instance write log summary to a file), its destructor will fail if it happens to be freed on the second iteration of loop breaking.
…on-gc

Fix access violation exception on shutdown
Was only used in the console and might not be available in some
embedding scenarios.
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

Successfully merging this pull request may close these issues.

6 participants