Core dump when calling MolFromInchi

[mnowotka]

Hi,

I'm using RDkit version 2016.09.2:

import rdkit
rdkit.__version__
'2016.09.2'

Compiled with InChI support. Now for this InChI string:

InChI=1S/C5H12N14O7/c6-1(16-18(23)24)8-10-3(20)12-14-5(22)15-13-4(21)11-9-2(7)17-19(25)26/h(H12-2,6,7,8,9,10,11,12,13,14,15,16,17,20,21,22,23,24,25,26)/p+2

RDKit crashes (Seg fault):

from rdkit import Chem
mol = Chem.MolFromInchi("InChI=1S/C5H12N14O7/c6-1(16-18(23)24)8-10-3(20)12-14-5(22)15-13-4(21)11-9-2(7)17-19(25)26/h(H12-2,6,7,8,9,10,11,12,13,14,15,16,17,20,21,22,23,24,25,26)/p+2")

Segmentation fault (core dumped)

The same thing happens using the indigo toolkit:

import indigo
import indigo_inchi
indigoObj = indigo.Indigo()
indigo_inchiObj = indigo_inchi.IndigoInchi(indigoObj)
mol = indigo_inchiObj.loadMolecule(‘InChI=1S/C5H12N14O7/c6-1(16-18(23)24)8-10-3(20)12-14-5(22)15-13-4(21)11-9-2(7)17-19(25)26/h(H12-2,6,7,8,9,10,11,12,13,14,15,16,17,20,21,22,23,24,25,26)/p+2')

Segmentation fault (core dumped)

So I suspect, that the crash may be inside InChI library. But is there any way to protect from this? With the Seg fault there is no possibility to catch anything and properly handle this error.

[mnowotka]

On the other hand it's possible to convert this Inchi to InchiKey and google it. The only result gives this:
http://jglobal.jst.go.jp/public/20090422/201407086094865150

[greglandrum]

I agree that the fact that Indigo also seg faults indicates that the problem is likely in the InChI library itself.

Given that the problem is likely in the InChI library, I don't think there's anything that the RDKit can really do about it. But I'll look into it.

If you haven't already: it would be worth reporting the crash to the InChI folks.

[mnowotka]

I did via twitter as they don't have any other channel. I'm not a chemistry expert but would it be possible to predict this problem before feeding this to inchi lib?

[greglandrum]

Ok, I found the crash and have a simple fix that requires a patch to the inchi code. Now it just fails instead of failing and generating a seg fault. I'll get that committed (though it will likely only work when InChI is downloaded by the RDKit build. I still need to figure that out).

I'll also see if I can figure out who to send the patch to.

[mnowotka]

Great, I always try to use the download-inchi.sh script where I can (I can't use it everywhere because it uses wget, it would be sooo much better if it tried wget OR curl instead), so this will work for me.

Out of curiosity, can you paste a link to the commit?

[greglandrum]

It will be linked here automatically after I make it

[mnowotka]

Perfect, thanks!

[kiddr]

Hi - thanks for the twitter notification. If you could send the issue/patch to the inchi-discuss list on sourceforge that's probably best, or mail me at richard at inchi-trust org

[kiddr]

We think this is fixed in 1.05, publicly released shortly (final review on inchi-discuss to 10 Jan 2017 if you want to take a look)

[mnowotka]

Nice, thanks. Would it be possible to get a patch I could apply to earlier versions to prevent the crash?

[greglandrum]

@kiddr : it looks like a fairly large number of changes have been made to the InChI distribution. Certainly the new zips are laid out differently than the old ones and no longer build with the RDKit.
This makes testing "challenging".
I'll subscribe to the mailing list to discuss this

[mnowotka]

@greglandrum , you said you have a simple fix for rdkit. Can you share it?

[greglandrum]

Yeah, sorry I haven't done that yet. I was trying to get it "right" and then I got distracted by the holidays.
Here's the change I made to runinchi.c:

~/rdk/RDKit_git/External/INCHI-API/src.o % diff -w runichi.c runichi.c.orig 
1754c1754
<             if ( prb_file && prb_file->f && 0L <= sd->fPtrStart && sd->fPtrStart < sd->fPtrEnd && !ip->bSaveAllGoodStructsAsProblem ) {
---
>             if ( prb_file->f && 0L <= sd->fPtrStart && sd->fPtrStart < sd->fPtrEnd && !ip->bSaveAllGoodStructsAsProblem ) {
1759c1759
<             if ( sd->nErrorCode && prb_file && prb_file->f && 0L <= sd->fPtrStart && sd->fPtrStart < sd->fPtrEnd && !ip->bSaveAllGoodStructsAsProblem ) {
---
>             if ( sd->nErrorCode && prb_file->f && 0L <= sd->fPtrStart && sd->fPtrStart < sd->fPtrEnd && !ip->bSaveAllGoodStructsAsProblem ) {
4006a4007,4008
> 
> 

[mnowotka]

Great, thanks!

[greglandrum]

Please let me know if that works for you.

[mnowotka]

Will do.