Re: assertion failed?

[John Darrington]

I did some investigation and have found the proximate cause can be seen from
this stack trace:


#6  0x00007fac5e6c76cb in case_tmpfile_put_values
    (ctf=0x5595f18b8c30, case_idx=0, start_value=0, values=0x5595ebea6a20, 
n_values=486)
    at /home/john/pspp-master/src/data/case-tmpfile.c:196
#7  0x00007fac5e6c7751 in case_tmpfile_put_case (ctf=0x5595f18b8c30, 
case_idx=0, c=0x5595ebea6a00)
    at /home/john/pspp-master/src/data/case-tmpfile.c:211
#8  0x00007fac5e6c68c7 in casewindow_file_push_head (cwf_=0x5595f18b9b80, 
c=0x5595ebea6a00)
    at /home/john/pspp-master/src/data/casewindow.c:314
#9  0x00007fac5e6c63f1 in casewindow_push_head (cw=0x5595f18bb030, 
c=0x5595ebea6a00)
    at /home/john/pspp-master/src/data/casewindow.c:143
#10 0x00007fac5e6c635c in casewindow_to_disk (old=0x5595ec079640)
    at /home/john/pspp-master/src/data/casewindow.c:130
#11 0x00007fac5e6c644f in casewindow_push_head (cw=0x5595ec079640, 
c=0x5595f18b5100)
    at /home/john/pspp-master/src/data/casewindow.c:149
#12 0x00007fac5e6c6fa1 in casewriter_window_write (writer=0x5595ebe2e2d0, 
window_=0x5595ec079640, c=0x5595f18b5100)
    at /home/john/pspp-master/src/data/casewriter.c:236
#13 0x00007fac5e6c6c9c in casewriter_write (writer=0x5595ebe2e2d0, 
c=0x5595f18b5100)
    at /home/john/pspp-master/src/data/casewriter.c:57
#14 0x00007fac5e6ced82 in proc_casereader_read (reader=0x5595ec229170, 
ds_=0x5595ebe2e0a0)
    at /home/john/pspp-master/src/data/dataset.c:547
#15 0x00007fac5e6c5385 in casereader_read (reader=0x5595ec229170)
    at /home/john/pspp-master/src/data/casereader.c:71
#16 0x00007fac5e6cee21 in proc_casereader_destroy (reader=0x5595ec229170, 
ds_=0x5595ebe2e0a0)
    at /home/john/pspp-master/src/data/dataset.c:578
#17 0x00007fac5e6c5425 in casereader_destroy (reader=0x5595ec229170)
    at /home/john/pspp-master/src/data/casereader.c:94
#18 0x00007fac5e6c4318 in casereader_shim_destroy (reader=0x5595ebeae8f0, 
s_=0x5595ec0c7440)
    at /home/john/pspp-master/src/data/casereader-shim.c:123
#19 0x00007fac5e6c5d1b in random_reader_destroy (reader=0x5595ebeae8f0, 
br_=0x5595ec2191e0)
    at /home/john/pspp-master/src/data/casereader.c:536
#20 0x00007fac5e6c5425 in casereader_destroy (reader=0x5595ebeae8f0)
    at /home/john/pspp-master/src/data/casereader.c:94
#21 0x00007fac5e83c967 in cmd_execute (lexer=0x5595ec332370, ds=0x5595ebe2e0a0)


In particular looking at frame 6, case-tmpfile.c (case_tmpfile_put_values)

    int width = caseproto_get_width (ctf->proto, i);
    if (width != -1
          && !ext_array_write (ctf->ext_array, case_offset + ctf->offsets[i],
                               width_to_n_bytes (width),
                               value_to_data (values++, width)))

