Re: [PATCH 0/5] Conflict Counterexample Generation

[Akim Demaille]

Hi Vincent,

> Le 13 mai 2020 à 19:58, Akim Demaille <address@hidden> a écrit :
> 
> Hi Vincent,
> 
> Once I have fixed the test suite by providing it with the expected values, I 
> can see that we have at least to SEGV: tests 247 and 253.  I will leave this 
> to you, and will be back to work on this tomorrow in the morning (French 
> time).

Here's what I see about this crash:

$ lldb -- ./_build/g9d/src/bison _build/g9d/tests/testsuite.dir/247/input.y 
-Wcou
(lldb) target create "./_build/g9d/src/bison"
Current executable set to './_build/g9d/src/bison' (x86_64).
(lldb) settings set -- target.run-args  
"_build/g9d/tests/testsuite.dir/247/input.y" "-Wcou"
(lldb) r
Process 85840 launched: '/Users/akim/src/gnu/bison/_build/g9d/src/bison' 
(x86_64)
Shift-Reduce Conflict:
4:    3 r: b .
4:    7 s: b . A xx y
On Symbol: A
Example  b  •  A  X  X  Y
First  derivation  a ::=[ r ::=[ b  • ]  t ::=[ A  x ::=[ X ]  xy ::=[ X  Y ] ] 
]
Second derivation  a ::=[ s ::=[ b  •  xx ::=[ A  X  X ]  y ::=[ Y ] ] ]

Shift-Reduce Conflict:
10:    8 x: X .
10:    9 xx: X . X
On Symbol: X
Process 85840 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x0)
    frame #0: 0x000000010000c4ee 
bison`complete_diverging_example(conflict_sym=5, path=0x000000010051ed50, 
derivs=0x0000000100513020) at counterexample.c:287:19
   284      {
   285        state_item *si = (state_item *) gl_list_node_value (path, 
state_node);
   286        item_number *item = si->item;
-> 287        item_number pos = *item;
   288        // symbols after dot
   289        if (gl_list_size (result) == 1 && !item_number_is_rule_number 
(pos)
   290            && gl_list_get_at (result, 0) == derivation_dot() )
Target 0: (bison) stopped.
(lldb) p item
(item_number *) $0 = 0x0000000000000000



The other crash, 253, is related to memory cleaning on time out.  It seems that 
the various structures are not in a sane state, and gnulib's list crash when 
they reclaim memory.

frame #3: 0x0000000100079aec bison`gl_linked_list_free(list=0x0000000147e3e060) 
at gl_anylinked_list2.h:906:7
   903        gl_list_node_t next = node->next;
   904        if (dispose != NULL)
   905          dispose (node->value);
-> 906        free (node);
   907        node = next;
   908      }
   909  #if WITH_HASHTABLE
(lldb) 
frame #4: 0x000000010003e768 bison`gl_list_free(list=0x0000000147e3e060) at 
gl_list.h:799:4
   796  GL_LIST_INLINE void
   797  gl_list_free (gl_list_t list)
   798  {
-> 799    ((const struct gl_list_impl_base *) list)->vtable->list_free (list);
   800  }
   801  
   802  GL_LIST_INLINE gl_list_iterator_t
(lldb) 
frame #5: 0x000000010003f2b2 bison`free_parse_state(ps=0x0000000147e3e000) at 
parse-simulation.c:189:9
   186        (ps->reference_count == 0 && !ps->free_contents_early))
   187      {
   188        if (ps->state_items.contents)
-> 189          gl_list_free (ps->state_items.contents);
   190        if (ps->derivs.contents)
   191          gl_list_free (ps->derivs.contents);
   192        free_parse_state (ps->parent);




Cheers!