← 输入框|github.com|刷新
Skip to content

callback function on win64 results in bad behavior. mem corruption? #52522

Closed

Description

@ocrush
mannequin
BPO 8275
Nosy @theller, @birkenfeld, @pitrou
Files
  • ctype_win64.txt: Contains Python and C code. comment the print statement in jfunc to fix the issue.
  • issue8275_win64_ctypes_no_optimization.patch
  • ctypes_win64.diff: one-liner fix
  • ctypes_win64_tests.diff: patch with tests
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2011-01-31.21:48:33.283>
    created_at = <Date 2010-03-31.18:53:44.080>
    labels = ['ctypes', 'type-crash']
    title = 'callback function on win64 results in bad behavior. mem corruption?'
    updated_at = <Date 2011-01-31.21:48:33.282>
    user = 'https://bugs.python.org/ocrush'

    bugs.python.org fields:

    activity = <Date 2011-01-31.21:48:33.282>
    actor = 'pitrou'
    assignee = 'none'
    closed = True
    closed_date = <Date 2011-01-31.21:48:33.283>
    closer = 'pitrou'
    components = ['ctypes']
    creation = <Date 2010-03-31.18:53:44.080>
    creator = 'ocrush'
    dependencies = []
    files = ['16708', '20134', '20527', '20626']
    hgrepos = []
    issue_num = 8275
    keywords = ['patch']
    message_count = 11.0
    messages = ['102028', '102544', '124474', '126713', '127092', '127121', '127127', '127605', '127610', '127657', '127668']
    nosy_count = 7.0
    nosy_names = ['theller', 'georg.brandl', 'pitrou', 'srid', 'cgohlke', 'ocrush', 'stan.mihai']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'crash'
    url = 'https://bugs.python.org/issue8275'
    versions = ['Python 3.1', 'Python 2.7', 'Python 3.2']

    Activity

    1. ocrush commented on Mar 31, 2010

      ocrushmannequin
      MannequinAuthor

      I am testing a wrapper on Windows 64 and it seems to result in an null pointer access error ONLY when I insert a print statement in the C code. I have tested the wrapper with Python 2.6 and Python 2.7a4. In addition, I have compiled Python 2.6.5 source code and ONLY the release version results in an error. I think the issue is with memcpy(obj->b_ptr, *pArgs, dict->size) (callbacks.c). pArgs seem to be corrupted. However, I am only looking at the code for the first time and I might be off base.

      The following is Python and C code to reproduce the bug. To resolve, please comment printf statement in jfunc (C function).

      Python Code:
      from ctypes import *
      def fcn(m,n,x,f):
      print "IN Python function fcn ................"
      print f[0]

      m=3
      n=1
      pydlltest=cdll.pydlltest
      pydlltest.jfunc.restype = POINTER(c_double)
      evalstring = 'pydlltest.jfunc('
      TMP_FCN=CFUNCTYPE(None,c_int,c_int,POINTER(c_double),POINTER(c_double))
      tmp_fcn=TMP_FCN(fcn)
      state=[TMP_FCN,tmp_fcn]
      evalstring += 'tmp_fcn'
      evalstring +=','
      evalstring +='c_int(m)'
      evalstring +=','
      evalstring +='c_int(n)'
      evalstring += ')'
      print "evalstring=",evalstring
      result = eval(evalstring)

      C code:
      #include <stdio.h>
      __declspec(dllexport) double *jfunc(void (*fcn) (int,int,double [],double[]),int m,int n);
      
      double *jfunc(void (*fcn) (int,int,double [],double []),int m,int n)
      {
      	double *fvec=NULL;
      	double *xguess = NULL;
      	int i = 0;
      	int j = 0;
      	/* comment the line below to fix the resulting null pointer access error */
      	printf("In j func .................\n");
      	fvec = (double *) malloc (m * sizeof (double));
      	xguess = (double *) malloc (n * sizeof (double));
      	for (i = 0; i < n; i++){
      	   xguess[i] = 0.123;
      	}
      	(*fcn) (m, n, xguess, fvec);
      	return fvec;
      }
    2. added
      type-bugAn unexpected behavior, bug, or error
      on Mar 31, 2010
    3. changed the title [-]callback function on win64 results in bad behavior. mem leak?[/-] [+]callback function on win64 results in bad behavior. mem corruption?[/+] on Mar 31, 2010
    4. ocrush commented on Apr 7, 2010

      ocrushmannequin
      MannequinAuthor

      I was able to fix the issue by modifying and re-compiling ctypes project in Visual Studio 2008. The following properties were modified:

      Release:
      configuration Properties->C/C++->Optimization->Optimization: Disabled(/Od)
      configuration Properties->C/C++->Optimization->Enable Intrinsic Functions: No

    5. srid commented on Dec 22, 2010

      sridmannequin
      Mannequin

      Attaching a patch for the configuration changes mentioned in msg102544

    6. cgohlke commented on Jan 21, 2011

      cgohlkemannequin
      Mannequin

      This patch fixes issue bpo-9884 and possibly bpo-9266.

    7. stanmihai commented on Jan 26, 2011

      stanmihaimannequin
      Mannequin

      Disabling optimizations doesn't really fix the issue, just hides it, for now.

      The problem was an uninitialized variable. Attached is the patch that fixes it.

    8. pitrou commented on Jan 26, 2011

      @pitrou
      Member

      Would it be possible to add a test case to the patch?

    9. added
      type-crashA hard crash of the interpreter, possibly with a core dump
      and removed
      type-bugAn unexpected behavior, bug, or error
      on Jan 26, 2011
    10. cgohlke commented on Jan 26, 2011

      cgohlkemannequin
      Mannequin

      Thank you. The new patch works and it also fixes a crash of the python-2.5.4.amd64 interpreter at startup when ctypes 1.0.2 and pyreadline 1.6.2 are installed.

    11. stanmihai commented on Jan 31, 2011

      stanmihaimannequin
      Mannequin

      attached patch with tests

      I have no experience with python development so the tests will actually need a more detailed review. Also I only checked it on win64.

    12. pitrou commented on Jan 31, 2011

      @pitrou
      Member

      Patch verified to work under Linux and win32. It looks good, except for tab characters in the Modules/_ctypes/_ctypes_test.c (indentation of C files should use 4 spaces); that's a detail that we can fix ourselves.

    13. stanmihai commented on Jan 31, 2011

      stanmihaimannequin
      Mannequin

      ok, please also fix the first parameter of the tests. Because it has the same value in the first call and the callback it will always be right by accident, since the first call puts the value in both standard and floating point registers.

    14. pitrou commented on Jan 31, 2011

      @pitrou
      Member

      Ok, committed in r88284 (3.2), r88285 (3.1) and r88286 (2.7). Thank you!

    15. transferred this issue fromon Apr 10, 2022
    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

      topic-ctypestype-crashA hard crash of the interpreter, possibly with a core dump

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions