bugGNU Octave - Bugs: bug #48219, Crash at end of execution of...

 
 

bug #48219: Crash at end of execution of openEMS script

Submitter:  John <jcoppens>
Submitted:  Tue 14 Jun 2016 03:42:36 AM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  3 - Low Item Group:  Segfault, Bus Error, etc.
Status:  Need Info Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.0.2 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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.

Rik <rik5>
Group administrator
Sun 27 Aug 2017 04:46:33 PM UTC, comment #10: 

Any progress?

Mike Miller <mtmiller>
Group Member
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.

Mike Miller <mtmiller>
Group Member
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.

John <jcoppens>
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?

Mike Miller <mtmiller>
Group Member
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?

Lachlan Andrew <lachlan>
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:


plot( freq/1e6, real(Zin), 'k-', 'Linewidth', 2 );


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)

John <jcoppens>
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


graphics_toolkit gnuplot


Does the simulation get farther with this change?

Rik <rik5>
Group administrator
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


FDTD = InitFDTD('NrTS', 100000, 'EndCriteria', 1e-1);       % Set to 1e-4 !!!


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:


idx = find (strcmp (get (hax, "tag"), "scribeoverlay"));
if (idx == 1)
  hover = hax (idx);
  do_restack = true;
endif;
## Create an axes object.
htmp = __go_axes__ (cf, varargin {:});
panic: Segmentation fault -- stopping myself...
octave-gui: malloc.c:2370: sysmalloc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *(sizeof(size_t))) - 1)) & ~((2 *(sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long) old_end & pagemask) == 0)' failed.
panic: attempted clean up apparently failed -- aborting...
*** Error in `/usr/libexec/octave/4.0.2/exec/x86_64-unknown-linux-gnu/octave-gui': realloc(): invalid pointer: 0x00007fffc096c6c0 ***
panic: attempted clean up apparently failed -- aborting...
*** Error in `/usr/libexec/octave/4.0.2/exec/x86_64-unknown-linux-gnu/octave-gui': realloc(): invalid pointer: 0x00007fffc096c520 ***
panic: attempted clean up apparently failed -- aborting...
*** Error in `/usr/libexec/octave/4.0.2/exec/x86_64-unknown-linux-gnu/octave-gui': realloc(): invalid pointer: 0x00007fffc096c380 ***
panic: attempted clean up apparently failed -- aborting...
octave exited with signal 6
[Inferior 1 (process 28371) exited normally]




(file #37474)

John <jcoppens>
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.

Rik <rik5>
Group administrator
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


echo on all


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"?


Lachlan Andrew <lachlan>
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:


[@     1m45s] Timestep:          679 || Speed:   91.1 MC/s (1.536e-01 s/TS) || Energy: ~2.98e-17 (- 9.76dB)
[@     1m49s] Timestep:          705 || Speed:   90.6 MC/s (1.545e-01 s/TS) || Energy: ~2.75e-17 (-10.11dB)
Time for 705 iterations with 13997521.00 cells : 109.61 sec
Speed: 90.03 MCells/s
panic: Segmentation fault -- stopping myself...
octave exited with signal 11
[Inferior 1 (process 11914) exited normally]
(gdb) bt
No stack.


I suspect this is because Octave traps the segfault itself?

How can I debug this further?

** Text when octave crashes (no gdb):


...
[@     1m44s] Timestep:          676 || Speed:   90.9 MC/s (1.541e-01 s/TS) || Energy: ~3.00e-17 (- 9.76dB)
[@     1m48s] Timestep:          702 || Speed:   90.7 MC/s (1.543e-01 s/TS) || Energy: ~2.78e-17 (-10.09dB)
Time for 702 iterations with 13997521.00 cells : 108.65 sec
Speed: 90.44 MCells/s
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
*** Error in `panic: attempted clean up apparently failed -- aborting...
/usr/libexec/octave/4.0.2/exec/x86_64-unknown-linux-gnu/octave-gui*** Error in `': malloc(): smallbin double linked list corrupted: 0x00007fa7249675a0 ***
/usr/libexec/octave/4.0.2/exec/x86_64-unknown-linux-gnu/octave-gui': realloc(): invalid pointer: 0x00007fa72496bfa0 ***
panic: attempted clean up apparently failed -- aborting...
*** Error in `/usr/libexec/octave/4.0.2/exec/x86_64-unknown-linux-gnu/octave-gui': realloc(): invalid pointerpanic: attempted clean up apparently failed -- aborting...
panic: attempted clean up apparently failed -- aborting...
*** Error in `/usr/libexec/octave/4.0.2/exec/x86_64-unknown-linux-gnu/octave-gui': *** Error in `/usr/libexec/octave/4.0.2/exec/x86_64-unknown-linux-gnu/octave-guirealloc(): invalid pointer: 0x00007fa72496c140 ***
: 0x00007fa72496be00 ***
': realloc(): invalid pointer: 0x00007fa72496bc60 ***
panic: attempted clean up apparently failed -- aborting...
*** Error in `/usr/libexec/octave/4.0.2/exec/x86_64-unknown-linux-gnu/octave-gui': realloc(): invalid pointer: 0x00007fa72496bac0 ***
save to 'octave-workspace' complete
octave exited with signal 11


John <jcoppens>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #37483:  debug.m.bz2 added by jcoppens (2KiB - application/octet-stream)
file #37474:  crash_log.gz added by jcoppens (3KiB - application/gzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by lachlan (Posted a comment)
  • -email is unavailable- added by jcoppens (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-11-10 rik5 Open/ClosedOpen Closed
    2016-11-18 mtmiller CategoryNone Plotting
    2016-06-16 mtmiller Priority5 - Normal 3 - Low
        StatusNone Need Info
    2016-06-15 jcoppens Attached File- Added debug.m.bz2, #37483
    2016-06-14 rik5 CategoryGUI None
    2016-06-14 jcoppens Attached File- Added crash_log.gz, #37474

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code