<rdar://problem/13878726>

This changes the setting target.load-script-from-symbol-file to be a ternary enum value:
default (the default value) will NOT load the script files but will issue a warning suggesting workarounds
yes will load the script files
no will not load the script files AND will NOT issue any warning

if you change the setting value from default to yes, that will then cause the script files to be loaded
(the assumption is you didn't know about the setting, got a warning, and quickly want to remedy it)

if you have a settings set command for this in your lldbinit file, be sure to change "true" or "false" into an appropriate "yes" or "no" value

llvm-svn: 182323

1 files changed, 8 insertions, 1 deletions

diff --git a/lldb/source/Commands/CommandObjectSettings.cpp b/lldb/source/Commands/CommandObjectSettings.cpp
index cafb05550f2..95cc9b68a8f 100644
--- a/lldb/source/Commands/CommandObjectSettings.cpp
+++ b/lldb/source/Commands/CommandObjectSettings.cpp
@@ -255,7 +255,14 @@ protected:
         
         if (error.Success())
         {
-            error = m_interpreter.GetDebugger().SetPropertyValue (&m_exe_ctx,
+            // FIXME this is the same issue as the one in commands script import
+            // we could be setting target.load-script-from-symbol-file which would cause
+            // Python scripts to be loaded, which could run LLDB commands
+            // (e.g. settings set target.process.python-os-plugin-path) and cause a crash
+            // if we did not clear the command's exe_ctx first
+            ExecutionContext exe_ctx(m_exe_ctx);
+            m_exe_ctx.Clear();
+            error = m_interpreter.GetDebugger().SetPropertyValue (&exe_ctx,
                                                                   eVarSetOperationAssign,
                                                                   var_name,
                                                                   var_value_cstr);