From tracker at bugs.pypy.org  Thu Jan  2 23:51:09 2014
From: tracker at bugs.pypy.org (Simon Sapin)
Date: Thu, 02 Jan 2014 22:51:09 +0000
Subject: [pypy-issue] [issue1666] Calling lots of lambdas is slow
In-Reply-To: <1388703069.72.0.643467565728.issue1666@bugs.pypy.org>
Message-ID: <1388703069.72.0.643467565728.issue1666@bugs.pypy.org>


New submission from Simon Sapin <simon.sapin at kozea.fr>:

The program I?m working on "compiles" CSS selectors to boolean expressions in
Python code, creates lambdas with `eval('lambda element: ' + expression)`, and
calls them each on every HTML element of a document.

The last step is about 6 times slower on PyPy than CPython. Alex Gaynor says on
IRC that this sounds like the "chain of guards" issue.

The loops being timed are:

https://github.com/SimonSapin/cssselect2/blob/006f19f203/example.py#L38
https://github.com/SimonSapin/cssselect2/blob/006f19f203/cssselect2/__init__.py#L63

where `test` is a lambda.


To reproduce:

    pip install html5lib tinycss2  # In a virtualenv or something
    git clone https://github.com/SimonSapin/cssselect2.git
    cd cssselect2
    git checkout 006f19f20305f5d42173c6a7d063d273c1263058
    python example.py

The output is the number of selectors (and lambdas), then the results from
`timeit.repeat`. On my Linux x64 machine, with CPython 2.7.6:

368
1.351
1.337
1.344

With PyPy 2.2.1:

368
17.077
13.098
10.307

Still on PyPy, adding `repeat=10` to the `timeit.repeat` call to give the JIT
more warm-up time:

368
16.708
13.201
10.273
9.874
9.537
9.409
9.509
9.306
9.365
9.166

----------
messages: 6448
nosy: SimonSapin, pypy-issue
priority: performance bug
status: unread
title: Calling lots of lambdas is slow

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1666>
________________________________________

From tracker at bugs.pypy.org  Fri Jan  3 09:23:00 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 03 Jan 2014 08:23:00 +0000
Subject: [pypy-issue] [issue1666] Calling lots of lambdas is slow
In-Reply-To: <1388703069.72.0.643467565728.issue1666@bugs.pypy.org>
Message-ID: <1388737380.67.0.59003409699.issue1666@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

The "chain of guards" issue being referred to is, I believe:
https://bugs.pypy.org/issue1565

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1666>
________________________________________

From tracker at bugs.pypy.org  Fri Jan  3 10:47:45 2014
From: tracker at bugs.pypy.org (Simon Sapin)
Date: Fri, 03 Jan 2014 09:47:45 +0000
Subject: [pypy-issue] [issue1666] Calling lots of lambdas is slow
In-Reply-To: <1388703069.72.0.643467565728.issue1666@bugs.pypy.org>
Message-ID: <1388742465.36.0.501203365019.issue1666@bugs.pypy.org>


Simon Sapin <simon.sapin at kozea.fr> added the comment:

For what it?s worth, with `--jit off`:

368
3.270
3.229
3.225

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1666>
________________________________________

From tracker at bugs.pypy.org  Fri Jan  3 17:11:07 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 03 Jan 2014 16:11:07 +0000
Subject: [pypy-issue] [issue1666] Calling lots of lambdas is slow
In-Reply-To: <1388703069.72.0.643467565728.issue1666@bugs.pypy.org>
Message-ID: <1388765467.85.0.405881283191.issue1666@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Yes, this means it is a duplicate issue.  I'm keeping it open so that we
remember to test this example too after we fix it.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1666>
________________________________________

From tracker at bugs.pypy.org  Fri Jan  3 18:18:15 2014
From: tracker at bugs.pypy.org (ita)
Date: Fri, 03 Jan 2014 17:18:15 +0000
Subject: [pypy-issue] [issue1667] py3k: invalid encoding validation
In-Reply-To: <1388769495.45.0.68764196333.issue1667@bugs.pypy.org>
Message-ID: <1388769495.45.0.68764196333.issue1667@bugs.pypy.org>


New submission from ita <tnagy1024 at gmail.com>:

Consider the following file, containing a null byte on a *commented* line:

$ echo -e "#\!/usr/bin/env python\n# encoding: ISO8859-1\nprint('ok')\n#\x00" > x.py

It works in cpython 2 and 3 (and in jython and in ironpython)
$ python2 x.py
ok
young at yang:~$ python3 x.py 
ok

It also works in pypy 2 as expected:
$ ~/Downloads/pypy-2.2.1-linux64/bin/pypy x.py 
ok

But pypy3 refuses to run it:

$ ~/pypy3-2.1-beta1-linux64/bin/pypy x.py 
TypeError: argument must be a string without NUL characters

----------
messages: 6452
nosy: ita, pypy-issue
priority: bug
status: unread
title: py3k: invalid encoding validation

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1667>
________________________________________

From tracker at bugs.pypy.org  Fri Jan  3 18:26:22 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 03 Jan 2014 17:26:22 +0000
Subject: [pypy-issue] [issue1667] py3k: invalid encoding validation
In-Reply-To: <1388769495.45.0.68764196333.issue1667@bugs.pypy.org>
Message-ID: <1388769982.94.0.973215451594.issue1667@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

exec and eval() have the reverse issue when comparing CPython 2.x (first) with
PyPy 2.x (last):

>>> eval("5 #\x00")
TypeError: expected string without null bytes

>>>> eval("5 #\x00")
5

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1667>
________________________________________

From tracker at bugs.pypy.org  Mon Jan  6 11:12:49 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 06 Jan 2014 10:12:49 +0000
Subject: [pypy-issue] [issue1667] py3k: invalid encoding validation
In-Reply-To: <1388769495.45.0.68764196333.issue1667@bugs.pypy.org>
Message-ID: <1389003169.86.0.716017996137.issue1667@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

The fact that it works on PyPy 2 is accidental, because \x00 is not a special
character in RPython, unlike C.  In CPython 2, it doesn't actually really work
as expected: you get nonsense, as explained in http://bugs.python.org/issue20115
, if your "#\x00" line is followed by a line of non-commented-out code.

CPython will likely fix the problem in 3.4 or 3.5 by banning NUL bytes.  I think
it would be a sane choice, and I don't think we should try to reproduce the
current buggy behavior.  I'm fine with closing this as: "it's actually a CPython
bug, reported".

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1667>
________________________________________

From tracker at bugs.pypy.org  Mon Jan  6 14:06:28 2014
From: tracker at bugs.pypy.org (mattip)
Date: Mon, 06 Jan 2014 13:06:28 +0000
Subject: [pypy-issue] [issue1429] CSV module is slow
In-Reply-To: <1363876896.88.0.901114514497.issue1429@bugs.pypy.org>
Message-ID: <1389013588.97.0.822299416869.issue1429@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

PyPY on Windows is still slow, but the problem seems to be reading from the 
file. By using the csvtest_preload.py to read the file into a list of strings, 
the times improve greatly. This points to IO problems with Windows more than 
parsing problems with CSV

csvtest.py -
reading took 1.986 seconds
writing took 0.411 seconds
complete took 2.397 seconds

csvtest_preload.py
reading took 0.292 seconds
writing took 0.243 seconds
complete took 0.535 seconds

----------
nosy: +mattip
status: resolved -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1429>
________________________________________
-------------- next part --------------

import csv
import time

with open('airports.csv') as file_in:
    lines = file_in.readlines()
for i in range(10):
    t0 = time.time()
    rows = list(csv.reader(lines))
    t1 = time.time()
    with open('airports.csv.out', 'wb') as file_out:
        writer = csv.writer(file_out)
        writer.writerows(rows)
    t2 = time.time()

    print 'reading took %.3f seconds' % (t1 - t0)
    print 'writing took %.3f seconds' % (t2 - t1)
    print 'complete took %.3f seconds' % (t2 - t0)

