Re: [PATCH 0/5] Conflict Counterexample Generation

Akim Demaille <[email protected]>
Newsgroups gmane.comp.parsers.bison.patches
Message-ID <[email protected]>
Hi Vincent,

> Le 13 mai 2020 à 19:58, Akim Demaille <[email protected]> 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!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.