Visitar URL original
Crash when calling back through method with `ref ValueType` parameter · Issue #965 · pythonnet/pythonnet · GitHub
Skip to content

Crash when calling back through method with ref ValueType parameter #965

Description

@zooba

Hi. In response to this query I had one of my colleagues debug an issue, and he found that PythonNet does not correctly generate code when calling into a function with a "ref ValueType" parameter. In his words:

The problem is here in the PythonNet code:

        for (var i = 0; i < parameters.Length; ++i)
        {
            il.Emit(OpCodes.Ldloc_0);
            il.Emit(OpCodes.Ldc_I4, i);
            il.Emit(OpCodes.Ldarg, i + 1);
            if (parameterTypes[i].IsValueType)
            {
                il.Emit(OpCodes.Box, parameterTypes[i]);
            }
            il.Emit(OpCodes.Stelem, typeof(object));
        }

The code is trying to store all of the incoming arguments in an array of type Object[]. The cases are:

  1. If the incoming argument is of reference type, the reference can simply be stored in the array.
  2. If the incoming argument is of struct type, the argument needs to be boxed into an object, which can then be stored in the array.
  3. If the incoming argument is a “byref” (i.e., “ref” keyword in C#), more complicated handling is needed, including:
    o On the way in, the byref needs to read (via ldobj if the underlying type is a struct, or ldind.ref otherwise) to load the actual argument data that needs to flow through.
    o On the way out, the byref needs to written (via stobj or stind.ref) to make sure any updates applied by the callee are reflected back to the caller.

The code above handles #1 and #2, but doesn’t handle #3.


Hopefully that's enough for someone to create or contribute a fix.

Activity

  1. filmor commented on Oct 4, 2019

    @filmor
    Member

    Thank you very much for the detailed analysis :)

    A hard crash is of course not acceptable, so we'll need to fix this soon. I'll see if I understand enough of this to do something about the issue.

  2. added this to the 2.5.0 milestone on Oct 4, 2019
  3. freakboy3742 commented on Oct 10, 2019

    @freakboy3742

    @filmor I don't know the status of fiscal sponsorship for Python.net, but if this is a problem where a fix can be expedited by throwing money at the problem, I may be in a position to supply that money.

  4. filmor commented on Oct 10, 2019

    @filmor
    Member

    The status of fiscal sponsorship for Python.NET is that there is none. The main issue with throwing money at the problem is finding someone to throw money at. It's not like we have a wealth of programmers with a lot of free time eager to work on problems that are not necessarily their own here.

  5. lostmsu commented on Mar 10, 2020

    @lostmsu
    Member

    @freakboy3742 I am sure if you list a bounty here somebody may pick it up.

  6. freakboy3742 commented on Mar 10, 2020

    @freakboy3742

    I have no idea what amount of money would get this job done; if you're interested in doing this as work-for-hire, get in touch.

  7. removed this from the 2.5.0 milestone on Apr 23, 2020
  8. lostmsu commented on Feb 21, 2021

    @lostmsu
    Member

    This should have been fixed by #1364

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions