[chemfp] chemfp-1.0 on Windows

[Andrew Dalke]

On Nov 7, 2011, at 2:34 AM, Andrew Dalke wrote:

> I've been trying to reproduce this but haven't yet succeeded.


I think I found it!

I sort the fingerprints by population count, and make indices into the sorted fingerprints. In that way I know that all fingerprints with 'p' bits set are between indices[p] <= i < indices[p+1].

(And I just realized that I've been spelling 'indices' as 'indicies' for years.)

Unfortunately, I assumed that fingerprints with N bits in them need N+1 index fields. It's actually N+2 index fields, since [0] is always 0 and the last one is always the number of fingerprints.

This causes a 4-byte buffer overflow, which apparently doesn't cause a problem on my installation but does on others.


> Someone else privately reported a bug in the simsearch code on Linux, so I know there's an error there somewhere. I just wish I could reproduce it -- or them.


I got that person to send me the output from valgrind. In it was:

==3383==    at 0x49BC801: chemfp_reorder_by_popcount (searches.c:874)
==3383==    by 0x49BDBF9: reorder_by_popcount (python_api.c:703)
==3383==    by 0x4073A8D: PyCFunction_Call (methodobject.c:116)
==3383==    by 0x40D0AEC: PyEval_EvalFrameEx (ceval.c:4012)

which pointed me to the right area.

I now have tests for the different corner cases, and everything is checked into the repository on Google Code.

Only 6 weeks to track down that bug. :)

				Andrew
				dalke at dalkescientific.com