This is the mail archive of the
mailing list for the Cygwin project.
Re: cppcheck 1.77 Segmentation fault (64-bit)
- From: David Stacey <drstacey at tiscali dot co dot uk>
- To: cygwin at cygwin dot com
- Date: Sat, 4 Feb 2017 15:57:43 +0000
- Subject: Re: cppcheck 1.77 Segmentation fault (64-bit)
- Authentication-results: sourceware.org; auth=none
- References: <CAK-n8j57fMX0fbwExi+4RmrKpX0W+0ujQaq=OWchwhTq2wBQxw@mail.gmail.com> <firstname.lastname@example.org> <CAK-n8j4fu0QQ8-=1NYkGikWV5EMWBdkED7u9f50+w-tRLSabyw@mail.gmail.com> <email@example.com>
On 04/02/17 00:08, David Stacey wrote:
On 29/01/17 21:04, Jim Reisert AD1C wrote:
Best as I can tell, the seg fault is due to having installed the test
version of gcc 6.0. Even uninstalling gcc 6.0 does not fix the
problem. I had to create an entirely new Cygwin-64 environment to get
past the problem.
I invite you (Dave) to try the experiment yourself. You would be wise
to back up your Cygwin environment before doing this.
I've spent a little time looking into this. As per the stack track you
supplied, cppcheck is falling over constructing a std::istringstream
with a string passed in to initialise the stream. I'll need to debug
this into the STL to work out exactly why the seg fault is occurring.
I'm stuck here, I'm afraid. From what I can deduce, cppcheck is using
the explicitly instantiated version of std::istringstream in libstdc++,
but my gdb-foo isn't good enough to work out what's going on past that.
I've taken a good look at the cppcheck code, and I believe that it's
using the STL correctly. If I'm being picky, cppcheck assumes that the
std::istringsteam is going to construct successfully, i.e. there doesn't
seem to be a 'catch' exception handler. But given the small size of the
strings we're dealing with, it's not too unreasonable to expect the
string copy to succeed.
Anyway, my assumption at the moment is that this is an issue with libstdc++.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple