Skip to content

Segmentation fault in QApplication destructor in CalcQt #62

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
paoloambrosio opened this issue Jun 22, 2013 · 7 comments · Fixed by #161
Closed

Segmentation fault in QApplication destructor in CalcQt #62

paoloambrosio opened this issue Jun 22, 2013 · 7 comments · Fixed by #161
Assignees
Labels
Milestone

Comments

@paoloambrosio
Copy link
Member

Everything works until the program is shutting down and the QApplication destructor is called:

Program received signal SIGSEGV, Segmentation fault.
0x004eba9a in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
(gdb) backtrace
#0  0x004eba9a in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
#1  0x004ebc0c in QPixmapCache::clear() ()
   from /usr/lib/i386-linux-gnu/libQtGui.so.4
#2  0x00484a3d in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
#3  0x00404a9c in QApplication::~QApplication() ()
   from /usr/lib/i386-linux-gnu/libQtGui.so.4
#4  0x011f5f51 in ?? () from /lib/i386-linux-gnu/libc.so.6
#5  0x011f5fdd in exit () from /lib/i386-linux-gnu/libc.so.6
#6  0x011dc4db in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#7  0x0808e0b9 in _start ()

Happens on:

  • Ubuntu Linux 12.10 x64, gcc 4.7.2, Qt 4.8.3, Boost 1.53.0
  • Linux Mint 13 x32, gcc 4.6.3, Qt 4.8.1
@gambr
Copy link
Contributor

gambr commented Jul 23, 2013

Ubuntu Linux 13.04, gcc 4.7.3, Qt 4.8.4, Boost 1.53.0 works fine.

Something related to the gfx card? Are Mint and Ubuntu installed on the same PC? Does CalcQt example work fine outside cucumber?

@konserw
Copy link
Contributor

konserw commented Feb 25, 2016

I'm wondering if this still happens, especialy on with PR #98

@paoloambrosio paoloambrosio modified the milestones: v0.3.1, v0.4, v0.3.2 Mar 26, 2016
@muggenhor
Copy link
Contributor

Still reproducible:

Thread 1 "BoostCalculator" received signal SIGSEGV, Segmentation fault.
0x00007ffff62e5fed in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
(gdb) bt full
#0  0x00007ffff62e5fed in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
No symbol table info available.
#1  0x00007ffff681ddcc in QApplication::~QApplication() () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#2  0x00007ffff4e59ff8 in __run_exit_handlers (status=0, listp=0x7ffff51e45f8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
        atfct = <optimized out>
        onfct = <optimized out>
        cxafct = <optimized out>
#3  0x00007ffff4e5a045 in __GI_exit (status=<optimized out>) at exit.c:104
No locals.
#4  0x00007ffff4e40837 in __libc_start_main (main=0x60547a <main>, argc=1, argv=0x7fffffffdb58, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fffffffdb48) at ../csu/libc-start.c:325
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 5378916977031014334, 6186992, 140737488345936, 0, 0, -5378917201933736002, -5378941200771291202},
              mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x1, 0x60547a <main>}, data = {prev = 0x0, cleanup = 0x0, canceltype = 1}}}
        not_first_call = <optimized out>
#5  0x00000000005e6819 in _start ()
No symbol table info available.
(gdb)
  • Ubuntu 16.04.3, gcc 5.4.0 and clang 4.0.0, Qt 5.5.1, Boost 1.58.0
  • Debian Stretch 9.1, gcc 6.3.0 and clang 5.0.0-svn305653-1, Qt 5.7.1, Boost 1.63.0

@konserw
Copy link
Contributor

konserw commented Aug 17, 2017

I was just looking at this. I believe that this line is root cause:

@muggenhor
Copy link
Contributor

muggenhor commented Aug 17, 2017

I assume you are referring to the static part? If Qt has some ordering requirements at destruction then this could indeed be the cause. (Inter-file ordering of globals is undefined).

Putting this in a ScenarioScope might be a solution to this. I can experiment a bit with this tomorrow.

@konserw
Copy link
Contributor

konserw commented Aug 17, 2017

Probably GlobalScope would be even better but it is not yet implemented, i.e. #66
I'm testing out adding scenarioScope in the BEFORE hook.
How do you use ScenarioScope with non-default constructor?

@paoloambrosio
Copy link
Member Author

You could create a wrapper object with a default constructor, if I understand your question correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants