Fri 10 Nov 2017 06:03:32 AM UTC, comment #11:
It's been a year since last activity on this report, and it references a deprecated version of Octave. Closing report.
|
Sun 27 Aug 2017 04:46:33 PM UTC, comment #10:
Any progress?
|
Fri 18 Nov 2016 10:19:57 PM UTC, comment #9:
Thanks John. If your program is still crashing Octave with version 4.2.0, and you think it happens at the point of one of the plot commands, then the easiest way to allow someone else to reproduce this is to save the entire workspace right before the plot command. Verify that loading the workspace into a new Octave session, not using any openEMS functions, and then performing one or more plot commands causes the same crash.
|
Fri 18 Nov 2016 09:59:58 PM UTC, comment #8:
Yes, I am interested. This semester was particularly complicated, and I had to suspend the experiments with OpenEMS. Things are winding down and I'll probably have some time.
I see that the latest release is now 4.2, so I'll install that, and try to get the data you asked for.
Thanks for leaving the bug open.
|
Fri 18 Nov 2016 07:44:10 PM UTC, comment #7:
Adding category Plotting.
Is there any remaining interest in pursuing this crash? Can the OP test in Octave 4.2.0? Can the OP provide only the data arrays that exist in the workspace just before the plot command so that one of us can attempt to reproduce this? Or do we just close this as invalid / unreproducible?
|
Wed 15 Jun 2016 07:58:43 AM UTC, comment #6:
You can see if the plot command is really at fault by getting to that line, saving the workspace, restarting Octave, reloading the workspace and issuing the plot command.
If that causes a crash, then we only need to look at what is odd in the plot command.
However, it is much more likely that something else has corrupted the memory beforehand.
The only C++ plug in from openEMS seems to be something to handle HDF5 files. Do you use that? Can you reproduce the bug using only the .m files from openEMS, and not the .cc file?
|
Wed 15 Jun 2016 05:26:42 AM UTC, comment #5:
> graphics_toolkit gnuplot
at the top of the program doesn't make any difference.
I've attached a quite reduced form of the program, which still generates the same problem.
I found that the problem occurs in line 92 of that program:
I checked the freq and Zin arrays, can they seem reasonable values (at least not NaNs or so).
Following steps:
- plot.m, line 210
- _plt_get_axis_arg_(), line 29.
- plot.m line 221
I can't seem to get a breakpoint working on that location.
If I set it, and run, the program crashes, but I do seem to
be able to step to this point.
BTW, the 'figure' statement works - an empty plot appears. I hadn't seen it earlier, as the error makes it disappear again.
I have the impression the problem is in the call to gca(), but the behaviour seems somewhat unpredictable.
(file #37483)
|
Tue 14 Jun 2016 08:38:37 PM UTC, comment #4:
One thing to try is switching to the gnuplot toolkit. At the start of your session, or in your .octaverc file, add
Does the simulation get farther with this change?
|
Tue 14 Jun 2016 04:29:19 PM UTC, comment #3:
> echo on all
Great... LOADs of output. I'll attach a gzip with the output I could recover with the screen buffer.
> place a breakpoint there and re-run it.
I think that from the gzip file, and the little I could see in the gdb output (see below), it should be possible to determine the crash point. Still, I'll try to check if I can find why the assert() is failing.
> what input did you give to openEMS
I wrote a script to simulate a patch antenna. I'll try make as small a version I can and post it.
> What changes did you make to "lower the ending criteria"?
To be clear, I changed that to make the program more or less 'debugable'. The original version takes about 2.5 hours to produce the crash - hardly interactive :) So I change the creation of the FDTD object to
It effectively stops the simulation at -10dB instead of the default -50dB. That doesn't change the error behaviour, but does shorten the run to a few minutes.
Output from gdb on exit:
(file #37474)
|
Tue 14 Jun 2016 04:16:02 PM UTC, comment #2:
Also, if Octave is using a dynamic external library then the cause is most likely something in that external library (openEMS in this case). The Octave core is pretty robust and we work hard not to segfault, but once you mix in third-party code it becomes more likely that someone has not got the interface quite right.
|
Tue 14 Jun 2016 10:49:51 AM UTC, comment #1:
Thanks for the report.
You ask how you can debug it further. One way is to use
to find out where it is crashing, then place a breakpoint there and re-run it. That will tell you exactly which command is failing, on what arguments, and what the stack trace is.
If you want others to help debug, it would be useful to tell us how we can reproduce it. For example, what input did you give to openEMS? What changes did you make to "lower the ending criteria"?
|
Tue 14 Jun 2016 03:42:36 AM UTC, original submission:
Below is the output of a run of the script. Normal runs take hours, but I lowered the ending criteria to stops earlier.
Running Octave in gdb, ends like this:
I suspect this is because Octave traps the segfault itself?
How can I debug this further?
- Text when octave crashes (no gdb):
|