[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] "import pygame" crashes with svn build



Hi,

Looks like SDL_HasSSE is indeed buggy on SDL 64bit systems.

Seems redhat has a patch for it:
https://bugzilla.redhat.com/show_bug.cgi?id=487720

A patch is here:
http://cvs.fedoraproject.org/viewvc/rpms/SDL/devel/SDL-1.2.13-rh487720.patch?revision=1.1&view=markup

Also there is a patch in SDL 1.3 svn... which is no use to us since
we're still on SDL 1.2.x.  Sam isn't doing another SDL 1.2.x release
for at least another few months.

I've added a bug with link to patch at the SDL bugzilla:
http://bugzilla.libsdl.org/show_bug.cgi?id=760


I think disabling it for now on 64bit systems, with a comment about
this problem is a good idea.  Or perhaps putting an ifdef SDL version
> 1.2.13 would be ok too.


cheers,





On Wed, Jul 1, 2009 at 3:53 AM, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:
>
> Oops, forgot to attach the patch.
>
> Lenard
>
> Lenard Lindstrom wrote:
>>
>> Hi Lorenz,
>>
>> Yes, it is supposed to be summer where I am too, and actually was hot for awhile, but not now. Anyway, to make sure I am clear on this, Rev. 1658 crashes when the transform module is imported, but earlier revisions work. I assume this means pygame.transform.smoothscale also works. So I am guessing it is the call to the SDL function SDL_HasSSE that is causing the problem. The attached patch to transform.c, Rev 2447 (release candidate 2) removes the SDL_HasSSE call for 64bit intels. Would you give it a try? If it works I will commit it to SVN. It is not ideal, but at least smoothscale will still use MMX.
>>
>> Lenard
>>
>> Lorenz Quack wrote:
>>>
>>> Hey Lenard,
>>>
>>> sorry for the long delays but I'm quite busy these days plus the good weather... not many PC hours left.
>>>
>>> Lenard Lindstrom wrote:
>>>>
>>>> Hi Lorenz,
>>>>
>>>> Could you try dropping in SVN rev 1912 of transform.c instead. This predates the Python 3 updates. This is kind of reaching, but it will narrow down the search.
>>>
>>> I tried this out and poked some more at it and it doesn't seem to be py3k related but rather MMX/SSE.
>>> The transform.c rev 1657 works and 1658 breaks.
>>> Also if I comment out "#define SCALE_MMX_SUPPORT" in any version it works.
>>>
>>> I don't get this. I keep thinking that something must be wrong with _my_ system otherwise someone else
>>> must have encountered this as well.
>>> The only thing I could possibly think of is that I installed the sdl-gfx package without the "mmx" USE-flag
>>> (I'm running Gentoo) because it is not available on amd64 architecture.
>>>
>>> By the way. I also tried commenting out all the asm stuff in scale_mmx64.c but it would still crash.
>>> So maybe it is something that is going on in transform.c but related to MMX/SSE
>>>
>>> If you have any other ideas let me know.
>>>
>>> yours
>>> //Lorenz
>>>
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Lenard
>>>>
>>>> Lorenz Quack wrote:
>>>>>
>>>>> Hi again,
>>>>>
>>>>>>
>>>>>> you figured this out yet?
>>>>>>
>>>>>
>>>>> not 100% but at least now I get it to compile by following your advice:
>>>>>>
>>>>>> Easiest way to work around it...
>>>>>>  Comment out import transform lines in the file:
>>>>>>      site-packages/pygame/__init__.py
>>>>>>
>>>>> [...]
>>>>>>
>>>>>> Perhaps try commenting out the sse/mmx parts?
>>>>>>
>>>>>
>>>>> that seems to be the problem. If I comment out
>>>>>
>>>>> #       include "scale_mmx64.c"
>>>>>
>>>>> in "scale_mmx.c" it compiles. if I import pygame the interpreter naturally
>>>>> complains about undefined symbols but as long as I don't use the transform
>>>>> module it seems to work this way as well. of course this is not a solution.
>>>>>
>>>>> For debugging purposes I tried to remove all SSE/MMX code and simply implement
>>>>> empty dummy functions like this:
>>>>>
>>>>> void filter_shrink_X_MMX(Uint8 *srcpix, Uint8 *dstpix, int height, int srcpitch,
>>>>>                         int dstpitch, int srcwidth, int dstwidth) {}
>>>>>
>>>>> that also crashed. I find this very confusing and frustrating. So I settle with
>>>>> the work around for now.
>>>>>
>>>>>
>>>>> thanks again for the help and if I can help with some debug information or if you
>>>>> have any ideas let me know.
>>>>>
>>>>> yours
>>>>> //Lorenz
>>>>
>>>
>>
>