The test script causes gnuplot to crash.  Octave doesn't know that's happened, so it continues on.  In _gnuplot_draw_axes_, there is a call to

  gnuplot_term = __gnuplot_get_var__ (axis_obj.parent, "GPVAL_TERM");

In _gnuplot_get_var_, Octave creates a fifo file and sends a request to gnuplot that is never answered.

I'm not sure how to detect this situation and work around it.  The development version of Octave is not responding to Ctrl-C in this case because it is stuck in a system call:

#0  0x00007ffff47134bd in open64 () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ffff46ab293 in __GI__IO_file_open (fp=fp@entry=0x555556c59a00, filename=<optimized out>, posix_mode=<optimized out>, prot=prot@entry=438, read_write=8, is32not64=is32not64@entry=1)
    at fileops.c:229
#2  0x00007ffff46ab433 in _IO_new_file_fopen (fp=fp@entry=0x555556c59a00, filename=filename@entry=0x7fffffff8480 "/tmp/oct-YXP99N", mode=<optimized out>, mode@entry=0x7fffffff8460 "rb",
    is32not64=is32not64@entry=1) at fileops.c:336
#3  0x00007ffff469f5b4 in __fopen_internal (filename=0x7fffffff8480 "/tmp/oct-YXP99N", mode=0x7fffffff8460 "rb", is32=1) at iofopen.c:86
#4  0x00007ffff7558725 in do_stream_open (fid=<synthetic pointer>: <optimized out>, arch="native", mode_arg="r", name="/tmp/oct-YXP99N") at /home/jwe/src/octave/libinterp/corefcn/file-io.cc:450
#5  do_stream_open (fcn=0x7ffff7901fe7 "fopen", fid=<synthetic pointer>: <optimized out>, tc_arch=..., tc_mode=..., tc_name=...) at /home/jwe/src/octave/libinterp/corefcn/file-io.cc:476

and the interrupt signal just sets a flag that the interpreter checks.  So we don't break out of the system call.

This is happening here:

stopped in:

  -->     __gnuplot_get_var__ at line 76 [/home/jwe/src/octave/scripts/plot/util/private/__gnuplot_get_var__.m]
        __gnuplot_draw_axes__ at line 38 [/home/jwe/src/octave/scripts/plot/util/private/__gnuplot_draw_axes__.m]
      __gnuplot_draw_figure__ at line 164 [/home/jwe/src/octave/scripts/plot/util/private/__gnuplot_draw_figure__.m]
          __gnuplot_drawnow__ at line 86 [/home/jwe/src/octave/scripts/plot/util/__gnuplot_drawnow__.m]
                        surfc at line 89 [/home/jwe/src/octave/scripts/plot/draw/surfc.m]
                          foo at line 19 [/net/buserror/scratch/jwe/build/octave/foo.m]

Since the test code would probably work if gnuplot didn't fail, and because both the fltk and qt plotting widgets work with this code, I'm lowering the priority to normal.

Confirmed that bug is still present with gnuplot 5.0.1 and the development branch from 8/7/16.

It's probably a bug in gnuplot, but I can't confirm 100%.  In testing with Octave versions 3.2.4, 3.4.3, 3.6.4, and development versions I can always reliably produce a crash.  My version of gnuplot is 4.6.2.

Interestingly, If I vary the final plot I don't get a crash.  I tried a 2-D plot [plot (1:10)], and the other 3-D plots that didn't use plot3 (mesh, surf, surfc).

Also, if I throw a line

subplot(4,2,8);

after the first subplot, just to create the axes, then everything works.