Nice digging down. I presume that this was on the same machine?
It could be something to do with changes in string handling (in the
compiler), particularly if you are a fan of flags for recent
standards.
We should definitely try to streamline our handling of large molecules
though, and we should be aware of what the largest SMILES string/PDB
file/etc we can currently handle and try to push back on those sizes.
Roger talks about "Dalke marks", which is the longest linear alkane a
toolkit can handle (from Andrew Dalke's use of "C"*LARGE_NUMBER to
stress test from Python). There's a limit of course, and we don't want
to trade off too much speed for the common case (e.g. by allocating
everything on the heap), but it's good to keep an eye on it.
On 26 April 2017 at 18:49, Nicolas Cheron
<nicolas.cheron.bou...@gmail.com> wrote:
> After digging a little bit, I found the cause of the problem, and it is not
> (directly) linked to OpenBabel. I have found that a code as simple as:
> #include <iostream>
> using namespace std;
> int main(int nbarg, char * argv[])
> {
> string List[400000];
> return 0;
> }
> can compile with g++5.4 but returns a segmentation fault during execution
> (on Ubuntu 16.04 in VirtualBox). After setting "ulimit -s unlimited", the
> problem disappears. I don't find any problem with g++4.8. It works with an
> array of 40000 and fails with 400000, I didn't look for the exact threshold.
>
> One consequence is that if I want to load a protein.pdb file with more than
> 45000 atoms in an obMol object, it can compile but crashes with segmentation
> fault (and again, this can be solved with "ulimit -s unlimited"). If there
> is a way, in future versions, to change the stack limit in OpenBabel, I
> think it could be useful.
>
> Nicolas
>
>
>
> 2017-04-22 18:17 GMT+02:00 Noel O'Boyle <baoille...@gmail.com>:
>>
>> No known problems. Could you file a bug?
>>
>> On 22 Apr 2017 1:51 p.m., "Nicolas Cheron"
>> <nicolas.cheron.bou...@gmail.com> wrote:
>>>
>>> Dear all,
>>>
>>> I have a code in C++ that uses the OpenBabel library. Everything is
>>> working smoothly with gcc4.8 or 4.9 (used to compile both OpenBabel and my
>>> code). However, when I am using gcc5 and above (I tried 5.4 and 6.3) I found
>>> some problems. For example, one of them seemed to be that I can not load pdb
>>> files larger than 40,000 atoms as an OBMol (segmentation fault). I am using
>>> v2.4.1 of OpenBabel and tried with Ubuntu 16.04 and 17.04 as well as Fedora
>>> 25.
>>>
>>> Is there known problems with gcc5 and above?
>>>
>>> Thank you.
>>>
>>> Nicolas
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> OpenBabel-discuss mailing list
>>> OpenBabel-discuss@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
>>>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenBabel-discuss mailing list
OpenBabel-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
