Re: Syck CVS (was Re: [bug] [yaml] YAML.load([1,2,3].to_yaml.to_yaml))

>>>>> "w" == why the lucky stiff <[e-mail]> writes:

w> Have you found the bug?  I can't even reproduce it.  I'm now setting up
w> Linux on a machine to test.

  2298          {   if ( YYTOKEN == YYLINEPTR )
  2299                          {
  2300                              if ( blockType == BLOCK_FOLD )
  2301                              {
  2302                                  qidx -= 1;
  2303                              }
  2304                              QUOTECAT(qstr, qcapa, qidx, '\n');
  2305                              POP_LEVEL();
  2306                              YYCURSOR = YYTOKEN;
  2307                              RETURN_YAML_BLOCK();
  2308                          }

 If blockType == BLOCK_FOLD and qidx == 0 (which is this special case) it
 will make (in QUOTECAT)

   qstr[-1] = '\n';

 This can corrupt the memory pool (qstr is malloced) and this is why it
 crash when free() is called


 Now, syck can emit this

svg% ruby -ryaml -e 'puts "---\n...\n".to_yaml'
--- >
---

...

svg% 

 This is valid in YAML for a String object ?

 Finally, for the other bug [ruby-talk:100706]

#14 0x0806a996 in rb_gc () at gc.c:1328
#15 0x08069861 in rb_newobj () at gc.c:386
#16 0x0806b8a2 in hash_alloc (klass=0) at hash.c:183
#17 0x0806b901 in rb_hash_new () at hash.c:195
#18 0x400b4921 in syck_parser_new (argc=0, argv=0x0, class=1074314424)
    at rubyext.c:772

 The GC is called when syck_parser_new() is not finished

 in syck_new_parser(), root is not set to zero.

 When the GC will find pobj on the stack, it will call syck_mark_parser()
 which call rb_gc_mark(parser->root);

 At this step, you can't predict what ruby will do :
   * segfault,
   * unknown object
   * infinite loop
   * ...



Guy Decoux