Re: [Pyobjc-dev] Python 3 + pyobjc_unicode + strptime = crash

[Ronald O. <ron...@ma...>]

On 8 Sep, 2010, at 14:39, Virgil Dupras wrote:

> On Wed, Sep 8, 2010 at 2:19 PM, Ronald Oussoren <ron...@ma...> wrote:
>> 
>> On 8 Sep, 2010, at 11:38, Virgil Dupras wrote:
>> 
>>> Hi,
>>> 
>>> (Sorry for not submitting it to the tracker, I don't remember my old
>>> SF login, I dislike SF and I want to avoid dealing with it.)
>> 
>>> 
>>> I uncovered a bug today. Under Python 3, when using a pyobjc_unicode
>>> with strptime, I get a this crash:
>>> 
>>> Traceback (most recent call last):
>>>  File "pyobjc_strptime_bug.py", line 6, in <module>
>>>    print(datetime.strptime(s, '%Y-%m-%d'))
>>>  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/_strptime.py",
>>> line 335, in _strptime
>>>    data_string[found.end():])
>>> ValueError: unconverted data remains: o
>>> 
>>> I created a script that reproduces the bug:
>>> 
>>> from Foundation import NSString
>>> s = NSString.alloc().initWithString_('2010-09-08')
>>> print(type(s))
>>> # Very interesting, the bug only shows up if datetime is imported here
>>> instead of at the top
>>> from datetime import datetime
>>> print(datetime.strptime(s, '%Y-%m-%d'))
>> 
>> This works for me, with python 3.1 and 3.2. Both of them 32-bit builds.   IIRC both python versions don't run the tip of the tree, but that shouldn't matter.
>> 
>> What version of Python and PyObjC do you use? Which architecture are you using (32-bit, intel, 3-way, ...)?
>> 
>> The most likely reason for the odd behaviour is that the constructor for pyobjc_unicode fails to initalize one of the fields in the unicode structs, or at least not exactly the same as the initializer for the real unicode type.
>> 
>> Ronald.
>> 
> 
> I use PyObjC's trunk at r2558 and Python 3.1.2, build in 32bit and
> 64bit intel arches (when I run it, it runs in 64bit). I fiddled around
> to figure out how to run python under 32bit mode, to no avail. The
> "arch" command doesn't seem to work for me...

You have to use "arch /Library/Framework/Python.framework/Versions/3.1/Resources/Python.app/Contents/MacOS/Python" (I'm typing the path from memory and may therefore by mistaken about the exact path, but the idea should be clear).

In 3.2 (and 2.7) the arch command does work (on Leopard or later, Tiger doesn't expose the functionality we need)

Arch doesn't work the python command on your shell's search path because that does nothing but execv the real interpreter (the one I buried deep inside the framework). That is needed to trick Apple's framework into believing that the interpreter is a real application and can have access to the window server.   

The wrapper executable in 3.2 and 2.7 uses posix_spawn instead of execv, which gives more control over how the real executable is started and that makes it possible to ensure that the real executable is started using the same architecture as was used to execute the wrapper. 

Ronald