[Image-SIG] AccessInit: hash collision: 3 for both 1 and 1

[Bill Janssen]

Fredrik Lundh <fredrik at 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 <janssen at parc.com> wrote:
> > Fredrik Lundh <fredrik at 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 <janssen at 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-SIG at python.org
> >> > http://mail.python.org/mailman/listinfo/image-sig
> >> >
> >