Tue 24 Jan 2017 09:55:11 PM UTC, comment #17:
Still crashes with the example in the original report on 4.2.0 and
4.3.0+.
Changing status to "In Progress".
|
Fri 26 Aug 2016 09:07:57 PM UTC, comment #16:
With Octave-4.1.0+ hg id 0ca341841198 (3 days ago), 32bit Octave on Win-10,
Octave still crashes with the example in the original report for n=12. It doesn't crash for n=11.
|
Fri 26 Aug 2016 10:31:42 AM UTC, comment #15:
@Rik:
With octave-4.1.0+ hg id 6cbbd550aa91 ("allow subsasgn.."), Octave still crashes with the example in the orginal report for n=12.
FWIW, Octave crashes while still only the first complete blue rectangle has been drawn. But maybe that is a red herring due to multithreading?
|
Thu 25 Aug 2016 07:35:51 PM UTC, comment #14:
Still the same crash with a windows 64bit (--enable-windows-64) version from Aug. 21. Is that recent enough?
Tomorrow I hope to make a newer build.
|
Wed 24 Aug 2016 01:50:10 PM UTC, comment #13:
@Philip: Can you re-test for this bug? There has been a lot of cleanup to the graphics functions, and I think this issue may have disappeared. This is still listed as severity 4 which is impeding the 4.2 release.
|
Mon 08 Aug 2016 08:45:40 PM UTC, comment #12:
Bug #46501 has been patched by jwe and closed and this bug may have been fixed with it.
@Philip: Can you build a version for Windows via MXE and re-test?
Changing Status to "Need Info".
|
Wed 13 Jul 2016 12:47:52 PM UTC, comment #11:
Ok, see attached gdb.txt
(file #37851)
|
Wed 13 Jul 2016 11:34:05 AM UTC, comment #10:
Great. In gdb, can you type
to get a stack trace of all threads? That will tell us which part of Octave called the system library where the actual crash occurred.
|
Wed 13 Jul 2016 10:53:20 AM UTC, comment #9:
I can't compile Octave for Windows but just running gdb on the binary gave this:
---
warning: Invalid parameter passed to C runtime function.
[New Thread 6312.0x13d4]
[New Thread 6312.0x1180]
[New Thread 6312.0x13c0]
[New Thread 6312.0xbdc]
[New Thread 6312.0x668]
[New Thread 6312.0x1d78]
Program received signal SIGSEGV, Segmentation fault.
0x77099947 in ntdll!RtlImageNtHeaderEx () from C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb)
---
|
Wed 13 Jul 2016 10:23:02 AM UTC, comment #8:
jsh, if you have gdb available on the system, then the attached patch might work.
(I personally think Octave should do a stack trace in the signal handler by default, for cases such as this, but others have disagreed.)
(file #37842)
|
Wed 13 Jul 2016 07:59:56 AM UTC, comment #7:
Running without Gui doesn't result in any error messages, just crash. Is there a way to run gdb with Octave on Windows?
Some more testing revealed that the issue seems to be the nested parents, as in the code below:
|
Wed 13 Jul 2016 07:29:12 AM UTC, comment #6:
Philip and jsh, does file #37622 from bug #46501 prevent the crash?
(To apply it, the "application" variable has to be replaced by "qt_app". I'll post an updated patch there soon.)
As Mike said, a stack trace would help. Also, just running it from the command line will allow any error messages to be captured.
|
Wed 13 Jul 2016 05:51:44 AM UTC, comment #5:
This is still the case with dev Octave :-(
$ hg -v summary
parent: 22097:5ad67277b007 tip
include builtin-defun-decls.h as needed
branch: default
Status back to "Confirmed"
|
Tue 12 Jul 2016 10:32:03 PM UTC, comment #4:
Still crashes for me in 4.0.3
|
Tue 12 Jul 2016 04:17:31 PM UTC, comment #3:
In any case, we need a re-test since this bug was originally confirmed back in September, 2015 by Philip and there have been a lot of changes since then.
I'm changing the status back to "Need Info" until/if it can be confirmed again.
|
Tue 12 Jul 2016 04:03:05 PM UTC, comment #2:
A gdb backtrace of this crash would be useful to identify where the problem is.
|
Wed 02 Sep 2015 11:25:08 AM UTC, comment #1:
I can confirm this with an --enable-windows-64 Octave-4.1.0+ on Win7 64-bit.
Up until n=11 goes OK, n=12 will reliably crash Octave.
|
Tue 01 Sep 2015 11:00:55 PM UTC, original submission:
I found that when I run the script below with n>=12 Octave with the qt gui will crash (it works fine in linux though).
|