The value of "width" is 1 (the old value of the variable's width) whereas it
ought to be 0 (the new value).

The caseproto should hold the correct value, because when the variable's type is
changed, there is a callback in psppire-datastore.c 
(variable_changed_callback); the
relevant code is:

{
      int posn = var_get_case_index (variable);
      struct resize_datum_aux aux;
      aux.old_variable = oldvar;
      aux.new_variable = variable;
      aux.dict = store->dict->dict;
      datasheet_resize_column (store->datasheet, posn, var_get_width (variable),
                               resize_datum, &aux);
}

and resize_datum is defined as :


static void
resize_datum (const union value *old, union value *new, const void *aux_)
{
  const struct resize_datum_aux *aux = aux_;
  int new_width = var_get_width (aux->new_variable);
  const char *enc = dict_get_encoding (aux->dict);
  const struct fmt_spec *newfmt = var_get_print_format (aux->new_variable);
  char *s = data_out (old, enc, var_get_print_format (aux->old_variable));
  enum fmt_type type = (fmt_usable_for_input (newfmt->type)
                        ? newfmt->type
                        : FMT_DOLLAR);
  free (data_in (ss_cstr (s), enc, type, new, new_width, enc));
  free (s);
}

Now I have checked, and this callback is indeed getting called as I would 
expect.
So I don't understand why the caseproto (which I think comes from a writer) 
seems
to refer to the old, unmodified dataset.

Is the call to datasheet_resize_column sufficient? Or is there something more I
need to do?

J'




On Sat, Jun 27, 2020 at 08:14:59PM +0200, John Darrington wrote:
     
     But I can condfirm that it is reproducible in GNU/Linux, and it's
     somewhat suprising to me.
     
     I will investigate further to see if I can find out what is going on.
     
     J'
     
     
     On Fri, Jan 10, 2020 at 11:37:15AM -0800, Ben Pfaff wrote:
          Looking at the code a little bit, I couldn't quickly find anything 
that properly
          implements changing a variable from numeric to string or vice versa.
          
          John, do you know whether the GUI is supposed to support that? If not,
          then we should either implement it or disable it.
          
          On Wed, Jan 8, 2020 at 7:12 PM Alan Mead <amead@alanmead.org> wrote:
          >
          > I was showing my son how to use PSPP to analyze some survey data 
and I
          > crashed PSPP. I'm using GNU pspp 1.2.0-g0fb4db on Windows 7 (yeah, I
          > know). This happens reliably for me. A mingw window pops up saying 
an
          > assertion failed:
          >
          >
          >
          > The text reads:
          >
          > Assertion failed!
          >
          > Program: C:\Program Files\PSPP\bin\PSPPIRE.exe
          > File: src/data/case.c, Line 476
          >
          > Expression: caseproto_get_width(c->proto, case_idx) == 
var_get_width(v)
          >
          > Steps to replicate:
          >
          > *Step 1.* Download this SPSS system file of survey data:
          > 
https://faunalytics.org/wp-content/uploads/2017/04/Faunalytics-Current-Former-Veg-Study-Dataset-All-Respondents-Original-Variables.sav
          > (Described on this page:
          > 
https://faunalytics.org/dataset-study-of-current-and-former-vegetarians-and-vegans/)
          >
          > *Step 2: *Find VEG_RECIDIVISTS_1_SQ001 in the data editor variable 
view
          > (row 66) and change the Type to numeric (leave the default %2.0f)
          >
          > *Step 3:* Open a new syntax file (File > New > Syntax) and paste 
these
          > two FREQ routines
          >
          > FREQUENCIES
          >     /VARIABLES= VEG_RECIDIVISTS_1_SQ001 to VEG_RECIDIVISTS_1_SQ010
          >     /FORMAT=AVALUE TABLE.
          >
          > FREQUENCIES
          >     /VARIABLES= VEGAN_RECIDIVISTS_1_SQ001 to 
VEGAN_RECIDIVISTS_1_SQ010
          >     /FORMAT=AVALUE TABLE.
          >
          > *Step 4:* Run this syntax twice (Run > all, then Run > all again). 
The
          > assertion pops and PSPPIRE closes when you select Abort.
          >
          > If you omit Step 2, it doesn't seem to occur, so I guess there's 
some
          > issue changing the type. (I know, BTW, that changing the type is a 
bad
          > idea because it forces all the data in that variable to be missing.)
          >
          > -Alan
          >
          > --
          >
          > Alan D. Mead, Ph.D.
          > President, Talent Algorithms Inc.
          >
          > science + technology = better workers
          >
          > http://www.alanmead.org
          >
          >
          > A lie can travel half way around the world while the truth is
          > putting on its shoes.
          >
          > -- Mark Twain
          >
          >

signature.asc
Description: PGP signature