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:
yaml.constructor.ConstructorError: could not determine a constructor for the tag 'tag:yaml.org,2002:perl/hash:Jifty::Result'
in "<string>", line 2, column 8:
fnord: !!perl/hash:Jifty::Result