durusmail: quixote-users: ptl core dump
ptl core dump
2001-11-06
2001-11-07
2001-11-07
ptl core dump
Greg Ward
2001-11-07
On 06 November 2001, Quinn Dunkan said:
> % cat >t.ptl
> a = [0,1]
> del a[0], a[1]

OK, here's another take on this problem.  No core dump this time, but it
still smells like a PTL bug.

  $ cat t.py
  def foo ():
      a = [0, 1]
      del a[0], a[0]
  $ python
  Python 2.1.1 (#5, Oct 26 2001, 17:50:23)
  [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
  Type "copyright", "credits" or "license" for more information.
  >>> import t
  >>> print t
  
  >>> t.foo()

  $ mv t.py t.ptl
  $ python
  Python 2.1.1 (#5, Oct 26 2001, 17:50:23)
  [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
  Type "copyright", "credits" or "license" for more information.
  >>> import quixote
  >>> quixote.enable_ptl()
  >>> import t
  >>> print t
  
  >>> t.foo()
  Traceback (most recent call last):
    File "", line 1, in ?
    File "t.ptl", line 3, in foo
      del a[0], a[0]
  TypeError: object does not support item deletion

(That's the exception you get when you try to delete an item from a
tuple.)  This code should act the same in PTL or Python, shouldn't it?

Anyways, since the odd behaviour is now coming from a function, I know
how to disassemble it.  (BTW, can anyone tell me how to disassemble a
.pyc file?)

Here are the two versions of t.foo; on the left from t.py, on the right
from t.ptl.

  0 SET_LINENO           1             0 SET_LINENO          1

  3 SET_LINENO           2             3 SET_LINENO          2
  6 LOAD_CONST           1 (0)         6 LOAD_CONST          1 (0)
  9 LOAD_CONST           2 (1)         9 LOAD_CONST          2 (1)
 12 BUILD_LIST           2            12 BUILD_LIST          2
 15 STORE_FAST           0 (a)        15 STORE_FAST          0 (a)
                                      18 UNPACK_SEQUENCE     2
 18 SET_LINENO           3
 21 LOAD_FAST            0 (a)        21 SET_LINENO          3
 24 LOAD_CONST           1 (0)        24 LOAD_FAST           0 (a)
 27 DELETE_SUBSCR                     27 LOAD_CONST          1 (0)
 28 LOAD_FAST            0 (a)        30 DELETE_SUBSCR
 31 LOAD_CONST           1 (0)        31 LOAD_FAST           0 (a)
 34 DELETE_SUBSCR                     34 LOAD_CONST          1 (0)
 35 LOAD_CONST           0 (None)     37 DELETE_SUBSCR
 38 RETURN_VALUE                      38 LOAD_CONST          0 (None)
                                      41 RETURN_VALUE

Looks like the only difference is the UNPACK_SEQUENCE opcode in the PTL
version.  I can see why that would cause problems, but I don't
understand precisely what's happening.  Nor do I understand why
ptl_compile put that bytecode in!  Neil?

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org


reply