Fri 11 Mar 2016 06:33:08 PM UTC, comment #10:
I re-built and the thread sanitizer report is the same. I didn't want to spend too much time digging in to the internals of the ThreadSanitizer, but my guess is that it only recognizes some constructs, like pthread.join, as creating ordering relationships. The Qt Slot mechanism is probably not recognized.
|
Thu 10 Mar 2016 08:24:10 PM UTC, comment #9:
Pushed:
http://hg.savannah.gnu.org/hgweb/octave/rev/217e6e97085b
Rik, it would be interesting to see if this changes the thread sanitizer report.
How about writing up how you did both sanitizers on the wiki?
|
Thu 10 Mar 2016 08:04:13 PM UTC, comment #8:
Rik, we discussed on IRC. I think the change is OK.
|
Thu 10 Mar 2016 07:55:20 PM UTC, comment #7:
@Mike: I'll post something to the Maintainer's list to try and get someone knowledgeable to review.
|
Thu 10 Mar 2016 06:31:32 PM UTC, comment #6:
Thanks for the report, that certainly indicates that there are some threading problems in the initialization. While the stack is not exactly the same, my crash could have occurred after some earlier interaction.
My understanding of the GUI is that Qt has to run in the main thread, so it starts another thread to run the interpreter and talks to it over the octave_link class. This thread is starting while the GUI is still being constructed, though, and before QApplication::exec is called.
The following patch defers execution of the interpreter until after the QApplication main loop is running, and this seems to work better for me so far (running for 30 minutes now without a crash).
I'm also not that comfortable with the GUI so I'd appreciate someone who works on it more to see if this is safe, maybe test on Windows also.
(file #36598)
|
Wed 09 Mar 2016 08:28:42 PM UTC, comment #5:
See bug #47372 where I was able to get the address sanitizer running with gcc. There are certainly memory leaks.
After great effort, I was able to get the thread sanitizer running. I've attached the log as thread.log to this report. Sure enough there is a reported data race condition between threads in set_default_prompts(). My guess is that is what is causing the segfault for you.
I'm no help in fixing this though as I never mess around with the GUI.
(file #36588)
|
Tue 08 Mar 2016 04:59:44 PM UTC, comment #4:
Comment #3 from Lachlan is consistent with some sort of out-of-bounds memory access. I find that lots of problems disappear when I actually use gdb because the internals of the program are re-arranged while running under the debugger.
The fact that it only happens when QT_ACCESSIBILITY is 1 makes me think it really is a problem with the Qt libraries, but I suppose there is a possibility that we are doing something wrong.
I would try re-configuring and using the '--enable-address-sanitizer-flags'. Try 'man gcc' and search for sanitizer.
I notice in the GCC documentation that there is also a thread sanitizer option. You might try configuring your CFLAGS, CXXFLAGS, CPPFLAGS with that since the segfault happens in set_default_prompts() which is the very next function call after octave_threads::init().
|
Thu 03 Mar 2016 03:31:16 AM UTC, comment #3:
I also often see segfaults when starting Octave. It often happens frequently when I make some change in the GUI code (which is why I haven't reported it), but those changes are usually unrelated to initialization.
When I run in gdb to get a stack trace, it normally works fine -- even for executables that consistently crash in start-up from the command line.
$0.02
|
Thu 03 Mar 2016 01:12:33 AM UTC, comment #2:
This works for me. I've been running your test for about 20 minutes without problems. It may be that by using Qt we are now exposed to their bugs. I'm having a horrible time right now with KDE5 and Qt5.
|
Thu 03 Mar 2016 12:54:04 AM UTC, comment #1:
This segfault only occurs when my environment contains QT_ACCESSIBILITY=1. This setting has come up before on other bug reports but was related to other issues with different configurations. Some users reported a crash but it was inconclusive at the time. I can now reliably reproduce this (eventually) with the same stack context each time.
|
Thu 03 Mar 2016 12:05:42 AM UTC, original submission:
I'm seeing a sporadic segfault when Octave's GUI starts up.
The attached contains a gdb backtrace of the two threads showing that they are both in initialization routines.
I got this by running the following shell loop:
Runs for a few minutes before a segfault occurs.
I'll try messing with my environment to make sure it's not something about my configuration causing this.
This is what leads to a segfault when building doc/interpreter for me occasionally. I don't see the crash at all with octave-cli.
|