From 37f29caf8a75a4eb9d2059814786dad10edb13fc Mon Sep 17 00:00:00 2001
From: Ben Pfaff <blp@cs.stanford.edu>
Date: Sun, 7 Mar 2021 15:42:56 -0800
Subject: [PATCH] DELETE VARIABLES: Fix crash when deleting and adding vars at
 same time.

Thanks to Ricardo Mejias for reporting the problem:
https://lists.gnu.org/archive/html/pspp-users/2021-03/msg00025.html
---
 src/language/dictionary/delete-variables.c    | 43 +++++++++++++++++++
 tests/language/dictionary/delete-variables.at | 19 ++++++++
 2 files changed, 62 insertions(+)

diff --git a/src/language/dictionary/delete-variables.c b/src/language/dictionary/delete-variables.c
index bf6006a86c..ded5c48ad3 100644
--- a/src/language/dictionary/delete-variables.c
+++ b/src/language/dictionary/delete-variables.c
@@ -55,8 +55,51 @@ cmd_delete_variables (struct lexer *lexer, struct dataset *ds)
   ok = proc_commit (ds) && ok;
   if (!ok)
     goto error;
+
   dict_delete_vars (dataset_dict (ds), vars, var_cnt);
 
+  /* XXX A bunch of bugs conspire to make executing transformations again here
+     necessary, even though it shouldn't be.
+
+     Consider the following (which is included in delete-variables.at):
+
+        DATA LIST NOTABLE /s1 TO s2 1-2(A).
+        BEGIN DATA
+        12
+        END DATA.
+        DELETE VARIABLES s1.
+        NUMERIC n1.
+        LIST.
+
+     The DATA LIST gives us a caseproto with widths 1,1.  DELETE VARIABLES
+     deletes the first variable so we now have -1,1.  This already is
+     technically a problem because proc_casereader_read() calls
+     case_unshare_and_resize() from the former to the latter caseproto, and
+     these caseprotos are not conformable (which is a requirement for
+     case_resize()).  It doesn't cause an assert by default because
+     case_resize() uses expensive_assert() to check for it though.  However, in
+     practice we don't see a problem yet because case_resize() only does work
+     if the number of widths in the source and dest caseproto are different.
+
+     Executing NUMERIC adds a third variable, though, so we have -1,1,0.  This
+     makes caseproto_resize() notice that there are fewer strings in the new
+     caseproto.  Therefore it destroys the second one (s2).  It should destroy
+     the first one (s1), but if the caseprotos were really conformable then it
+     would have destroyed the right one.  This mistake eventually causes a bad
+     memory reference.
+
+     Executing transformations a second time after DELETE VARIABLES, like we do
+     below, works around the problem because we can never run into a situation
+     where we've got both new variables (triggering a resize) and deleted
+     variables (triggering the bad free).
+
+     We should fix this in a better way.  Doing it cleanly seems hard.  This
+     seems to work for now. */
+  ok = casereader_destroy (proc_open_filtering (ds, false));
+  ok = proc_commit (ds) && ok;
+  if (!ok)
+    goto error;
+
   free (vars);
 
   return CMD_SUCCESS;
diff --git a/tests/language/dictionary/delete-variables.at b/tests/language/dictionary/delete-variables.at
index 2237df92c4..b4b199987b 100644
--- a/tests/language/dictionary/delete-variables.at
+++ b/tests/language/dictionary/delete-variables.at
@@ -43,3 +43,22 @@ b
 9.00
 ])
 AT_CLEANUP
+
+dnl Checks for regression against a crash reported on pspp-users:
+dnl https://lists.gnu.org/archive/html/pspp-users/2021-03/msg00025.html
+AT_SETUP([DELETE VARIABLES with string variables])
+AT_DATA([delete-variables.sps], [dnl
+DATA LIST NOTABLE /s1 TO s2 1-2(A).
+BEGIN DATA
+12
+END DATA.
+DELETE VARIABLES s1.
+NUMERIC n1.
+LIST.
+])
+AT_CHECK([pspp -O format=csv delete-variables.sps], [0], [dnl
+Table: Data List
+s2,n1
+2,.  @&t@
+])
+AT_CLEANUP
-- 
2.30.2