Segmentation fault with binutils 2.28.1

[ghost]

Using these build scripts:

• http://github.com/svnpenn/glade/blob/ce20757/tageditor/install.sh
• http://github.com/svnpenn/glade/blob/ce20757/tagparser/install.sh
• http://github.com/svnpenn/glade/blob/ce20757/cpp-utilities/install.sh

and with this file (regionsAllowed=DE,US):

youtube-dl --add-metadata --format m4a --output z.m4a wMeyeS_7YXU

I am getting this error when building with binutils 2.28.1:

$ tageditor -gf z.m4a
Segmentation fault

Note that building with binutils 2.25.0 works as expected:

$ tageditor -gf z.m4a
Tag information for "z.m4a":
 - MP4/iTunes tag
    Title             Aphex Twin - Stone In Focus
    Artist            Diego Acosta
    Year              20160503
    Encoder           Lavf57.82.101

[Martchus]

I'm currently doing some changes regarding the CLI, might be a regression. Last time I worked on the tag editor I didn't noticed that bug (using Clang 5.0 and GCC 7.2). Could you do a debug build to determine in which line the segfault occurs?

[ghost]

The debug build does the same thing? even with no arguments:

$ tageditor
Segmentation fault

also I dont know if it is recent change - I tried these versions with same result:

• v2.2.5
• v2.2.4
• v2.2.3
• v2.2.2
• v2.2.1

[Martchus]

The debug build does the same thing?

This makes things easier. Issues which only occur in release builds are hard to track.

You need to run the program with the debugger. Since you're using GCC, gdb is your tool. See https://stackoverflow.com/questions/2876357/determine-the-line-of-c-code-that-causes-a-segmentation-fault for an example. Or you can just use an IDE like Qt Creator if you don't like to fiddle with gdb directly.

Thanks for the extensive testing. If it is reproducible with all those versions it is not due to my latest changes (at least not the latest changes in the tageditor repository). Hard to tell something more specific without having debug info, though.

[ghost]

Here you go

(gdb) run
Starting program: /var/cache/glade/tageditor/tageditor 
[New Thread 4140.0x880]

Program received signal SIGSEGV, Segmentation fault.
std::ostream::sentry::sentry (this=this@entry=0x22d120, __os=...)
  at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/
  mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/
  ostream.tcc:51
51 /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/
  mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/
  ostream.tcc: No such file or directory.
(gdb) backtrace
#0  std::ostream::sentry::sentry (this=this@entry=0x22d120, __os=...)
  at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/
  mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/
  ostream.tcc:51
#1  0x00000000005d3759 in std::__ostream_insert<char, std::char_traits<char> >
  (__out=..., 
  __s=__s@entry=0x5f3d80 <__gnu_cxx::__default_lock_policy+3388> "Application
  has not been build with Qt widgets GUI support.", __n=59)
  at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/
  mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/
  ostream_insert.h:82
#2  0x00000000005ea157 in std::operator<< <std::char_traits<char> > (
  __out=..., 
  __s=0x5f3d80 <__gnu_cxx::__default_lock_policy+3388> "Application has not been
  build with Qt widgets GUI support.")
  at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/
  mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/std/
  ostream:561
#3  0x00000000004038ce in main ()

[Martchus]

So it fails directly in main() when trying to print "Application has not been built with Qt widgets GUI support.". Likely this is just a symptom of a previous mistake. I'll look into it.

[Martchus]

My own build, compiled with GCC 7.2, binutils 2.29, and mingw-w64 (CRT, headers, winpthreads) 5.0.2 works (tested under Windows 10 and Wine): https://martchus.no-ip.biz/repo/win/static/devel/tageditor-devel-2.2.5-319.3525588-static-x86_64-w64-mingw32.tar.xz

I suppose a simple CLI application using io streams from C++ standard library (std::cout, std::cerr) built using your version of GCC, binutils and mingw-w64 works?

I just have to ask because such errors in Windows version of GCC/binutils and mingw-w64 are not uncommon, eg.
https://bugs.archlinux.org/task/49860?string=mingw-w64-gcc&project=5&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=33&status%5B0%5D=&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=
https://sourceforge.net/p/mingw-w64/bugs/548

If the problem is caused by my code, I suspect startConsole() and convertArgsToUtf8() could be candidates for further investigation (https://github.com/Martchus/cpp-utilities/blob/master/application/commandlineutils.cpp#L62). You can try to build without them by removing their calls in the corresponding macros (https://github.com/Martchus/cpp-utilities/blob/master/application/commandlineutils.h#L25).

[ghost]

@Martchus thanks for that, but that build really isnt germane, because yours has QT - hence it would never have a chance of triggering the error I have

To really "put the ball back in my court" - you would need a working build that uses binutils 2.28.1 -
without QT

[Martchus]

Initially, you said the error would also occur when using the CLI, eg.

tageditor -gf z.m4a
Segmentation fault

In this case it makes no difference whether Qt is enabled or not and of course I tested that case with my binary (extra for you with the crappy cmd.exe). The issue is likely called by the two mentioned functions and maybe by using the standard IO streams. In the last case it is likely caused by the Windows version of GCC (likely libstdc++ in particular).

I'm not taking the effort to test with old GCC versions for finding bugs which are likely outside of the scope of this project (as the bugs mentioned in the last comment). But as far as I remember I was able to produce correct Windows builds using GCC 6.2 and GCC 6.3 (in contrast to GCC 6.1). However, the issues depended on various things such as CPU architecture (i686 vs. x86_64) and optimization flags. You could at least try to play around with optimization flags.

And does a simple CLI application using io streams from C++ standard library (std::cout, std::cerr) with your version of GCC work? Shouldn't take long to find out.

[ghost]

No, because that will give a different backtrace:

(gdb) run
Starting program: /var/cache/glade/tageditor/tageditor -gf z.m4a
[New Thread 5340.0x1024]

Program received signal SIGSEGV, Segmentation fault.
std::ostream::sentry::sentry (this=this@entry=0x22c850, __os=...)
  at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/
  mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/
  ostream.tcc:51
51 /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/
  mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/
  ostream.tcc: No such file or directory.
(gdb) backtrace
#0  std::ostream::sentry::sentry (this=this@entry=0x22c850, __os=...)
  at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/
  mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/
  ostream.tcc:51
#1  0x00000000005d0e79 in std::__ostream_insert<char, std::char_traits<char> >
  (__out=..., 
  __s=__s@entry=0x5f256e <Cli::fieldNamesForSet+1118> "Tag information for \"",
  __n=21)
  at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/
  mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/
  ostream_insert.h:82
#2  0x00000000005e7097 in std::operator<< <std::char_traits<char> > (
  __out=..., 
  __s=0x5f256e <Cli::fieldNamesForSet+1118> "Tag information for \"")
  at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/
  mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/std/
  ostream:561
#3  0x0000000000409cde in Cli::displayTagInfo(ApplicationUtilities::Argument
  const&, ApplicationUtilities::Argument const&, ApplicationUtilities::Argument
  const&) ()
