This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: python.exe problem with cvxopt
Type: behavior Stage: resolved
Components: Versions:
process
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, brian.curtin, jroach, r.david.murray
Priority: normal Keywords:

Created on 2010-05-29 02:17 by jroach, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
python26problem.doc jroach, 2010-05-29 02:17
Messages (6)
msg106701 - (view) Author: (jroach) Date: 2010-05-29 02:17
I have encountered a runtime problem with python26 (same problem not 
encountered with python25). The reported error is in python.exe.
I have written a brief .doc file describing the problem which I will 
attach. ( The problem was first encountered with an older version of 
python26, it also occurs with the latest  version  2.6.5). The Python 
cvxopt package is available on the internet.
This is my first communication of this type. I hope that it is appropriate.
jroach
msg106718 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2010-05-29 13:48
Rather than attaching a Word document, can you just enter your information here?
msg106747 - (view) Author: (jroach) Date: 2010-05-30 06:07
Brian,
I am an engineer who makes significant use of Python, not a computer 
professional. I hope that I communicate the right information. The 
operating system is Windows XP Professional. The problem encountered was 
that a python program invoking cvxopt, that ran perfectly well with 
Python25, crashed with Python26 and (without request) generated a 
response from Visual Studio to the effect that python.exe encountered an 
access violation writing location 0x9b0b80c8. (The full message was 
'Unhandled exception  at 0x01de5607 in python.exe:0xC0000005: Access  
violation writing location 0x9b0b80c8. The c-code segment displayed by 
the debugger was (file: crt0dat.c):
  /*
         * walk the table of function pointers from the bottom up, until
         * the end is encountered.  Do not skip the first entry.  The 
initial
         * value of pfbegin points to the first valid entry.  Do not try to
         * execute what pfend points to.  Only entries before pfend are 
valid.
         */
        while ( pfbegin < pfend )
        {
            /*
             * if current table entry is non-NULL, call thru it.
             */
            if ( *pfbegin != NULL )
                (**pfbegin)();
            ++pfbegin;
        }
}

/***
* static int  _initterm_e(_PIFV * pfbegin, _PIFV * pfend) - call entries in
*       function pointer table, return error code on any failure
*
*Purpose:
*       Walk a table of function pointers in the same way as _initterm, but
*       here the functions return an error code.  If an error is 
returned, it
*       will be a nonzero value equal to one of the _RT_* codes.
*
*Entry:
The call stack line was: >    msvcr90.dll!_initterm(void (void)* * 
pfbegin=0x00000002, void (void)* * pfend=0x00993148)  Line 903    C
I do not have the necessary knowledge to interpret these data.
This Python26 problem occurs with every execution under both Idle and 
Editra.

jroach
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue8849>
> _______________________________________
>
>
msg115880 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-09-08 15:19
cvxopt looks like it includes a C-based extension module.  Have you reported the bug to cvxopt?  They are more likely to be able to spot the problem and determine if it is a bug in Python or their code.
msg222710 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-07-10 22:56
I can't see how we can pursue this as the minimum Python version for cvxopt is now 2.7 and we don't know what version of cvxopt was originally involved.
msg223025 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-07-14 13:15
True.  Since there was no response from the OP to my question, let's close this.  It can be reopened if he's still having a problem, which seems unlikely.
History
Date User Action Args
2022-04-11 14:57:01adminsetgithub: 53095
2014-07-14 13:15:02r.david.murraysetstatus: open -> closed
type: behavior
messages: + msg223025

resolution: third party
stage: resolved
2014-07-10 22:56:23BreamoreBoysetnosy: + BreamoreBoy
messages: + msg222710
2010-09-08 15:19:44r.david.murraysetnosy: + r.david.murray
messages: + msg115880
2010-05-30 06:07:39jroachsetmessages: + msg106747
2010-05-29 13:48:01brian.curtinsetnosy: + brian.curtin
messages: + msg106718
2010-05-29 02:17:51jroachcreate