hm: Sat Oct 14 05:03:00 2006

Sat Oct 14 05:03:00 2006

Yay, jesse added 

depended_on_by_count: 2
depended_on_by_ids: 38157   38158
depended_on_by_summaries: move thok email   move swat email

Sadly, syck falls apart; use ctypes instead? Sadly, libsyck0-dev only provides a static lib; the only dynamic lib is the one that is already the parser. electric fence doesn't catch anything either.

Rebuilding syck.so with debugging (after purging the PHP references from the build :-) and installing python-dbg, and running "./todo.py listid 7AM" to test the bad bit of code got this:

#0  0x00000000 in ?? ()
#1  0xb7cb5e83 in syck_hdlr_get_anchor (p=0x82217c0, a=0x81fcb18 "1") at handler.c:108
   108                      n = (p->bad_anchor_handler)( p, a );

#2  0xb7cb14d0 in syckparse (parser=0x82217c0) at gram.y:192
#3  0xb7cafacd in syck_parse (p=0x82217c0) at syck.c:497
#4  0xb7cadf81 in py_syck_load (self=0x0, args=0x0) at pyext.c:397
#5  0x080b63c7 in PyEval_EvalFrame (f=0x81c0a2c) at ../Python/ceval.c:3563
#6  0x080b713b in PyEval_EvalFrame (f=0x81f8d44) at ../Python/ceval.c:3645
#7  0x080b713b in PyEval_EvalFrame (f=0x815cac4) at ../Python/ceval.c:3645
#8  0x080b781f in PyEval_EvalCodeEx (co=0xb7cf78a0, globals=0xb7d58824, locals=0x0, args=0xb7cc7318, argcount=2, kws=0x0, kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2736
#9  0x080fc13d in function_call (func=0xb7acf72c, arg=0xb7cc730c, kw=0x0) at ../Objects/funcobject.c:548
#10 0x0805946c in PyObject_Call (func=0x81f9cf8, arg=0x0, kw=0x0) at ../Objects/abstract.c:1795
#11 0x080b4bba in PyEval_EvalFrame (f=0x81d5d74) at ../Python/ceval.c:3840
#12 0x080b713b in PyEval_EvalFrame (f=0x8142f0c) at ../Python/ceval.c:3645
#13 0x080b781f in PyEval_EvalCodeEx (co=0xb7cf7a20, globals=0xb7d58824, locals=0xb7d58824, args=0x0, argcount=0, kws=0x0, kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2736
#14 0x080b7a65 in PyEval_EvalCode (co=0x0, globals=0x0, locals=0x0) at ../Python/ceval.c:484
#15 0x080d95cc in PyRun_FileExFlags (fp=0x813e008, filename=0xbfe1bcf4 "./todo.py", start=0, globals=0x0, locals=0x0, closeit=1, 
    flags=0xbfe1ba34) at ../Python/pythonrun.c:1265
#16 0x080d986c in PyRun_SimpleFileExFlags (fp=<value optimized out>, filename=0xbfe1bcf4 "./todo.py", closeit=1, flags=0xbfe1ba34)
    at ../Python/pythonrun.c:860
#17 0x08055b33 in Py_Main (argc=3, argv=0xbfe1bad4) at ../Modules/main.c:493
#18 0xb7d95ea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#19 0x08054fa1 in _start () at ../sysdeps/i386/elf/start.S:119

and there simply is no bad_anchor_handler, so it all catches fire.

Oddly, setting up the handler:

syck_parser_bad_anchor_handler( parser, py_syck_error_handler); /* [eichin:20061014T0538-04] */

just changes the quality of the traceback - we don't get to see the error because it goes is screwing up the cleanup too...

#0  0xb7e88309 in free () from /lib/tls/i686/cmov/libc.so.6
#1  0xb7d5299f in syck_free_node (n=0xb7b719dc) at node.c:39
#2  0xb7d5338d in syck_st_free_nodes (key=0x81fcb18 "88··°Ë\037\b\020", n=0xb7f51304, arg=0x0) at syck.c:206
#3  0xb7d54430 in st_foreach (table=0x81f9cf8, func=0xb7d5336b <syck_st_free_nodes>, arg=0x0) at syck_st.c:495
#4  0xb7d533ff in syck_st_free (p=0x82217c0) at syck.c:226
#5  0xb7d53601 in syck_free_parser (p=0x82217c0) at syck.c:247
#6  0xb7d51fc0 in py_syck_load (self=0x0, args=0xb7f51304) at pyext.c:406

Adding a forced print, and then looking at the given line and offset, it turns out not to handle *1 syntax -- force-replacing it out causes the parse to succeed...

print syck.load(res.replace('        _current_user: *1',''))

Will complain and try and work around it... but upstream (rubyforge CVS) stopped at 0.55, and http://code.whytheluckystiff.net/svn/syck/trunk/ext/ is notably missing the python branch...

http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=python-syck;dist=unstable

lists this bug -- with no analysis, but a good short test case:

python ./syck-deb-293251.py
py_syck_error_handler: 2, 5, b['stuff', 'stuff']
Exception exceptions.TypeError: (2, 5, 'b') in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage collection
Aborted

among a set of 500-day-old bugs from possibly the only person to try it, and a reference to a better implementation:

This at least doesn't crash (it can't using the pure python version, but there's pyrex to call libyaml... wonder if that should use ctypes) but it isn't compatible in other ways:

  in "<string>", line 2, column 8:
    fnord: !!perl/hash:Jifty::Result
PrevUpNext