# HG changeset patch
# User John W. Eaton <jwe@octave.org>
# Date 1346166053 14400
# Node ID c16357c4bdbb488e87ee1839170c8d1526db95b6
# Parent  b241e69306a5ba4b3f44d490ac1db31d4658c07a
attempt to display location of out of memory errors in interpreted code

* pt-eval.cc (tree_evaluator::visit_statement):
Handle std::bad_alloc exception here.
* toplev.cc (main_loop): Simplify out-of-memory error message.
* octave.cc (safe_source_file): Don't handle std::bad_alloc here.
(execute_eval_option_code): Likewise.
* ov-oncleanup.cc (octave_oncleanup::~octave_oncleanup): Likewise.

diff -r b241e69306a5 -r c16357c4bdbb libinterp/interpfcn/toplev.cc
--- a/libinterp/interpfcn/toplev.cc	Tue Aug 28 09:42:48 2012 -0400
+++ b/libinterp/interpfcn/toplev.cc	Tue Aug 28 11:00:53 2012 -0400
@@ -653,7 +653,7 @@
         {
           recover_from_exception ();
           std::cerr
-            << "error: memory exhausted or requested size too large for range of Octave's index type -- trying to return to prompt"
+            << "error: out of memory -- trying to return to prompt"
             << std::endl;
         }
     }
diff -r b241e69306a5 -r c16357c4bdbb libinterp/octave-value/ov-oncleanup.cc
--- a/libinterp/octave-value/ov-oncleanup.cc	Tue Aug 28 09:42:48 2012 -0400
+++ b/libinterp/octave-value/ov-oncleanup.cc	Tue Aug 28 11:00:53 2012 -0400
@@ -92,11 +92,6 @@
       // Swallow the interrupt.
       warning ("onCleanup: interrupt occured in cleanup action");
     }
-  catch (std::bad_alloc)
-    {
-      // Swallow the exception.
-      warning ("onCleanup: out of memory occured in cleanup action");
-    }
   catch (...) // Yes, the black hole. We're in a d-tor.
     {
       // This shouldn't happen, in theory.
diff -r b241e69306a5 -r c16357c4bdbb libinterp/octave.cc
--- a/libinterp/octave.cc	Tue Aug 28 09:42:48 2012 -0400
+++ b/libinterp/octave.cc	Tue Aug 28 11:00:53 2012 -0400
@@ -379,14 +379,6 @@
       recover_from_exception ();
       gripe_safe_source_exception (file_name, "unhandled execution exception");
     }
-  catch (std::bad_alloc)
-    {
-      recover_from_exception ();
-      error_state = -2;
-      gripe_safe_source_exception
-        (file_name,
-         "memory exhausted or requested size too large for range of Octave's index type");
-    }
 }
 
 // Initialize by reading startup files.
@@ -507,12 +499,6 @@
       std::cerr << "error: unhandled execution exception -- eval failed"
                 << std::endl;
     }
-  catch (std::bad_alloc)
-    {
-      error_state = -2;
-      std::cerr << "error: memory exhausted or requested size too large for range of Octave's index type -- eval failed"
-                << std::endl;
-    }
 
   return parse_status;
 }
diff -r b241e69306a5 -r c16357c4bdbb libinterp/parse-tree/pt-eval.cc
--- a/libinterp/parse-tree/pt-eval.cc	Tue Aug 28 09:42:48 2012 -0400
+++ b/libinterp/parse-tree/pt-eval.cc	Tue Aug 28 11:00:53 2012 -0400
@@ -757,6 +757,19 @@
         {
           gripe_library_execution_error ();
         }
+      catch (std::bad_alloc)
+        {
+          // FIXME -- We want to use error_with_id here so that we set
+          // the error state, give users control over this error
+          // message, and so that we set the error_state appropriately
+          // so we'll get stack trace info when appropriate.  But
+          // error_with_id will require some memory allocations.  Is
+          // there anything we can do to make those more likely to
+          // succeed?
+
+          error_with_id ("Octave:bad-alloc",
+                         "out of memory or dimension too large for Octave's index type");
+        }
     }
 }
 
@@ -897,7 +910,6 @@
   if (try_code)
     {
       try_code->accept (*this);
-      // FIXME: should std::bad_alloc be handled here?
     }
 
   if (error_state)