After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 790981 - Crash when generating puzzle
Crash when generating puzzle
Status: RESOLVED FIXED
Product: gnome-sudoku
Classification: Applications
Component: general
git master
Other Linux
: Normal critical
: ---
Assigned To: gnome-sudoku-maint
gnome-sudoku-maint
Depends on:
Blocks:
 
 
Reported: 2017-11-29 13:44 UTC by Ernestas Kulik
Modified: 2017-11-29 16:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Link with pthreads (1.13 KB, patch)
2017-11-29 13:44 UTC, Ernestas Kulik
committed Details | Review

Description Ernestas Kulik 2017-11-29 13:44:30 UTC
This might be different with GCC, but building with Clang and trying to start a game results in a crash when generating the puzzle. This is due to calling call_once() without linking to pthread.

Some context: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
Comment 1 Ernestas Kulik 2017-11-29 13:44:49 UTC
Created attachment 364620 [details] [review]
Link with pthreads

Calling call_once() without having linked to a pthread library will
result in an unhandled exception when generating puzzles.
Comment 2 Ernestas Kulik 2017-11-29 13:48:52 UTC
Here’s the exception:

terminate called after throwing an instance of 'std::system_error'
  what():  Unknown error -1

And here’s the stack trace:

  • #0 raise
    from /lib64/libc.so.6
  • #1 abort
    from /lib64/libc.so.6
  • #2 __gnu_cxx::__verbose_terminate_handler()
    from /lib64/libstdc++.so.6
  • #3 ??
    from /lib64/libstdc++.so.6
  • #4 std::terminate()
    from /lib64/libstdc++.so.6
  • #5 __cxa_throw
    from /lib64/libstdc++.so.6
  • #6 std::__throw_system_error(int)
    from /lib64/libstdc++.so.6
  • #7 std::call_once<qqwing_generate_puzzle::\$_0>
    at /usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/mutex line 692
  • #8 qqwing_generate_puzzle
    at /home/ernestas/jhbuild/checkout/gnome-sudoku/lib/qqwing-wrapper.cpp line 44
  • #9 sudoku_generator_generate_board
    at /home/ernestas/jhbuild/checkout/gnome-sudoku/lib/sudoku-generator.vala line 68
  • #10 sudoku_generator_worker_run
    at /home/ernestas/jhbuild/checkout/gnome-sudoku/lib/sudoku-generator.vala line 47
  • #11 __lambda5_
    at /home/ernestas/jhbuild/checkout/gnome-sudoku/lib/sudoku-generator.vala line 87
  • #12 ___lambda5__gfunc
    at /home/ernestas/jhbuild/checkout/gnome-sudoku/lib/sudoku-generator.vala line 86
  • #13 g_thread_pool_thread_proxy
    at /home/ernestas/jhbuild/checkout/glib/glib/gthreadpool.c line 307
  • #14 g_thread_proxy
    at /home/ernestas/jhbuild/checkout/glib/glib/gthread.c line 784
  • #15 start_thread
    from /lib64/libpthread.so.0
  • #16 clone
    from /lib64/libc.so.6

Comment 3 Michael Catanzaro 2017-11-29 15:30:21 UTC
Review of attachment 364620 [details] [review]:

::: configure.ac
@@ +55,3 @@
 AC_SUBST([GLIB_REQUIRED])
 
+AX_PTHREAD

Heh, I didn't know about AX_PTHREAD!

::: lib/Makefile.am
@@ +19,3 @@
 
+libsudoku_la_CXXFLAGS = \
+	$(PTHREAD_CFLAGS)

Yay, this looks right, but it's managed to violate the well-defined convention of using _CFLAGS variables only for stuff that should be added to... _CPPFLAGS. I don't know what to think of that, since AX_PTHREAD is being sane here, where pkg-config is insane, but the insane pkg-config convention is so entrenched at this point that violating it seems like a bad idea. Oh well. I would just leave a warning comment to mention that this _CXXFLAGS is really the right place for it, or someone is bound to assume it's only for include directories and move it to _CPPFLAGS.

I should really port this thing to meson....
Comment 4 Ernestas Kulik 2017-11-29 16:21:27 UTC
Attachment 364620 [details] pushed as ec20e84 - Link with pthreads
Comment 5 Ernestas Kulik 2017-11-29 16:24:55 UTC
(In reply to Michael Catanzaro from comment #3)
> Yay, this looks right, but it's managed to violate the well-defined
> convention of using _CFLAGS variables only for stuff that should be added
> to... _CPPFLAGS.

Just when I think that I managed to escape the shackles of Autotools, I learn this.

> I don't know what to think of that, since AX_PTHREAD is
> being sane here, where pkg-config is insane, but the insane pkg-config
> convention is so entrenched at this point that violating it seems like a bad
> idea. Oh well. I would just leave a warning comment to mention that this
> _CXXFLAGS is really the right place for it, or someone is bound to assume
> it's only for include directories and move it to _CPPFLAGS.

My thought process was just “this affects only the C++ code, so CXXFLAGS it is”, but I’m glad to hear that I wasn’t too far off.

> I should really port this thing to meson....

This is not that big, maybe I’ll free up some time to do it, if you don’t mind. :p
Comment 6 Michael Catanzaro 2017-11-29 16:45:26 UTC
Meson ports are always appreciated. ;)