From tracker at bugs.pypy.org  Tue Jan  7 00:38:32 2014
From: tracker at bugs.pypy.org (sn6uv)
Date: Mon, 06 Jan 2014 23:38:32 +0000
Subject: [pypy-issue] [issue1668] sporadic seg fault with cffi
In-Reply-To: <1389051512.96.0.194249030628.issue1668@bugs.pypy.org>
Message-ID: <1389051512.96.0.194249030628.issue1668@bugs.pypy.org>


New submission from sn6uv <16sn6uv at gmail.com>:

Steps to reproduce
==================
git clone git at github.com:sn6uv/gmpy_cffi.git
cd gmpy_cffi

Then run
py.test-pypy
repeatedly.

Details
=======
About 90% of the time the tests run and pass, but about 10% of the time I get 
some form of error. So far I've seen a few different errors
- Most commonly zsh: segmentation fault (core dumped)  /opt/pypy/bin/py.test 
double free e.g.. *** Error in `/usr/bin/pypy': double free or corruption (out): 
0x00002b101d3c55d0 ***
- corrupted double-linked list e.g * Error in `/usr/bin/pypy': corrupted double-
linked list: 0x00000000041fcdf0 ***
- corrupted double-linked malloc variant list e.g. *** Error in `/usr/bin/pypy': 
malloc(): smallbin double linked list corrupted: 0x00000000057bcfa0 ***
- free()/realloc() invalid pointer e.g. *** Error in `/usr/bin/pypy': realloc(): 
invalid pointer: 0x0000000005c388b0 ***
- free() invalid size e.g. .*** Error in `/usr/bin/pypy': free(): invalid size: 
0x00000000077e6820 ***
- Kernel panic requiring hard restart of my system. This one is exceedingly rare 
(<< 1%).

The errors occur at different points throughout the tests, but it's always in 
the same test file.
Upon removing that file from the test suite the errors just occur in the next 
file.

Occasionally I get a backtrace [1] accompanying the error but most of the time 
not.

I've confirmed this on my desktop and my laptop (both run archlinux with PyPy 
2.2.1-final, cffi version 0.8). Also on the travis CI tests [2] (which seem to 
error more regularly than my local 
systems). Alex Gaynor was able to reproduce this of OS X also.

This may be a bug in cffi I'm not sure (I posted to the cffi mailing list also). 

[1] http://pastebin.com/td376i2M
[2] https://travis-ci.org/sn6uv/gmpy_cffi/jobs/16210613

----------
messages: 6456
nosy: pypy-issue, sn6uv
priority: bug
release: ???
status: unread
title: sporadic seg fault with cffi

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1668>
________________________________________

From tracker at bugs.pypy.org  Tue Jan  7 03:11:57 2014
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Tue, 07 Jan 2014 02:11:57 +0000
Subject: [pypy-issue] [issue1571] py3k: cffi says initializer for ctype
	'char[]' must be a	str or list or tuple, not str
In-Reply-To: <1375362715.89.0.380428240667.issue1571@bugs.pypy.org>
Message-ID: <1389060717.03.0.77858221793.issue1571@bugs.pypy.org>


Philip Jenvey <pjenvey at underboss.org> added the comment:

fixed in 18ba4e72d2f7, thanks

----------
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1571>
________________________________________

From arigo at tunes.org  Tue Jan  7 09:46:02 2014
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 7 Jan 2014 09:46:02 +0100
Subject: [pypy-issue] [issue1668] sporadic seg fault with cffi
In-Reply-To: <1389051512.96.0.194249030628.issue1668@bugs.pypy.org>
References: <1389051512.96.0.194249030628.issue1668@bugs.pypy.org>
 <1389051512.96.0.194249030628.issue1668@bugs.pypy.org>
Message-ID: <CAMSv6X3VZD0vZm08DJ_KSfvbZCzkg7mPW31BKO6imBTG76bBfQ@mail.gmail.com>

Hi,

I can reproduce your segfault on CPython too, so the problem is not
PyPy.  The problem is a keepalive issue.  CPython crashes consistently
on a line like this:

    print gmpy_cffi.mpc(1.5, 2.3).real

I guess it's because the .real returns a reference inside the data
managed by the mpc object, but it is deallocated while the .real
object is still alive, which ends up in a crash.  With CPython, you
can find it reliably by compiling _cffi_backend with -DCFFI_MEM_DEBUG
before running the tests.  (I guess that it is a trick that should be
mentioned on the doc page...)


A bient?t,

Armin.

From tracker at bugs.pypy.org  Thu Jan  9 06:13:10 2014
From: tracker at bugs.pypy.org (Daniel Morgan)
Date: Thu, 09 Jan 2014 05:13:10 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>


New submission from Daniel Morgan <daniel.patrick.morgan at gmail.com>:

RPython traceback:
  File "pypy_module_pypyjit_interp_jit.c", line 118, in 
jump_absolute__AccessDirect_None
  File "rpython_jit_metainterp_warmstate.c", line 2723, in 
maybe_compile_and_run__star_5_1
  File "rpython_jit_metainterp_warmstate.c", line 8873, in bound_reached__star_5_1
  File "rpython_jit_metainterp_pyjitpl.c", line 5818, in 
compile_and_run_once___rpython_jit_metainterp_ji_4
  File "rpython_jit_metainterp_pyjitpl.c", line 4872, in 
MetaInterp__compile_and_run_once
  File "rpython_jit_metainterp_pyjitpl.c", line 8042, in MetaInterp_interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 14632, in MetaInterp__interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 22909, in MIFrame_run_one_step
  File "rpython_jit_metainterp_pyjitpl.c", line 51507, in handler_residual_call_ir_v
  File "rpython_jit_metainterp_pyjitpl_3.c", line 9320, in execute_varargs___126
  File "rpython_jit_metainterp_pyjitpl_2.c", line 38333, in 
MetaInterp__record_helper_nonpure_varargs
  File "rpython_jit_metainterp_heapcache.c", line 12236, in HeapCache_clear_caches
  File "rpython_rtyper_lltypesystem_rdict_1.c", line 40684, in 
ll_dict_getitem__dicttablePtr_Signed_11
~~~ Crash in JIT! <KeyError object at 0x101747540>

----------
files: main.py
messages: 6459
nosy: dmorgan1, pypy-issue
priority: bug
status: unread
title: Getting error: ~~~ Crash in JIT! <KeyError object at 0x101747540>

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Thu Jan  9 06:17:16 2014
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Thu, 09 Jan 2014 05:17:16 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389244636.53.0.179827011599.issue1669@bugs.pypy.org>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

This imports several files which aren't included, can you either make a tarball 
which we can download with all the needed files to run this, or minimize the 
example to only be one file.

----------
nosy: +agaynor
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Thu Jan  9 13:09:34 2014
From: tracker at bugs.pypy.org (sn6uv)
Date: Thu, 09 Jan 2014 12:09:34 +0000
Subject: [pypy-issue] [issue1668] sporadic seg fault with cffi
In-Reply-To: <1389051512.96.0.194249030628.issue1668@bugs.pypy.org>
Message-ID: <1389269374.13.0.865719216694.issue1668@bugs.pypy.org>


sn6uv <16sn6uv at gmail.com> added the comment:

Okay. I'll mark this invalid. Can we continue the discussion on the python-cffi 
mailing list instead.

----------
status: chatting -> invalid

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1668>
________________________________________

From tracker at bugs.pypy.org  Thu Jan  9 14:21:05 2014
From: tracker at bugs.pypy.org (Daniel Morgan)
Date: Thu, 09 Jan 2014 13:21:05 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389273665.53.0.585156181948.issue1669@bugs.pypy.org>


Daniel Morgan <daniel.patrick.morgan at gmail.com> added the comment:

the error seems to be coming up during the import csv stage

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Thu Jan  9 14:34:03 2014
From: tracker at bugs.pypy.org (zzz654321)
Date: Thu, 09 Jan 2014 13:34:03 +0000
Subject: [pypy-issue] [issue1670] BUG! ctypes create_string_buffer
In-Reply-To: <5c6aea3d.c6e4.14377355afc.Coremail.lightdarkadmin@163.com>
Message-ID: <5c6aea3d.c6e4.14377355afc.Coremail.lightdarkadmin@163.com>


New submission from zzz654321 <lightdarkadmin at 163.com>:

import ctypes as C

s1= "0"* 1024* 1024* 10
# mem engross add 10M bytes
b1= C.create_string_buffer(s1 )
# CPU 1 core 100% and mem engross add 300M bytes ?
I don't know!
please talk me, thanks very match....

I'm chinese, english is not good, sorry!

----------
files: unnamed
messages: 6463
nosy: pypy-issue, zzz654321
status: unread
title: BUG! ctypes create_string_buffer

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1670>
________________________________________

From tracker at bugs.pypy.org  Thu Jan  9 21:16:51 2014
From: tracker at bugs.pypy.org (Daniel Morgan)
Date: Thu, 09 Jan 2014 20:16:51 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389298611.6.0.14324065358.issue1669@bugs.pypy.org>


Daniel Morgan <daniel.patrick.morgan at gmail.com> added the comment:

do let me know if the zip file is okay - otherwise ill work on getting you a tar ball

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 10 11:09:06 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 10 Jan 2014 10:09:06 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389348546.36.0.216442651217.issue1669@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Precise version of PyPy, and operating system, please :-)

----------
nosy: +arigo

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 10 14:32:13 2014
From: tracker at bugs.pypy.org (Daniel Morgan)
Date: Fri, 10 Jan 2014 13:32:13 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389360733.82.0.31142460096.issue1669@bugs.pypy.org>


Daniel Morgan <daniel.patrick.morgan at gmail.com> added the comment:

pypy-2.2.1-osx64
osx 10.9.1 (latest version of Mavericks)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 10 14:32:31 2014
From: tracker at bugs.pypy.org (Daniel Morgan)
Date: Fri, 10 Jan 2014 13:32:31 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389360751.47.0.480963782493.issue1669@bugs.pypy.org>


Daniel Morgan <daniel.patrick.morgan at gmail.com> added the comment:

Thanks so much for looking into this for me

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 10 15:16:40 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 10 Jan 2014 14:16:40 +0000
Subject: [pypy-issue] [issue1670] BUG! ctypes create_string_buffer
In-Reply-To: <5c6aea3d.c6e4.14377355afc.Coremail.lightdarkadmin@163.com>
Message-ID: <1389363400.86.0.724130931583.issue1670@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Fixed in 872f6055d970.  Thanks for the bug report!  It might have been a
long-standing issue with memory in ctypes: memory was not promptly released,
leading to the apparence of leaks.

----------
nosy: +arigo
priority:  -> bug
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1670>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 10 16:55:11 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 10 Jan 2014 15:55:11 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389369311.85.0.736844233718.issue1669@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Reproduced on Linux 64 with a build from today.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 10 17:07:36 2014
From: tracker at bugs.pypy.org (Daniel Morgan)
Date: Fri, 10 Jan 2014 16:07:36 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389370056.39.0.1624599834.issue1669@bugs.pypy.org>


Daniel Morgan <daniel.patrick.morgan at gmail.com> added the comment:

Arigo, thanks for looking at this for me - do let me know if it works or if you get the 
same error.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 10 18:15:29 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 10 Jan 2014 17:15:29 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389374129.92.0.726367110733.issue1669@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Fixed in 5ca199444bb9, by figuring out where the crash occurs and doing the
obvious fix.  But it's hard for me to know how to derive a test.  I only checked
that the example provided here (which used to crash for me as you reported) now
work.  Good enough in this case, I hope :-)

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 10 18:25:00 2014
From: tracker at bugs.pypy.org (Daniel Morgan)
Date: Fri, 10 Jan 2014 17:25:00 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389374129.92.0.726367110733.issue1669@bugs.pypy.org>
Message-ID: <CA+njk2Muh7KCuGtYqHe4R0ed5SN4+BukYdnfYpDPEhHZW07mmA@mail.gmail.com>


Daniel Morgan <daniel.patrick.morgan at gmail.com> added the comment:

Armin, thanks so much. What should I do now to get my version working? Do I
need to download pypy again?

Best,
Daniel

On Fri, Jan 10, 2014 at 12:15 PM, Armin Rigo <tracker at bugs.pypy.org> wrote:

>
> Armin Rigo <armin.rigo at gmail.com> added the comment:
>
> Fixed in 5ca199444bb9, by figuring out where the crash occurs and doing the
> obvious fix.  But it's hard for me to know how to derive a test.  I only
> checked
> that the example provided here (which used to crash for me as you
> reported) now
> work.  Good enough in this case, I hope :-)
>
> ----------
> status: chatting -> resolved
>
> ________________________________________
> PyPy bug tracker <tracker at bugs.pypy.org>
> <https://bugs.pypy.org/issue1669>
> ________________________________________
>

----------
status: resolved -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 10 18:35:44 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 10 Jan 2014 17:35:44 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389375344.68.0.798510475505.issue1669@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

http://buildbot.pypy.org/nightly/trunk/ will contain tonight's automatic build,
which you can simply download from tomorrow morning.

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 10 18:37:32 2014
From: tracker at bugs.pypy.org (Daniel Morgan)
Date: Fri, 10 Jan 2014 17:37:32 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389375344.68.0.798510475505.issue1669@bugs.pypy.org>
Message-ID: <CA+njk2NKowQrpc7WkB5yLv+Ra2ECn-y1-wzVPW4n-M9=Ospviw@mail.gmail.com>


Daniel Morgan <daniel.patrick.morgan at gmail.com> added the comment:

Thanks!

On Fri, Jan 10, 2014 at 12:35 PM, Armin Rigo <tracker at bugs.pypy.org> wrote:

>
> Armin Rigo <armin.rigo at gmail.com> added the comment:
>
> http://buildbot.pypy.org/nightly/trunk/ will contain tonight's automatic
> build,
> which you can simply download from tomorrow morning.
>
> ----------
> status: chatting -> resolved
>
> ________________________________________
> PyPy bug tracker <tracker at bugs.pypy.org>
> <https://bugs.pypy.org/issue1669>
> ________________________________________
>

----------
status: resolved -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 11 12:37:44 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 11 Jan 2014 11:37:44 +0000
Subject: [pypy-issue] [issue1671] ctypes keepalive missing
In-Reply-To: <1389440264.97.0.0275615216068.issue1671@bugs.pypy.org>
Message-ID: <1389440264.97.0.0275615216068.issue1671@bugs.pypy.org>


New submission from Armin Rigo <armin.rigo at gmail.com>:

The attached example prints garbage on PyPy, but works on CPython.  This means
that our ctypes is probably missing some keepalive logic, which is potentially
bad, because it still works "most of the time" as long as no collection occurs
in the meantime.

----------
files: x.py
messages: 6476
nosy: arigo, pypy-issue
priority: bug
status: unread
title: ctypes keepalive missing

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1671>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 11 18:26:12 2014
From: tracker at bugs.pypy.org (Daniel Morgan)
Date: Sat, 11 Jan 2014 17:26:12 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389461172.72.0.467304342249.issue1669@bugs.pypy.org>


Daniel Morgan <daniel.patrick.morgan at gmail.com> added the comment:

Hi, I just checked the builds - which one do I download. I see several for 5ca199444bb9 
but none for mac osx. Do I just download the general one for osx or is it the freedsb 
one for 5ca199444bb9.

Thanks,
Dan

----------
status: resolved -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 11 20:01:06 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 11 Jan 2014 19:01:06 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389466866.16.0.271310548588.issue1669@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

The OS/X builder has apparently been down for a few hours.  There is now a build
for OS/X too, de464ba9c716.

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 11 21:05:21 2014
From: tracker at bugs.pypy.org (Daniel Morgan)
Date: Sat, 11 Jan 2014 20:05:21 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389470721.71.0.658055901961.issue1669@bugs.pypy.org>


Daniel Morgan <daniel.patrick.morgan at gmail.com> added the comment:

I tried using pypy-c-jit-68596-de464ba9c716-osx64 and I get the same error:

RPython traceback:
  File "pypy_module_pypyjit_interp_jit.c", line 118, in 
jump_absolute__AccessDirect_None
  File "rpython_jit_metainterp_warmstate.c", line 2723, in 
maybe_compile_and_run__star_5_1
  File "rpython_jit_metainterp_warmstate.c", line 8873, in bound_reached__star_5_1
  File "rpython_jit_metainterp_pyjitpl.c", line 5818, in 
compile_and_run_once___rpython_jit_metainterp_ji_4
  File "rpython_jit_metainterp_pyjitpl.c", line 4872, in 
MetaInterp__compile_and_run_once
  File "rpython_jit_metainterp_pyjitpl.c", line 8042, in MetaInterp_interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 14632, in MetaInterp__interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 22909, in MIFrame_run_one_step
  File "rpython_jit_metainterp_pyjitpl.c", line 51507, in handler_residual_call_ir_v
  File "rpython_jit_metainterp_pyjitpl_3.c", line 9320, in execute_varargs___126
  File "rpython_jit_metainterp_pyjitpl_2.c", line 38333, in 
MetaInterp__record_helper_nonpure_varargs
  File "rpython_jit_metainterp_heapcache.c", line 12236, in HeapCache_clear_caches
  File "rpython_rtyper_lltypesystem_rdict_1.c", line 40684, in 
ll_dict_getitem__dicttablePtr_Signed_11
~~~ Crash in JIT! <KeyError object at 0x101747540>
Abort trap: 6

Should I used a different build?

----------
status: resolved -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 12 06:10:45 2014
From: tracker at bugs.pypy.org (Gerald)
Date: Sun, 12 Jan 2014 05:10:45 +0000
Subject: [pypy-issue] [issue1672] Fatal RPython Error: UnicodeDecodeError
In-Reply-To: <1389503445.95.0.200079635061.issue1672@bugs.pypy.org>
Message-ID: <1389503445.95.0.200079635061.issue1672@bugs.pypy.org>


New submission from Gerald <gera2ld at 163.com>:

PyPy version: pypy3 2.1 beta
OS: Win7 Ultimate 32bit

Just one line of code:
>>> import uuid

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
RPython traceback:
  File "pypy_goal_targetpypystandalone.c", line 2727, in entry_point
  File "pypy_interpreter_pyframe.c", line 1427, in PyFrame_execute_frame
  File "rpython_jit_metainterp_warmspot.c", line 1135, in 
ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 101, in portal_3
  File "pypy_interpreter_pyopcode.c", line 7030, in 
handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 12720, in 
dispatch_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 21837, in 
call_function__AccessDirect_None
  File "pypy_interpreter_pyframe.c", line 1427, in PyFrame_execute_frame
  File "rpython_jit_metainterp_warmspot.c", line 1135, in 
ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 101, in portal_3
  File "pypy_interpreter_pyopcode.c", line 7030, in 
handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 12375, in 
dispatch_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 21837, in 
call_function__AccessDirect_None
  File "pypy_interpreter_pyframe.c", line 1427, in PyFrame_execute_frame
  File "rpython_jit_metainterp_warmspot.c", line 1135, in 
ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 101, in portal_3
  File "pypy_interpreter_pyopcode.c", line 7030, in 
handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 13677, in 
dispatch_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 21837, in 
call_function__AccessDirect_None
  File "pypy_interpreter_pyframe.c", line 1427, in PyFrame_execute_frame
  File "rpython_jit_metainterp_warmspot.c", line 1135, in 
ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 101, in portal_3
  File "pypy_interpreter_pyopcode.c", line 7030, in 
handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 9287, in 
dispatch_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 17461, in 
CALL_FUNCTION__AccessDirect_None
  File "pypy_interpreter_pyframe.c", line 1427, in PyFrame_execute_frame
  File "rpython_jit_metainterp_warmspot.c", line 1135, in 
ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 101, in portal_3
  File "pypy_interpreter_pyopcode.c", line 7030, in 
handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 9287, in 
dispatch_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 17461, in 
CALL_FUNCTION__AccessDirect_None
  File "pypy_interpreter_gateway.c", line 3280, in BuiltinCode_funcrun_obj
  File "pypy_interpreter_gateway.c", line 3640, in BuiltinCode_handle_exception
Fatal RPython error: UnicodeDecodeError

----------
messages: 6480
nosy: gerald, pypy-issue
priority: bug
release: 2.1
status: unread
title: Fatal RPython Error: UnicodeDecodeError

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1672>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 12 17:42:26 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 12 Jan 2014 16:42:26 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389544946.38.0.333435229004.issue1669@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Works for me.  Please double-check that you're really and only using
de464ba9c716, and run the main.py/python.zip that you pasted here.  For me it
works on Linux 64, whereas it failed as reported previously.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 12 17:43:40 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 12 Jan 2014 16:43:40 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389545020.74.0.251132136669.issue1669@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

...in particular, the line numbers being *exactly* the same as in the previous
traceback is very suspicious.  It looks like you're accidentally using the
previous pypy.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 12 19:43:59 2014
From: tracker at bugs.pypy.org (Daniel Morgan)
Date: Sun, 12 Jan 2014 18:43:59 +0000
Subject: [pypy-issue] [issue1669] Getting error: ~~~ Crash in JIT! <KeyError
	object at	0x101747540>
In-Reply-To: <1389244390.54.0.33072966795.issue1669@bugs.pypy.org>
Message-ID: <1389552239.1.0.993476416707.issue1669@bugs.pypy.org>


Daniel Morgan <daniel.patrick.morgan at gmail.com> added the comment:

You were right. Sorry PyPy is new to me so I'm just getting the hang of how everything 
works. I have everything working now. I really appreciate your help. Thanks!

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1669>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 13 15:30:05 2014
From: tracker at bugs.pypy.org (mmaenpaa)
Date: Mon, 13 Jan 2014 14:30:05 +0000
Subject: [pypy-issue] [issue1673] Can't copy AST-nodes that have missing
	fields
In-Reply-To: <1389623405.63.0.0669653596687.issue1673@bugs.pypy.org>
Message-ID: <1389623405.63.0.0669653596687.issue1673@bugs.pypy.org>


New submission from mmaenpaa <mika.j.maenpaa at iki.fi>:

In Pypy it is not possible to copy ast-nodes that have missing fields or attributes.

For example:

>>>> import ast
>>>> import copy
>>>> n = ast.Num(n=2,lineno=2)
>>>> n2 = copy.deepcopy(n)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "lib-python/2.7/copy.py", line 182, in deepcopy
    rv = reductor(2)
AttributeError: 'Num' object has no attribute 'col_offset'

----------
messages: 6484
nosy: mmaenpaa, pypy-issue
priority: bug
release: 2.2
status: unread
title: Can't copy AST-nodes that have missing fields

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1673>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 13 18:49:57 2014
From: tracker at bugs.pypy.org (remi)
Date: Mon, 13 Jan 2014 17:49:57 +0000
Subject: [pypy-issue] [issue1674] broken mask indexing / selection
In-Reply-To: <1389635397.99.0.388613215276.issue1674@bugs.pypy.org>
Message-ID: <1389635397.99.0.388613215276.issue1674@bugs.pypy.org>


New submission from remi <remi2402 at free.fr>:

>>> import numpy as np
>>> data = np.arange(15).reshape(3, 5) * 1.0
>>> data
array([[  0.,   1.,   2.,   3.,   4.],
       [  5.,   6.,   7.,   8.,   9.],
       [ 10.,  11.,  12.,  13.,  14.]])
>>> m = data[:, 0] % 2 == 0
>>> m
array([ True, False,  True], dtype=bool)

on CPython 2.7 with numpy 1.6.2 (debian stable/wheezy)
>>> data[m, 0]
array([  0.,  10.])

on PyPy / Python 2.7.3 (25070f2267c4, Jan 13 2014, 14:17:42)
>>>> data[m, 0]
array([ 5.,  0.,  5.])

----------
assignedto: r.lobb
messages: 6485
nosy: pypy-issue, r.lobb, remi
priority: bug
status: unread
title: broken mask indexing / selection

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1674>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 13 23:54:19 2014
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Mon, 13 Jan 2014 22:54:19 +0000
Subject: [pypy-issue] [issue1672] py3k: Fatal RPython Error:
	UnicodeDecodeError
In-Reply-To: <1389503445.95.0.200079635061.issue1672@bugs.pypy.org>
Message-ID: <1389653659.09.0.0435947900432.issue1672@bugs.pypy.org>


Philip Jenvey <pjenvey at underboss.org> added the comment:

Unfortunately I'm unable to reproduce this (WinXP).

What happens when you run pypy with --jit off?

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1672>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 14 02:49:03 2014
From: tracker at bugs.pypy.org (Richard Lobb)
Date: Tue, 14 Jan 2014 01:49:03 +0000
Subject: [pypy-issue] [issue1674] broken mask indexing / selection
In-Reply-To: <1389635397.99.0.388613215276.issue1674@bugs.pypy.org>
Message-ID: <1389664143.04.0.823168123587.issue1674@bugs.pypy.org>


Richard Lobb <trampgeek at gmail.com> added the comment:

I think assigning this to me is a mistake. I'm not a pypy developer, just a guy 
who logged a bug report a year or two ago.

----------
assignedto: r.lobb -> 
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1674>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 14 16:16:43 2014
From: tracker at bugs.pypy.org (Gerald)
Date: Tue, 14 Jan 2014 15:16:43 +0000
Subject: [pypy-issue] [issue1672] py3k: Fatal RPython Error:
	UnicodeDecodeError
In-Reply-To: <1389503445.95.0.200079635061.issue1672@bugs.pypy.org>
Message-ID: <1389712603.15.0.580420958899.issue1672@bugs.pypy.org>


Gerald <gera2ld at 163.com> added the comment:

Exact the same with --jit off.
That's really weird. :(

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1672>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 16 11:59:51 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 16 Jan 2014 10:59:51 +0000
Subject: [pypy-issue] [issue1675] Avoid double calls: jitted code -> helper
	-> real function
In-Reply-To: <1389869991.7.0.307041676051.issue1675@bugs.pypy.org>
Message-ID: <1389869991.7.0.307041676051.issue1675@bugs.pypy.org>


New submission from Armin Rigo <armin.rigo at gmail.com>:

In some cases our assembler contains calls to helpers whose only purpose is to
call the real functions.  Example: PyPy contains 295 versions of the function
_ll_0_alloc_with_del.  Avoid this.

----------
messages: 6489
nosy: arigo, pypy-issue
priority: performance bug
status: unread
title: Avoid double calls: jitted code -> helper -> real function

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1675>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 17 13:27:59 2014
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Fri, 17 Jan 2014 12:27:59 +0000
Subject: [pypy-issue] [issue892] Pypy is slower on longs than it should
In-Reply-To: <1317663715.18.0.663914446646.issue892@bugs.pypy.org>
Message-ID: <1389961679.83.0.862263347855.issue892@bugs.pypy.org>


Carl Friedrich Bolz <cfbolz at gmx.de> added the comment:

Committed in 84ab6e698cac, thank you!

----------
nosy: +cfbolz
status: chatting -> testing

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue892>
________________________________________

From tracker at bugs.pypy.org  Fri Jan 17 20:54:38 2014
From: tracker at bugs.pypy.org (Alex Stewart)
Date: Fri, 17 Jan 2014 19:54:38 +0000
Subject: [pypy-issue] [issue1676] cppyy: Incorrect __class__ for Python
	subclasses of C++	classes
In-Reply-To: <1389988478.85.0.648989574508.issue1676@bugs.pypy.org>
Message-ID: <1389988478.85.0.648989574508.issue1676@bugs.pypy.org>


New submission from Alex Stewart <foogod at gmail.com>:

(The cppyy docs sorta imply that this sort of thing (subclassing C++ classes 
from Python) should be possible, so I'm assuming this is a bug..)

If I have a C++ class (say, "CppClass") imported via cppyy, and create a 
subclass of this in Python like so:

class MyClass (cppyy.gbl.CppClass):
    def myfunc(self):
        print "Yay!"

When I create an instance of MyClass, what I actually get back is an instance of 
CppClass, not of MyClass, so I can't actually use the additional 
attributes/methods defined on the subclass:

>>>> o = MyClass()
>>>> o.__class__
<class '__main__.CppClass'>
>>>> isinstance(o, MyClass)
False
>>>> o.myfunc()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'CppClass' object has no attribute 'myfunc'

I notice, however, that if I override __new__ and explicitly fix the __class__ 
attribute of the returned object, things actually do seem to work as expected:

class MyClass (cppyy.gbl.CppClass):
    def __new__(cls):
        o = cppyy.gbl.CppClass.__new__(cls)
        o.__class__ = cls
        return o

    def myfunc(self):
        print "Yay!"

>>>> o = MyClass()
>>>> o.__class__
<class '__main__.MyClass'>
>>>> isinstance(o, MyClass)
True
>>>> o.myfunc()
Yay!

(And I can still access all the C++ members from the parent class as expected 
too)

It looks like the default cppyy __new__ constructor is just not setting 
__class__ correctly on the created object?

----------
messages: 6491
nosy: Foogod, pypy-issue
priority: bug
release: 2.2
status: unread
title: cppyy: Incorrect __class__ for Python subclasses of C++ classes

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1676>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 18 18:58:16 2014
From: tracker at bugs.pypy.org (kostia.lopuhin)
Date: Sat, 18 Jan 2014 17:58:16 +0000
Subject: [pypy-issue] [issue1652] Array search ( Sorting/index heavy) is
	2.24x slower on	PyPy than Python2 and Python3
In-Reply-To: <1386279511.75.0.122444070392.issue1652@bugs.pypy.org>
Message-ID: <1390067896.14.0.738662810509.issue1652@bugs.pypy.org>


kostia.lopuhin <kostia.lopuhin at gmail.com> added the comment:

On the code from archive I get 26 s for PyPy nighly (OS X 64 bit) and 16 s for 
CPython 2.7. If I put Point and _get_high_values into top-level scope, then PyPy 
nighly is much slower (89 s vs 16 for CPython). But then if I replace 
itememgetter(x) for _clock and _value definitions with lambda y: x[y], or move 
_clock and _value definitions into top level, than PyPy takes 17 s (and by the way 
PyPy 2.0 and 2.1 take 13 seconds on this last version).
So, one of the reasons for PyPy slowness here might be itemgetter, defined inside 
a hot function.

----------
nosy: +kostia.lopuhin

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1652>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 18 19:13:08 2014
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 18 Jan 2014 18:13:08 +0000
Subject: [pypy-issue] [issue1652] Array search ( Sorting/index heavy) is
	2.24x slower on	PyPy than Python2 and Python3
In-Reply-To: <1386279511.75.0.122444070392.issue1652@bugs.pypy.org>
Message-ID: <1390068788.97.0.141442237909.issue1652@bugs.pypy.org>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

I think there's a problem with str/unicode dicts, adding `from __future__ import 
unicode_literals` to the top makes this faster.

----------
nosy: +agaynor

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1652>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 18 19:15:11 2014
From: tracker at bugs.pypy.org (kostia.lopuhin)
Date: Sat, 18 Jan 2014 18:15:11 +0000
Subject: [pypy-issue] [issue1652] Array search ( Sorting/index heavy) is
	2.24x slower on	PyPy than Python2 and Python3
In-Reply-To: <1386279511.75.0.122444070392.issue1652@bugs.pypy.org>
Message-ID: <1390068911.48.0.801497402525.issue1652@bugs.pypy.org>


kostia.lopuhin <kostia.lopuhin at gmail.com> added the comment:

As for the itemgetter slowness - if I define _clock = builtinify(lambda x: 
x['clock']) than I get the same slowdown as for _clock = itemgetter('clock'). So 
it seems that function wrapped into builtinify needs a lot more time to warm up?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1652>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 18 20:51:32 2014
From: tracker at bugs.pypy.org (kostia.lopuhin)
Date: Sat, 18 Jan 2014 19:51:32 +0000
Subject: [pypy-issue] [issue1652] Array search ( Sorting/index heavy) is
	2.24x slower on	PyPy than Python2 and Python3
In-Reply-To: <1386279511.75.0.122444070392.issue1652@bugs.pypy.org>
Message-ID: <1390074692.4.0.379155986037.issue1652@bugs.pypy.org>


kostia.lopuhin <kostia.lopuhin at gmail.com> added the comment:

By the way, it seems that making itemgetter('a') a builtin is not documented here 
http://docs.python.org/2/library/operator.html and is not checked in lib_python or 
pypy tests - so maybe there is no point in making the result of itermgetter 
function a builtin?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1652>
________________________________________

From tracker at bugs.pypy.org  Sat Jan 18 21:17:58 2014
From: tracker at bugs.pypy.org (lvella)
Date: Sat, 18 Jan 2014 20:17:58 +0000
Subject: [pypy-issue] [issue1677] itertools.product slower than nested fors
In-Reply-To: <1390076278.88.0.469888288883.issue1677@bugs.pypy.org>
Message-ID: <1390076278.88.0.469888288883.issue1677@bugs.pypy.org>


New submission from lvella <lvella at gmail.com>:

Consider the 2 following snippets:

a)
n = 0.0
for i in xrange(1000):
    for j in xrange(1000):
        for k in xrange(1000):
            n += float(i) * j * k
print n

b)
import itertools
n = 0.0
for i,j,k in itertools.product(xrange(1000), xrange(1000), xrange(1000)):
    n += float(i) * j * k
print n

I find snippet b) much nicer to read and write, but it is sad that b) is much
slower than a):

execution of a):
$ time pypy loop.py 
1.24625374875e+17

real	0m7.877s
user	0m7.853s
sys	0m0.020s

execution of b):
$ time pypy loop.py 
1.24625374875e+17

real	0m38.214s
user	0m38.209s
sys	0m0.008s

So, can this be fixed, so both have the good speed of a)?

----------
messages: 6496
nosy: lvella, pypy-issue
priority: feature
status: unread
title: itertools.product slower than nested fors

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1677>
________________________________________

From tracker at bugs.pypy.org  Sun Jan 19 18:23:22 2014
From: tracker at bugs.pypy.org (Jeremy Thurgood)
Date: Sun, 19 Jan 2014 17:23:22 +0000
Subject: [pypy-issue] [issue1671] ctypes keepalive missing
In-Reply-To: <1389440264.97.0.0275615216068.issue1671@bugs.pypy.org>
Message-ID: <1390152202.98.0.77523047158.issue1671@bugs.pypy.org>


Jeremy Thurgood <firxen at gmail.com> added the comment:

Fixed in 68766:1329fe522dfb.

----------
assignedto:  -> jerith
nosy: +jerith
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1671>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 21 11:45:50 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 21 Jan 2014 10:45:50 +0000
Subject: [pypy-issue] [issue1678] example 20x slower after the first time
In-Reply-To: <1390301150.19.0.0852731519756.issue1678@bugs.pypy.org>
Message-ID: <1390301150.19.0.0852731519756.issue1678@bugs.pypy.org>


New submission from Armin Rigo <armin.rigo at gmail.com>:

>From ????????? on pypy-dev.

bug: run fibonacci() for 10 times and it's much lower since the second time.

----------
files: x.py
messages: 6498
nosy: arigo, pypy-issue
priority: performance bug
status: unread
title: example 20x slower after the first time

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1678>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 22 00:37:23 2014
From: tracker at bugs.pypy.org (wiredfool)
Date: Tue, 21 Jan 2014 23:37:23 +0000
Subject: [pypy-issue] [issue1679] Segfault on 32bit pypy
In-Reply-To: <1390347443.25.0.353202447744.issue1679@bugs.pypy.org>
Message-ID: <1390347443.25.0.353202447744.issue1679@bugs.pypy.org>


New submission from wiredfool <eric-pypy at soroos.net>:

Using Ubuntu 13.10, pypy 2.2.1 from the ppa. 

One of the tests in Pillow segfaults on a 32bit build, not on a 64bit build. This test 
passes 
on all cpythons that I've tested. 

It's this test: 
https://github.com/wiredfool/Pillow/blob/master/Tests/test_imagefont.py#L33 , 
though it also fails on the open file test in the next test case. 

The _render method works when passed a font path, not when it gets a file like object, 
i.e. 
this succeeds:  https://github.com/python-
imaging/Pillow/blob/master/Tests/test_imagefont.py#L63 and this fails: 
https://github.com/python-imaging/Pillow/blob/master/Tests/test_imagefont.py#L66


To Reproduce:

sudo apt-get install  libjpeg8-dev zlib1g-dev libfreetype6-dev 
git clone https://github.com/wiredfool/Pillow.git
virtualenv -p /usr/bin/pypy vpypy
source vpypy/bin/activate
cd Pillow/
python setup.py install
python Tests/test_imagefont.py --installed

----------
messages: 6499
nosy: pypy-issue, wiredfool
priority: bug
status: unread
title: Segfault on 32bit pypy

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1679>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 22 12:10:50 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 22 Jan 2014 11:10:50 +0000
Subject: [pypy-issue] [issue1679] Segfault on 32bit pypy
In-Reply-To: <1390347443.25.0.353202447744.issue1679@bugs.pypy.org>
Message-ID: <1390389050.31.0.981950672898.issue1679@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

A possibly related bug: when compiled with lldebug, pypy immediately crashes on
"import cpyext" with "in pypy_check_stack_count: bad stacks_counter or
non-closed stacks around".

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1679>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 22 12:51:56 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 22 Jan 2014 11:51:56 +0000
Subject: [pypy-issue] [issue1679] Segfault on 32bit pypy
In-Reply-To: <1390347443.25.0.353202447744.issue1679@bugs.pypy.org>
Message-ID: <1390391516.76.0.921693849738.issue1679@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

It turned out to be unrelated.  I tried compiling the .c files of Pillow with
the "-g -O0" flags.  The crash occurs in libfreetype.so when in the call
"FT_Get_Char_Index(face, ch);" from _imagingft.c:222.  As far as I can tell,
"face" and "ch" look reasonable.  The "self" out of which we have just read
"face" also looks reasonable, with ob_refcnt == 1 and a correct ob_type.

I guess the next step is to obtain a debug version of libfreetype and try to
debug it.  I'm not saying the bug is necessarily in libfreetype, but I'm not
excluding it either, and debugging both pypy and libfreetype together seems
required at this point.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1679>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 22 13:31:18 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 22 Jan 2014 12:31:18 +0000
Subject: [pypy-issue] [issue1679] Segfault on 32bit pypy
In-Reply-To: <1390347443.25.0.353202447744.issue1679@bugs.pypy.org>
Message-ID: <1390393878.01.0.380326771563.issue1679@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

I cannot find anything wrong in PyPy (I ran it with MALLOC_CHECK_=3 in a special
mode to detect usage of memory after free()).  I'd suggest to try to print all
operations done on this particular "face" object from C code, and comparing the
results on CPython and on PyPy.  Maybe PyPy indeed messes up something earlier.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1679>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 22 14:08:03 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 22 Jan 2014 13:08:03 +0000
Subject: [pypy-issue] [issue1677] itertools.product slower than nested fors
In-Reply-To: <1390076278.88.0.469888288883.issue1677@bugs.pypy.org>
Message-ID: <1390396083.26.0.475052681756.issue1677@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Try again with tomorrow's build: http://buildbot.pypy.org/nightly/trunk/ .  I
hope it should be a bit faster, but I don't know how much.

Note that our goal is to ensure that itertools is not massively slower than
plain Python, but we don't really care about making it exactly as fast (or
faster) as plain Python.  As long as it's not massively slower, it's fine.  (At
least I don't agree with you about whether a) or b) is easier to read :-)

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1677>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 22 20:54:06 2014
From: tracker at bugs.pypy.org (wiredfool)
Date: Wed, 22 Jan 2014 19:54:06 +0000
Subject: [pypy-issue] [issue1679] Segfault on 32bit pypy
In-Reply-To: <1390347443.25.0.353202447744.issue1679@bugs.pypy.org>
Message-ID: <1390420446.01.0.405731121006.issue1679@bugs.pypy.org>


wiredfool <eric-pypy at soroos.net> added the comment:

Running under gdb, with symbols compiled into libfreetype, breaking in _imagingft.c when 
the font is created, and then just prior to the segfault. 


(vpypy)erics at builder-1310-x86:~/Pillow$ gdb python
GNU gdb (GDB) 7.6.1-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/erics/vpypy/bin/pypy...(no debugging symbols found)...done.
(gdb) b _imagingft.c:142
No symbol table is loaded.  Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (_imagingft.c:142) pending.
(gdb) b _imagingft.c:221
No symbol table is loaded.  Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (_imagingft.c:221) pending.
(gdb) r Tests/test_imagefont.py --installed
Starting program: /home/erics/vpypy/bin/python Tests/test_imagefont.py --installed
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

Breakpoint 1, getfont (self_=0x0, args=0xb7abb0f0, kw=0xb7abb0f8) at _imagingft.c:142
142	    if (!error)
(gdb) p ((TT_CMap)self->face->charmap)[0]
$1 = {cmap = {charmap = {face = 0xa4227a0, encoding = FT_ENCODING_UNICODE, platform_id = 
3, encoding_id = 10}, 
    clazz = 0xb6f972c0 <tt_cmap12_class_rec>}, data = 0xb6c97830 "", flags = 0}
(gdb) c
Continuing.

Breakpoint 2, font_getsize (self=0xb7ab8150, args=0xb7abb0f8) at _imagingft.c:221
221	        face = self->face;
(gdb) p ((TT_CMap)self->face->charmap)[0]
$2 = {cmap = {charmap = {face = 0xa4227a0, encoding = FT_ENCODING_UNICODE, platform_id = 
3, encoding_id = 10}, 
    clazz = 0xb6f972c0 <tt_cmap12_class_rec>}, data = 0xb6c97830 <Address 0xb6c97830 out 
of bounds>, flags = 0}



This corresponds to the python (where bp1 is in the first call, and bp2 is in the 
second): 
    ttf = ImageFont.truetype(font, font_size)
    w, h = ttf.getsize(txt)

The operative parts of ImageFont.truetype are:

           self.font_bytes = font.read()
           self.font = core.getfont("", size, index, encoding, self.font_bytes)

(at which point, it returns)

Breaking at the final line of getfont and the first line of font_getsize,  it looks like 
the data pointer is getting freed somewhere outside of the freetype library. There's 
precious little python in there either, as it's the last line of getfont, and getsize 
just calls out to the c extension.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1679>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 22 22:06:47 2014
From: tracker at bugs.pypy.org (dmlockhart)
Date: Wed, 22 Jan 2014 21:06:47 +0000
Subject: [pypy-issue] [issue1680] ast.NodeTransformer throws AttributeError
	in pypy only
In-Reply-To: <1390424807.78.0.389244299554.issue1680@bugs.pypy.org>
Message-ID: <1390424807.78.0.389244299554.issue1680@bugs.pypy.org>


New submission from dmlockhart <dmlockhart+pypy at gmail.com>:

I have some code which performs transformations of python ast objects.  The code 
executes as expected in CPython 2.7, but when run with the pypy interpreter, I 
receive the following traceback:

Traceback (most recent call last):
  File "app_main.py", line 72, in run_toplevel
  File "ast_exception_bug.py", line 47, in <module>
    new_tree = RemoveSelf().visit( tree )
  File "/Users/dmlockhart/venvs/pypy-2.0.2/lib-python/2.7/ast.py", line 241, in 
visit
    return visitor(node)
  File "/Users/dmlockhart/venvs/pypy-2.0.2/lib-python/2.7/ast.py", line 297, in 
generic_visit
    value = self.visit(value)
  File "/Users/dmlockhart/venvs/pypy-2.0.2/lib-python/2.7/ast.py", line 241, in 
visit
    return visitor(node)
  File "/Users/dmlockhart/venvs/pypy-2.0.2/lib-python/2.7/ast.py", line 297, in 
generic_visit
    value = self.visit(value)
  File "/Users/dmlockhart/venvs/pypy-2.0.2/lib-python/2.7/ast.py", line 241, in 
visit
    return visitor(node)
  File "/Users/dmlockhart/venvs/pypy-2.0.2/lib-python/2.7/ast.py", line 297, in 
generic_visit
    value = self.visit(value)
  File "/Users/dmlockhart/venvs/pypy-2.0.2/lib-python/2.7/ast.py", line 241, in 
visit
    return visitor(node)
  File "/Users/dmlockhart/venvs/pypy-2.0.2/lib-python/2.7/ast.py", line 308, in 
generic_visit
    delattr(node, field)
AttributeError: cannot delete attribute




Platform: OSX Mavericks

Interpreters Tested:
pypy-2.0.2
pypy-2.1

----------
files: ast_exception_bug.py
messages: 6505
nosy: dmlockhart, pypy-issue
priority: bug
status: unread
title: ast.NodeTransformer throws AttributeError in pypy only

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1680>
________________________________________

From tracker at bugs.pypy.org  Wed Jan 22 22:23:59 2014
From: tracker at bugs.pypy.org (wiredfool)
Date: Wed, 22 Jan 2014 21:23:59 +0000
Subject: [pypy-issue] [issue1679] Segfault on 32bit pypy
In-Reply-To: <1390347443.25.0.353202447744.issue1679@bugs.pypy.org>
Message-ID: <1390425839.27.0.792218726471.issue1679@bugs.pypy.org>


wiredfool <eric-pypy at soroos.net> added the comment:

Run on 64bit:

Breakpoint 1, getfont (self_=0x0, args=0x7ffff7faa130, kw=0x7ffff7faa120) at _imagingft.c:142
142	    if (!error)
(gdb) p ((TT_CMap)self->face->charmap)[0]
$4 = {cmap = {charmap = {face = 0x3036da0, encoding = FT_ENCODING_UNICODE, platform_id = 3, 
encoding_id = 10}, 
    clazz = 0x7ffff40c0800 <tt_cmap12_class_rec>}, data = 0x7ffff535d828 "", flags = 0}
(gdb) c
Continuing.

Breakpoint 2, font_getsize (self=0x7ffff7fa7168, args=0x7ffff7faa120) at _imagingft.c:221
221	        face = self->face;
(gdb) p ((TT_CMap)self->face->charmap)[0]
$5 = {cmap = {charmap = {face = 0x3036da0, encoding = FT_ENCODING_UNICODE, platform_id = 3, 
encoding_id = 10}, 
    clazz = 0x7ffff40c0800 <tt_cmap12_class_rec>}, data = 0x7ffff535d828 "", flags = 0}


Data hasn't been freed in this case.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1679>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 23 10:24:02 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 23 Jan 2014 09:24:02 +0000
Subject: [pypy-issue] [issue1679] Segfault on 32bit pypy
In-Reply-To: <1390347443.25.0.353202447744.issue1679@bugs.pypy.org>
Message-ID: <1390469042.11.0.293770601197.issue1679@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Ok, found it.  You are calling FT_New_Memory_Face() with the font_bytes being a
pointer just returned from PyArg_ParseTuple(..."s#"...), but you're not keeping
alive the object that held that memory.  CPython is "more or less safe" because
you call core.getfont(.., self.font_bytes) and thus keep the font_bytes string
alive as needed --- assuming, reasonably, that nobody does "font.font_bytes =
None" behind your back.  This doesn't work in PyPy because the data in the
font_bytes object is copied from GC memory to non-movable memory before the call
to core.getfont(), and freed afterwards.

I'd suggest that you change this to make the C-level FontObject keep a reference
to the font_bytes, rather than the Python-level FreeTypeFont.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1679>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 27 20:22:39 2014
From: tracker at bugs.pypy.org (Konstantin Alekseev)
Date: Mon, 27 Jan 2014 19:22:39 +0000
Subject: [pypy-issue] [issue1681] Regular expression 2.5x faster with cpython
In-Reply-To: <1390850559.24.0.877748026005.issue1681@bugs.pypy.org>
Message-ID: <1390850559.24.0.877748026005.issue1681@bugs.pypy.org>


New submission from Konstantin Alekseev <kv.alekseev at gmail.com>:

~ /usr/bin/python test_pypy.py
Time: 2.907 seconds
 
~ python test_pypy.py
Time: 7.733 seconds
 
~ python -V
Python 2.7.3 (2.2.1+dfsg-1~ppa1, Nov 28 2013, 02:02:56)
[PyPy 2.2.1 with GCC 4.6.3]
 
~ /usr/bin/python -V
Python 2.7.3

----------
files: test_pypy.py
messages: 6508
nosy: konstantin, pypy-issue
priority: performance bug
status: unread
title: Regular expression 2.5x faster with cpython

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1681>
________________________________________

From tracker at bugs.pypy.org  Mon Jan 27 22:53:17 2014
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Mon, 27 Jan 2014 21:53:17 +0000
Subject: [pypy-issue] [issue1682] changes in cpyext broke several lib-python
	tests on mac64
In-Reply-To: <1390859597.58.0.588955837992.issue1682@bugs.pypy.org>
Message-ID: <1390859597.58.0.588955837992.issue1682@bugs.pypy.org>


New submission from Brian Kearns <bdkearns at gmail.com>:

I suspect 49c649807414 and related changesets.

* thread #1: tid = 0xc93b3, 0x00000001007272eb pypy-c1`pypy_g_init_types + 11, 
queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, 
address=0x2623461)
    frame #0: 0x00000001007272eb pypy-c1`pypy_g_init_types + 11
