[Open Babel] Segmentation fault while reading multiple mol2 files
Hi, I have a strange problem when compiling and running my code on two different machines (on some molecules download attached molecule). My code looks like this: OBMol OBmol1; OBConversion OBconv(&cin,&cout); OBFormat *inFormat, *outFormat; string ff1 = "MMFF94"; string ff2 = "GAFF"; OBForceField* pFF = OBForceField::FindForceField(ff1); if(!pFF){ cout << "Forcefield is missing " << endl; exit(-1); } // Query ligand OBmol1.Clear(); inFormat = OBconv.FormatFromExt(filename1.c_str()); outFormat= OBconv.FindFormat("mol2"); OBconv.SetInAndOutFormats(inFormat,outFormat); bool notatend = OBconv.ReadFile(&OBmol1,filename1); while (notatend){ //Add hydrogens (required by forcefield)/ (bool) OBmol1.AddPolarHydrogens(); string MolID = OBmol1.GetTitle(); std::vector rings = OBmol1.GetSSSR(); double energy=1; if(!pFF->Setup(OBmol1)){ cout << "Forcefield set up failed " << endl; exit(-1); } else{ energy = pFF->Energy(false); } int Nrings = rings.size(); cout << MolID << " Rot.Bonds: " << OBmol1.NumRotors() << " Heavy.Atoms: " << OBmol1.NumHvyAtoms() << " Rings:" << Nrings << " Energy:" << energy << endl; OBmol1.Clear(); notatend = OBconv.Read(&OBmol1); // This is where segmentation fault occurs } This code runs through (for the attached molecule) without any problem on one of my machines, while it gives segmentation fault error on the second. I need to mention that there was no issue with compilation on the second machine as some other molecules that I tested runs through without any issue. When I checked for memory leak on the attached file. I got this error log ==15859== Invalid read of size 1 ==15859==at 0x77FA6D5: OpenBabel::MOL2Format::ReadMolecule(OpenBabel::OBBase*, OpenBabel::OBConversion*) (mol2format.cpp:372) ==15859==by 0x4F6367A: OpenBabel::OBConversion::Read(OpenBabel::OBBase*, std::istream*) (obconversion.cpp:825) ==15859==by 0x4021FF: main (in LigProp/LigProp) ==15859== Address 0x20 is not stack'd, malloc'd or (recently) free'd ==15859== ==15859== ==15859== Process terminating with default action of signal 11 (SIGSEGV) ==15859== Access not within mapped region at address 0x20 ==15859==at 0x77FA6D5: OpenBabel::MOL2Format::ReadMolecule(OpenBabel::OBBase*, OpenBabel::OBConversion*) (mol2format.cpp:372) ==15859==by 0x4F6367A: OpenBabel::OBConversion::Read(OpenBabel::OBBase*, std::istream*) (obconversion.cpp:825) ==15859== If you believe this happened as a result of a stack ==15859== overflow in your program's main thread (unlikely but ==15859== possible), you can try to increase the size of the ==15859== main thread stack using the --main-stacksize= flag. ==15859== The main thread stack size used in this run was 10485760. ==15859== Invalid free() / delete / delete[] / realloc() ==15859==at 0x4C222BA: free (vg_replace_malloc.c:446) ==15859==by 0x5B0ACDA: free_mem (in /lib64/libc-2.5.so) ==15859==by 0x5B0A8D1: __libc_freeres (in /lib64/libc-2.5.so) ==15859==by 0x4A1D5E9: _vgnU_freeres (vg_preloaded.c:62) ==15859==by 0x7FEFEF16F: ??? ==15859==by 0x7FEFFF4FF: ??? ==15859==by 0x7FEFE716F: ??? ==15859==by 0x7FEFFF41F: ??? ==15859==by 0x7FEFFF41F: ??? ==15859==by 0x7FEFFF3DF: ??? ==15859==by 0x7FEFFF37F: ??? ==15859==by 0x7FEFDF16F: ??? ==15859== Address 0x4027398 is not stack'd, malloc'd or (recently) free'd ==15859== HEAP SUMMARY: ==15859== in use at exit: 1,701,442 bytes in 24,704 blocks ==15859== total heap usage: 99,190 allocs, 74,487 frees, 5,574,740 bytes allocated ==15859== ==15859== LEAK SUMMARY: ==15859==definitely lost: 0 bytes in 0 blocks ==15859==indirectly lost: 0 bytes in 0 blocks Thanks in advance for any suggestion. -- View this message in context: http://forums.openbabel.org/Segmentation-fault-while-reading-multiple-mol2-files-tp4656482.html Sent from the General discussion mailing list archive at Nabble.com. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ OpenBabel-discuss mailing list OpenBabel-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Re: [Open Babel] Segmentation fault while reading multiple mol2 files
It looks like the variable "boundToNitrogen" has not been assigned any value when it was refered to at line 371 of mol2format.cpp. Probably a line similar to line 387 is missing just prior to line 371. Ling > > From: Roy >To: openbabel-discuss@lists.sourceforge.net >Sent: Tuesday, July 9, 2013 9:54 AM >Subject: [Open Babel] Segmentation fault while reading multiple mol2 files > > >Hi, > I have a strange problem when compiling and running my code on two >different machines (on some molecules download attached molecule). My code >looks like this: > > OBMol OBmol1; > OBConversion OBconv(&cin,&cout); > OBFormat *inFormat, *outFormat; > string ff1 = "MMFF94"; > string ff2 = "GAFF"; > OBForceField* pFF = OBForceField::FindForceField(ff1); > if(!pFF){ > cout << "Forcefield is missing " << endl; > exit(-1); > } > > // Query ligand > OBmol1.Clear(); > inFormat = OBconv.FormatFromExt(filename1.c_str()); > outFormat= OBconv.FindFormat("mol2"); > OBconv.SetInAndOutFormats(inFormat,outFormat); > bool notatend = OBconv.ReadFile(&OBmol1,filename1); > > while (notatend){ > //Add hydrogens (required by forcefield)/ > (bool) OBmol1.AddPolarHydrogens(); > string MolID = OBmol1.GetTitle(); > std::vector rings = OBmol1.GetSSSR(); > double energy=1; > if(!pFF->Setup(OBmol1)){ > cout << "Forcefield set up failed " << endl; > exit(-1); > } > else{ > energy = pFF->Energy(false); > } > int Nrings = rings.size(); > cout << MolID << " Rot.Bonds: " << OBmol1.NumRotors() << " Heavy.Atoms: >" << OBmol1.NumHvyAtoms() << " Rings:" << Nrings << " Energy:" << energy << >endl; > OBmol1.Clear(); > notatend = OBconv.Read(&OBmol1); // This is where segmentation fault >occurs > } > > This code runs through (for the attached molecule) without any problem on >one of my machines, while it gives segmentation fault error on the second. I >need to mention that there was no issue with compilation on the second >machine as some other molecules that I tested runs through without any >issue. > > >When I checked for memory leak on the attached file. I got this error log >==15859== Invalid read of size 1 >==15859== at 0x77FA6D5: >OpenBabel::MOL2Format::ReadMolecule(OpenBabel::OBBase*, >OpenBabel::OBConversion*) (mol2format.cpp:372) >==15859== by 0x4F6367A: OpenBabel::OBConversion::Read(OpenBabel::OBBase*, >std::istream*) (obconversion.cpp:825) >==15859== by 0x4021FF: main (in LigProp/LigProp) >==15859== Address 0x20 is not stack'd, malloc'd or (recently) free'd >==15859== >==15859== >==15859== Process terminating with default action of signal 11 (SIGSEGV) >==15859== Access not within mapped region at address 0x20 >==15859== at 0x77FA6D5: >OpenBabel::MOL2Format::ReadMolecule(OpenBabel::OBBase*, >OpenBabel::OBConversion*) (mol2format.cpp:372) >==15859== by 0x4F6367A: OpenBabel::OBConversion::Read(OpenBabel::OBBase*, >std::istream*) (obconversion.cpp:825) >==15859== If you believe this happened as a result of a stack >==15859== overflow in your program's main thread (unlikely but >==15859== possible), you can try to increase the size of the >==15859== main thread stack using the --main-stacksize= flag. >==15859== The main thread stack size used in this run was 10485760. >==15859== Invalid free() / delete / delete[] / realloc() >==15859== at 0x4C222BA: free (vg_replace_malloc.c:446) >==15859== by 0x5B0ACDA: free_mem (in /lib64/libc-2.5.so) >==15859== by 0x5B0A8D1: __libc_freeres (in /lib64/libc-2.5.so) >==15859== by 0x4A1D5E9: _vgnU_freeres (vg_preloaded.c:62) >==15859== by 0x7FEFEF16F: ??? >==15859== by 0x7FEFFF4FF: ??? >==15859== by 0x7FEFE716F: ??? >==15859== by 0x7FEFFF41F: ??? >==15859== by 0x7FEFFF41F: ??? >==15859== by 0x7FEFFF3DF: ??? >==15859== by 0x7FEFFF37F: ??? >==15859== by 0x7FEFDF16F: ??? >==15859== Address 0x4027398 is not stack'd, malloc'd or (recently) free'd >==15859== HEAP SUMMARY: >==15859== in use at exit: 1,701,442 bytes in 24,704 blocks >==15859== total heap usage: 99,190 allocs, 74,487 frees, 5,574,740 bytes >allocated >==15859== >==15859== LEAK SUMMARY: >==15859== definitely lost: 0 bytes in 0 blocks >==15859== indirectly lost: 0 bytes in 0 blocks > >Thanks in advance for any suggestion. > > > >-- >View this message in conte