public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: David Stacey <drstacey@tiscali.co.uk>
To: cygwin@cygwin.com
Subject: Re: cppcheck 1.77 Segmentation fault (64-bit)
Date: Sat, 04 Feb 2017 15:57:00 -0000	[thread overview]
Message-ID: <37f6781d-8ce8-40bd-855a-bf5857bde55b@tiscali.co.uk> (raw)
In-Reply-To: <ed80a1b5-754f-09f1-614d-b84aaf4ec18b@tiscali.co.uk>

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

Any thoughts?

Dave.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

  reply	other threads:[~2017-02-04 15:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-26  2:57 Jim Reisert AD1C
2017-01-26 22:21 ` David Stacey
2017-01-29 21:04   ` Jim Reisert AD1C
2017-01-29 22:13     ` Christian Franke
2017-01-29 22:55       ` David Stacey
2017-02-04  0:08     ` David Stacey
2017-02-04 15:57       ` David Stacey [this message]
2017-02-08  6:20         ` Christian Franke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37f6781d-8ce8-40bd-855a-bf5857bde55b@tiscali.co.uk \
    --to=drstacey@tiscali.co.uk \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).