Problem with gcc5 and above

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with gcc5 and above

Nicolas Cheron
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Problem with gcc5 and above

Noel O'Boyle
Administrator
No known problems. Could you file a bug?

On 22 Apr 2017 1:51 p.m., "Nicolas Cheron" <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Problem with gcc5 and above

Nicolas Cheron
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 <[hidden email]>:
No known problems. Could you file a bug?

On 22 Apr 2017 1:51 p.m., "Nicolas Cheron" <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Problem with gcc5 and above

Dimitri Maziuk
On 4/26/2017 12:49 PM, Nicolas Cheron wrote:

> If there is a way, in future versions, to change the stack
> limit in OpenBabel, I think it could be useful.

Not really, even if there was a way: someone'll just try to load a
larger structure and hit the same thing again.

Dima


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Problem with gcc5 and above

Geoff Hutchison
>> If there is a way, in future versions, to change the stack
>> limit in OpenBabel, I think it could be useful.
>
> Not really, even if there was a way: someone'll just try to load a
> larger structure and hit the same thing again.

Moreover, it's a type of denial of service attack on the underlying machine. Consider if you run OB on a machine with limited resources..

Not sure why this would be limited to gcc5 and above, though.

-Geoff
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Problem with gcc5 and above

Noel O'Boyle
Administrator
In reply to this post by Nicolas Cheron
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
<[hidden email]> 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 <[hidden email]>:
>>
>> No known problems. Could you file a bug?
>>
>> On 22 Apr 2017 1:51 p.m., "Nicolas Cheron"
>> <[hidden email]> 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
>>> [hidden email]
>>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Problem with gcc5 and above

Dimitri Maziuk
On 4/27/2017 10:24 AM, Noel O'Boyle wrote:

> ... 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.

I very much doubt the speed difference for the common case will be
noticeable to the user, or even if it is: unacceptable. At the end of
the day stack and heap both live in physical RAM and there's a finite
amount of that so there's always a hard limit. The practical difference
between "string blah[HUGE_NUM];" and "vector<string> blah;" is that the
first form will crash on startup while the second one will crash sometimes.

Dima


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Problem with gcc5 and above

Nicolas Cheron
In reply to this post by Noel O'Boyle
Yes, it was on the same machine (stack was 8192kb)

2017-04-27 17:24 GMT+02:00 Noel O'Boyle <[hidden email]>:
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
<[hidden email]> 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 <[hidden email]>:
>>
>> No known problems. Could you file a bug?
>>
>> On 22 Apr 2017 1:51 p.m., "Nicolas Cheron"
>> <[hidden email]> 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
>>> [hidden email]
>>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss