[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
