changeset 15245:c16357c4bdbb

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.
author John W. Eaton <jwe@octave.org>
date Tue, 28 Aug 2012 11:00:53 -0400
parents b241e69306a5
children 4c0cef65c55f
files libinterp/interpfcn/toplev.cc libinterp/octave-value/ov-oncleanup.cc libinterp/octave.cc libinterp/parse-tree/pt-eval.cc
diffstat 4 files changed, 14 insertions(+), 21 deletions(-) [+]
line wrap: on
line diff
--- a/libinterp/interpfcn/toplev.cc
+++ b/libinterp/interpfcn/toplev.cc
@@ -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;
         }
     }
--- a/libinterp/octave-value/ov-oncleanup.cc
+++ b/libinterp/octave-value/ov-oncleanup.cc
@@ -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.
--- a/libinterp/octave.cc
+++ b/libinterp/octave.cc
@@ -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;
 }
--- a/libinterp/parse-tree/pt-eval.cc
+++ b/libinterp/parse-tree/pt-eval.cc
@@ -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)