Re: cppcheck 1.77 Segmentation fault (64-bit)

[Christian Franke]

David Stacey wrote:

...
Anyway, my assumption at the moment is that this is an issue with 
libstdc++.


Any thoughts?


The export table of cygstdc++-6.dll 6.3.0-1 is broken, see:
https://cygwin.com/ml/cygwin/2017-02/msg00093.html

Christian


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

Re: cppcheck 1.77 Segmentation fault (64-bit)

[David Stacey]

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

Re: cppcheck 1.77 Segmentation fault (64-bit)

[David Stacey]

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.


Note that there's more to this than simply constructing a 
std::istringstream - compiling the example given in [1] works fine, even 
if I use the same g++ switches used to build cppcheck. So there's 
something else going on...


Dave.

[1] 
http://www.cplusplus.com/reference/sstream/basic_istringstream/basic_istringstream/



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

Re: cppcheck 1.77 Segmentation fault (64-bit)

[David Stacey]

On 29/01/17 22:13, Christian Franke wrote:

Jim Reisert AD1C wrote:

Best as I can tell, the seg fault is due to having installed the test
version of gcc 6.0.


I could reproduce the cppcheck segfault on 32-bit Cygin if 
libstd++6-6.3.0-1 is installed.


Possibly a variant of this problem:
https://cygwin.com/ml/cygwin/2017-01/msg00315.html


Thank you both for investigating this. At least this isn't something 
that will affect all users. I'm going to be a little busy for a couple 
of days, but I'll take a look at this later in the week.


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

Re: cppcheck 1.77 Segmentation fault (64-bit)

[Christian Franke]

Jim Reisert AD1C wrote:

Best as I can tell, the seg fault is due to having installed the test
version of gcc 6.0.


I could reproduce the cppcheck segfault on 32-bit Cygin if 
libstd++6-6.3.0-1 is installed.


Possibly a variant of this problem:
https://cygwin.com/ml/cygwin/2017-01/msg00315.html

Downgrading /bin/cygstdc++-6.dll fixes the cppcheck crash.



  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.


Did you possibly miss to downgrade libstdc++6 package ?
It is not visible if 'gcc' is entered in the Search field of setup.exe.

Christian


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

Re: cppcheck 1.77 Segmentation fault (64-bit)

[Jim Reisert AD1C]

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.

- Jim

-- 
Jim Reisert AD1C, , http://www.ad1c.us

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

Re: cppcheck 1.77 Segmentation fault (64-bit)

[David Stacey]

On 26/01/2017 02:56, Jim Reisert AD1C wrote:

The latest version of cppcheck segment-faults.

# cppcheck --enable=all -I include -I ../../library/include
-I/usr/include/libxml2 \
 --suppressions-list=dx4wupd.check \
 --suppress=missingIncludeSystem --quiet \
 --template={file}:{line}:{severity}:{message}
dx4wupd.cpp dx4wupdDlg.cpp


I'm sorry, but I can't reproduce this. I tested cppcheck on some of my 
own code before uploading the package (I have a some deliberately dodgy 
code samples for this very purpose) and it worked fine. I also run 
cppcheck's own testsuite as part of the build, and all of those tests 
passed.


Are you able to run really simple cppcheck commands, such as 'cppcheck 
--version' or 'cppcheck --help'?


If those work, what happens if you simplify the command line somewhat - 
say just scan one file, or omit the suppression switches, or omit the 
templates / include paths? Can you isolate one command line switch 
that's causing the crash?


If cppcheck still seg faults, can you send me a sample of code that 
exhibits the problem? If you don't want to post the source code to a 
public mailing list, you can e-mail a sample to me privately. Don't 
include your entire build tree, but try to cut it down to a small sample 
that still exhibits the problem.



Stack trace:
FrameFunctionArgs
000BAA0  001004E27F3 (000, 001801FC280, 002, 00100509D10)
000BDB0  0010040229F (003000D, 000CC00, 000CA90, 000C9C0)
000CC00  00100405C31 (003E6FCF578, 003E6FCF578, 008, 001005CFBE0)
000CC00  00100408ADC (001801441C9, 003E6F79950, 001802E5880, 001005CF790)
000CCC0  0010059E5FE (00180188C7A, 0018023BE00, 00180053801, 02F)
000CCC0  00180047902 (000, 000, 000, 000)
000  00180045693 (000, 000, 000, 000)
000FFF0  00180045744 (000, 000, 000, 000)
End of stack trace


Thanks for including that, but sadly it's not as helpful as it might be. 
The stack trace shows the code going bang in the constructor of a 
std::basic_istream, but that doesn't really make sense (to me at least) 
in the context of the parent frame(s). It could be that there's some 
inlined code or a compiler generated function confusing me.


A couple of frames in and we're into cppcheck code. It's going over just 
after parsing the command line arguments - so I don't think it's even 
started looking at your code yet. With that in mind, I copied and pasted 
the exact same command you gave, and whilst it gave an error message (as 
I don't have your source files) it didn't crash.


So send me a sample of code that reproduces the problem, and I'll take 
another look.


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