[Image-SIG] AccessInit: hash collision: 3 for both 1 and 1
Bill Janssen
janssen at parc.com
Mon Apr 12 18:28:58 CEST 2010
Fredrik Lundh <fredrik at pythonware.com> wrote:
> 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.
No, but I am doing something somewhat unusual -- I install all my
extensions, including PIL, in a private directory,
C:\UpLib\1.7.9\python\Lib\site-packages\, and I set PYTHONPATH to that
before running. What I'm running is epydoc:
python C:\UpLib\1.7.9\python\Scripts\epydoc --config-file=...
>
> </F>
>
> On Thu, Apr 8, 2010 at 9:06 PM, 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?
> >
> > </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
> >>> >
> >>
> >
More information about the Image-SIG
mailing list