Are you using some virtual env thing that might move modules around,
btw? I tried messing with the path to see if I could trick Python
into importing the same thing twice on Windows, but failed under 2.6.
</F>
On Thu, Apr 8, 2010 at 9:06 PM, Fredrik Lundh <fred...@pythonware.com> wrote:
> The error should only occur if the C module's initialization function
> is called twice. That shouldn't happen under normal use of Python
> (and if it happens anyway, it invariably results in resource leaks for
> many modules, and potentially also more serious issues -- the C module
> interface doesn't have a "uninit" mechanism). Changing the init to
> ignore double initializations only addresses the symptoms.
>
> (the reason this is a hard error is that collision under normal
> circumstances means that the library is unusable unless rebuilt with
> proper hash settings).
>
> Googling led me to someone mentioning that this happened after he'd
> used easy_install, but that it went away after rebuilding with
> setup.py. How did you build your copy?
>
> </F>
>
> On Thu, Apr 8, 2010 at 8:17 PM, Bill Janssen <jans...@parc.com> wrote:
>> Fredrik Lundh <fred...@pythonware.com> wrote:
>>
>>> The idea is that add_item should only be called once for each mode
>>> (see ImagingAccessInit). What did you do to trick Python into calling
>>> the module initializer multiple times?
>>
>> I was using epydoc and docutils 0.5 to build my documentation. Epydoc
>> crashed with this error. If you google "AccessInit: hash collision: 3
>> for both 1 and 1", you'll see it's not just me. After I applied my
>> patch, things seem to work fine.
>>
>> Seems to be a problem with Django and Sphinx and Satchmo, too. And
>> it looks like maybe it only occurs on Windows. I ran into it using
>> PIL built with msys for Python 2.6.4 on Windows XP. I've never seen
>> it on OS X or Ubuntu or Fedora.
>>
>> By the way, "exit(1)" is pretty harsh. Shouldn't you somehow throw a
>> Python exception there? Give us a better chance of figuring out where
>> it's being called from.
>>
>> Bill
>>
>>>
>>> </F>
>>>
>>> On Mon, Apr 5, 2010 at 4:41 AM, Bill Janssen <jans...@parc.com> wrote:
>>> > Seems to me that in libImaging, Access.c:add_item should really read
>>> >
>>> > static ImagingAccess
>>> > add_item(const char* mode)
>>> > {
>>> > UINT32 i = hash(mode);
>>> > /* printf("hash %s => %d\n", mode, i); */
>>> > if (access_table[i].mode && (strcmp(mode, access_table[i].mode) != 0))
>>> > {
>>> > fprintf(stderr, "AccessInit: hash collision: %d for both %s and
>>> > %s\n",
>>> > i, mode, access_table[i].mode);
>>> > exit(1);
>>> > }
>>> > access_table[i].mode = mode;
>>> > return &access_table[i];
>>> > }
>>> >
>>> > Currently, it reads:
>>> >
>>> > static ImagingAccess
>>> > add_item(const char* mode)
>>> > {
>>> > UINT32 i = hash(mode);
>>> > /* printf("hash %s => %d\n", mode, i); */
>>> > if (access_table[i].mode) {
>>> > fprintf(stderr, "AccessInit: hash collision: %d for both %s and
>>> > %s\n",
>>> > i, mode, access_table[i].mode);
>>> > exit(1);
>>> > }
>>> > access_table[i].mode = mode;
>>> > return &access_table[i];
>>> > }
>>> >
>>> > And there's a number of Google hits for "AccessInit: hash collision: 3
>>> > for both 1 and 1", starting about the release of 1.1.7.
>>> >
>>> > Bill
>>> > _______________________________________________
>>> > Image-SIG maillist - image-...@python.org
>>> > http://mail.python.org/mailman/listinfo/image-sig
>>> >
>>
>
_______________________________________________
Image-SIG maillist - Image-SIG@python.org
http://mail.python.org/mailman/listinfo/image-sig