#4  0x000000000058048f in void std::_Bind<void (*(std::reference_wrapper
  <ApplicationUtilities::Argument const>, std::reference_wrapper
  <ApplicationUtilities::Argument const>, std::reference_wrapper
  <ApplicationUtilities::Argument const>))(ApplicationUtilities::Argument
  const&, ApplicationUtilities::Argument const&, ApplicationUtilities::Argument
  const&)>::__call<void, ApplicationUtilities::ArgumentOccurrence const&, 0ull,
  1ull, 2ull>(std::tuple<ApplicationUtilities::ArgumentOccurrence const&>&&,
  std::_Index_tuple<0ull, 1ull, 2ull>) ()
#5  0x00000000005805d4 in void std::_Bind<void (*(std::reference_wrapper
  <ApplicationUtilities::Argument const>, std::reference_wrapper
  <ApplicationUtilities::Argument const>, std::reference_wrapper
  <ApplicationUtilities::Argument const>))(ApplicationUtilities::Argument
  const&, ApplicationUtilities::Argument const&, ApplicationUtilities::Argument
  const&)>::operator()<ApplicationUtilities::ArgumentOccurrence const&, void>
  (ApplicationUtilities::ArgumentOccurrence const&) ()
#6  0x0000000000576039 in std::_Function_handler<void (ApplicationUtilities::
  ArgumentOccurrence const&), std::_Bind<void (*(std::reference_wrapper
  <ApplicationUtilities::Argument const>, std::reference_wrapper
  <ApplicationUtilities::Argument const>, std::reference_wrapper
  <ApplicationUtilities::Argument const>))(ApplicationUtilities::Argument
  const&, ApplicationUtilities::Argument const&, ApplicationUtilities::Argument
  const&)> >::_M_invoke(std::_Any_data const&, ApplicationUtilities::
  ArgumentOccurrence const&) ()
#7  0x0000000000516a1b in std::function<void (ApplicationUtilities::
  ArgumentOccurrence const&)>::operator()(ApplicationUtilities::
  ArgumentOccurrence const&) const ()
#8  0x0000000000415146 in ApplicationUtilities::ArgumentParser::invokeCallbacks
  (std::vector<ApplicationUtilities::Argument*, std::allocator
  <ApplicationUtilities::Argument*> > const&) ()
#9  0x0000000000411db8 in ApplicationUtilities::ArgumentParser::parseArgs(int,
  char const* const*) ()
#10 0x00000000004038a3 in main ()

[Martchus]

The backtrace is different, but it show the same issue: It dies when trying to print something the first time via std::cout.

Still, the two mentioned (Windows specific functions) might cause the issue or your tool chain. So does a simple CLI application using io streams from C++ standard library (std::cout, std::cerr) with your version of GCC work? And does it work if you disabled those functions as described in the previous comment?

[ghost]

Here you go:

$ cat z.cpp
#include <iostream>
main() {
  std::cout << "cout test\n";
}

$ x86_64-w64-mingw32-g++ -static -o z z.cpp

$ ./z
Segmentation fault

[Martchus]

So this is a problem in your toolchain - likely libstdc++. Maybe you find a workaround by playing around with the build flags. Note that the Windows version of GCC is just buggy as hell. I am aware that this - combined with the necessary extra treatment required under Windows eg. for UTF-8 - doesn't give a great user experience of my software under Windows. However, using GCC is currently the easiest way for me to provided Windows support and I'm not going to take any extra effort. (If someone wants to adjust the build scripts to be able to use Clang or MS compiler under Windows, feel free to contribute.)

---

I'm also still wondering whether maybe just your GCC package is broken, because I can't remember such a severe bugs when using GCC 6.3 myself.

[Martchus]

Ok, so we know at least what causes this issue in particular. Note that when I had been using mingw-w64-binutils 2.28 (before recent update to 2.29) I didn't encounter this issue. I never tried 2.28.1.

[ghost]

this is fixed with new version of binutils

https://cygwin.com/ml/cygwin/2017-10/msg00067.html