pypy-c1`pypy_g_init_types + 11:
-> 0x1007272eb:  testb  $16, 169(%rdi)
   0x1007272f2:  jne    0x100727320               ; pypy_g_init_types + 64
   0x1007272f4:  callq  0x10077ad10               ; pypy_g_type_realize
   0x1007272f9:  leaq   32528048(%rip), %rax      ; pypy_g_ExcData

----------
messages: 6509
nosy: bdk, pypy-issue
priority: critical
status: unread
title: changes in cpyext broke several lib-python tests on mac64

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1682>
________________________________________

From tracker at bugs.pypy.org  Tue Jan 28 17:44:18 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 28 Jan 2014 16:44:18 +0000
Subject: [pypy-issue] [issue1682] changes in cpyext broke several lib-python
	tests on mac64
In-Reply-To: <1390859597.58.0.588955837992.issue1682@bugs.pypy.org>
Message-ID: <1390927458.76.0.772816768577.issue1682@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

I cannot guess what is wrong here.  What is the value of %rdi?  Where does it
come from?

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1682>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 30 09:45:23 2014
From: tracker at bugs.pypy.org (gangesmaster)
Date: Thu, 30 Jan 2014 08:45:23 +0000
Subject: [pypy-issue] [issue1683] BytesIO leaks like hell
In-Reply-To: <1391071523.88.0.269822509177.issue1683@bugs.pypy.org>
Message-ID: <1391071523.88.0.269822509177.issue1683@bugs.pypy.org>


New submission from gangesmaster <tomerfiliba at gmail.com>:

Our web server was leaking memory over time (twisted+cyclone). For reference:
http://stackoverflow.com/questions/21063842/using-twisted-cyclone-pypy-to-handle-
post-requests-cause-a-memory-leak

It turns out it's all due to the following code in cyclone:

    from io import BytesIO as StringIO
    ...
    if content_length < 100000:
        self._contentbuffer = StringIO()
    else:
        self._contentbuffer = TemporaryFile()

( https://github.com/fiorix/cyclone/blob/master/cyclone/httpserver.py#L168 )

We noticed that only smaller buffers leaked. We're running with:

    Python 2.7.3 (87aa9de10f9c, Nov 24 2013, 20:57:21)
    [PyPy 2.2.1 with GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on 
darwin

Here's a code snippet that recreates the problem:

    from io import BytesIO

    while True:
        s = BytesIO()

This code leaks like hell, reaching 1GB in ~3 seconds and soaring up still.

Just for comparison, cStringIO.StringIO and StringIO.StringIO do not leak. 
None of them leak on CPython too.

----------
messages: 6511
nosy: gangesmaster, pypy-issue
priority: bug
release: 2.2
status: unread
title: BytesIO leaks like hell

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1683>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 30 11:28:12 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 30 Jan 2014 10:28:12 +0000
Subject: [pypy-issue] [issue1683] BytesIO leaks like hell
In-Reply-To: <1391071523.88.0.269822509177.issue1683@bugs.pypy.org>
Message-ID: <1391077692.26.0.121319245645.issue1683@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Bah, the leak appears to be StreamHolder from module/_io/interp_iobase.py:
running the tiny example with "gc.dump_rpy_heap()" at the end, the program ends
with one very large dictionary (likely "AutoFlusher.streams") and millions of
instances of "StreamHolder" and "weakref".

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1683>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 30 11:39:11 2014
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 30 Jan 2014 10:39:11 +0000
Subject: [pypy-issue] [issue1683] BytesIO leaks like hell
In-Reply-To: <1391071523.88.0.269822509177.issue1683@bugs.pypy.org>
Message-ID: <1391078351.04.0.911800572901.issue1683@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Should be fixed in 40fa4f3a0740, translate or try tomorrow nightly

----------
nosy: +fijal
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1683>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 30 11:51:49 2014
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 30 Jan 2014 10:51:49 +0000
Subject: [pypy-issue] [issue1684] io module requires serious review
In-Reply-To: <1391079109.06.0.302449668339.issue1684@bugs.pypy.org>
Message-ID: <1391079109.06.0.302449668339.issue1684@bugs.pypy.org>


New submission from Fijal <fijall at gmail.com>:

io module contains several code paths related to autoflusher in which the item 
does not get removed from the autoflusher after being deleted, thus leaving 
dangling entries in the autflusher (e.g. is it possible that the file is closed 
and then not removed by having a specific custom subclass that overloads close 
and does not call parent?)

Another problem is that all this finding methods for subclasses is quite slow, 
we should maybe investigate what needs to be done in order to make it better

----------
messages: 6514
nosy: fijal, pypy-issue
priority: bug
status: unread
title: io module requires serious review

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1684>
________________________________________

From tracker at bugs.pypy.org  Thu Jan 30 12:30:10 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 30 Jan 2014 11:30:10 +0000
Subject: [pypy-issue] [issue1684] io module requires serious review
In-Reply-To: <1391079109.06.0.302449668339.issue1684@bugs.pypy.org>
Message-ID: <1391081410.02.0.371257126507.issue1684@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

1101ea526ac3 fixed the main issue: it should not create memory leaks any more. 
I did not consider the correctness issues mentioned here.

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1684>
________________________________________