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?
Setup.py:
python setup.py build --compiler=mingw32 install
--prefix="C:\\UpLib\\1.7.9\\python"
I do have setuptools installed in that prefix, though -- need it for
some other modules. But as long as PIL's setup.py doesn't load it, it
shouldn't be an issue. I think. Not sure, perhaps installing
setuptools pollutes distutils right off the bat.
From the Google hits, it looks to me as if this is something docutils is
doing, perhaps only on Windows, but I don't know what. That's why I
suggested changing (if possible) the exit(1) to some way of triggering a
Python exception or error, so that we can get a stack trace.
Bill
>
> </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
