On Mon, Dec 5, 2011 at 12:30 AM, Ram Rachum wrote:
> Hey guys,
>
> I'm happy to say that I don't see this crash anymore in PyPy 1.7! Thanks!
>
Pleasure!
>
> Ram.
>
> On Mon, Oct 10, 2011 at 5:13 PM, Ram Rachum wrote:
>>
>> Tried it now with this Zip, getting the same crash.
>>
>>
>> On Mon, Oct
Hey guys,
I'm happy to say that I don't see this crash anymore in PyPy 1.7! Thanks!
Ram.
On Mon, Oct 10, 2011 at 5:13 PM, Ram Rachum wrote:
> Tried it now with this Zip, getting the same crash.
>
>
> On Mon, Oct 10, 2011 at 4:58 PM, Armin Rigo wrote:
>
>> Hi,
>>
>> On Mon, Oct 10, 2011 at 13
Tried it now with this Zip, getting the same crash.
On Mon, Oct 10, 2011 at 4:58 PM, Armin Rigo wrote:
> Hi,
>
> On Mon, Oct 10, 2011 at 13:11, Ram Rachum wrote:
> > Trying to download this file results in getting a tiny corrupted archive.
> > Also, I don't know whether this is a source release
Hi,
On Mon, Oct 10, 2011 at 13:11, Ram Rachum wrote:
> Trying to download this file results in getting a tiny corrupted archive.
> Also, I don't know whether this is a source release or a binary release. I
> don't know to compile so I can only use a binary one.
Bah, I don't know why the recent z
Trying to download this file results in getting a tiny corrupted archive.
Also, I don't know whether this is a source release or a binary release. I
don't know to compile so I can only use a binary one.
On Sun, Oct 9, 2011 at 12:29 PM, Armin Rigo wrote:
> Hi,
>
> On Sun, Oct 9, 2011 at 12:15, R
Hi,
On Sun, Oct 9, 2011 at 12:15, Ram Rachum wrote:
> Did anyone give that a try?
Sorry, it may take a while, because Windows is not our primary
platform. In the meantime, could you try with this latest version of
pypy? Thanks!
http://buildbot.pypy.org/nightly/trunk/pypy-c-jit-latest-win32.zip
On Fri, Oct 7, 2011 at 11:03 AM, Ram Rachum wrote:
>
> Hey guys,
>
> I've managed to produce a VM that shows the bug.
>
> You can download it here:
>
> http://dl.dropbox.com/u/1927707/VM%20for%20debugging%20PyPy.rar
>
> It's a VMWare Virtual Machine, and it weighs 2 GB compressed.
>
> Once you fi
On Thu, Oct 6, 2011 at 10:13 AM, Amaury Forgeot d'Arc wrote:
> Hi,
>
> 2011/10/5 Martin Kretschmar :
> > Microsofts free WinDbg (http://en.wikipedia.org/wiki/WinDbg) can also
> attach
> > to running processes.
>
> A release build of pypy contains no debug information
> Believe me, a debugger won't
Hi,
2011/10/5 Martin Kretschmar :
> Microsofts free WinDbg (http://en.wikipedia.org/wiki/WinDbg) can also attach
> to running processes.
A release build of pypy contains no debug information
Believe me, a debugger won't show anything useful.
It's already difficult enough in a debug build (becaus
Hello,
Microsofts free WinDbg (http://en.wikipedia.org/wiki/WinDbg) can also
attach to running processes.
Regards,
Martin
"Ram Rachum" schrieb:
Hey guys,
I upgraded to PyPy 1.6 on my 2 Windows XP 32 bit machines. It crashes on
both system when running the GarlicSim test suite.
Can you fill in something for "#Do something that uses lots of RAM"? Because
I'm not sure I'll get it right.
On Thu, Oct 6, 2011 at 12:02 AM, Alex Pyattaev wrote:
> I've had a very similar stuff, as in something crashing only when run many
> times when I had a bug in a container type implemented
I've had a very similar stuff, as in something crashing only when run many
times when I had a bug in a container type implemented in C. Basically, I had
wrong refcount for the objets, which caused them to be freed by garbage
collectore while they have been still used. Maybe something similar hap
On Wed, Oct 5, 2011 at 6:51 PM, Amaury Forgeot d'Arc wrote:
> 2011/10/5 Ram Rachum :
> > Okay, I've spent a few hours print-debugging, and I think I've almost got
> > it.
> > The crash happens on a line:
> > st = os.stat(s)
> > inside `os.path.isdir`, where `s` is a string 'C:\\Documents and
>
2011/10/5 Ram Rachum :
> Okay, I've spent a few hours print-debugging, and I think I've almost got
> it.
> The crash happens on a line:
> st = os.stat(s)
> inside `os.path.isdir`, where `s` is a string 'C:\\Documents and
> Settings\\User\\My Documents\\Python Projects\\GarlicSim\\garlicsim\\src
On Wed, Oct 5, 2011 at 4:11 PM, Ram Rachum wrote:
> On Wed, Oct 5, 2011 at 2:23 PM, Alex Pyattaev wrote:
>
>> Another option is to edit the sources of the test suite adding print
>> statements incrementally until you spot the place where it crashes. It is
>> a
>> slow, but very reliable way. That
2011/10/5 Brian Curtin :
> On Wed, Oct 5, 2011 at 08:22, Amaury Forgeot d'Arc wrote:
>> 2011/10/5 Michael Foord :
>>> Well, in recent versions it gained the faulthandler module... :-)
>>>
>>> http://pypi.python.org/pypi/faulthandler/
>>
>> Yes, and this was a *great* improvement!
>> I hope we will
On Wed, Oct 5, 2011 at 2:23 PM, Alex Pyattaev wrote:
> Generally, any binary-level debugger such as gdb or MSVC should work with
> pypy. At the very least you will find which operation crashed.
>
As I said to Amaury, I don't know how to use those... Python is the only
language I program in.
>
On Wed, Oct 5, 2011 at 08:22, Amaury Forgeot d'Arc wrote:
> 2011/10/5 Michael Foord :
>> Well, in recent versions it gained the faulthandler module... :-)
>>
>> http://pypi.python.org/pypi/faulthandler/
>
> Yes, and this was a *great* improvement!
> I hope we will be able to adapt it to pypy.
It
2011/10/5 Michael Foord :
> Well, in recent versions it gained the faulthandler module... :-)
>
> http://pypi.python.org/pypi/faulthandler/
Yes, and this was a *great* improvement!
I hope we will be able to adapt it to pypy.
--
Amaury Forgeot d'Arc
___
On 5 October 2011 13:50, Amaury Forgeot d'Arc wrote:
> 2011/10/5 Alex Pyattaev :
> > In Cpython it works
> > somewhat better, but not in PYPY
>
> How is CPython behavior better with segfaults?
>
>
Well, in recent versions it gained the faulthandler module... :-)
http://pypi.python.org/pypi/fault
2011/10/5 Alex Pyattaev :
> In Cpython it works
> somewhat better, but not in PYPY
How is CPython behavior better with segfaults?
--
Amaury Forgeot d'Arc
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
> If I use a Python debugger, can't I just step forward line by line, see
> where I get the crash, and then isolate the offending line?
The way pypy works - no you can not really do that. In Cpython it works
somewhat better, but not in PYPY. Basically you have to use C debugger to
locate the cras
On Wed, Oct 5, 2011 at 2:22 PM, Amaury Forgeot d'Arc wrote:
> 2011/10/5 Ram Rachum :
> > How do I run the Nose test suite on Pypy with a debugger? I usually use
> Wing
> > IDE, but it doesn't support PyPy. I'm also aware of Nose's `--pdb` flag
> > which drops you into the debugger after an error,
Generally, any binary-level debugger such as gdb or MSVC should work with
pypy. At the very least you will find which operation crashed.
If it is something really specific, for example
sin/log/sign, it might be quite easy to map it back to python code. If it is
not, it will be nearly impossibl
2011/10/5 Ram Rachum :
> How do I run the Nose test suite on Pypy with a debugger? I usually use Wing
> IDE, but it doesn't support PyPy. I'm also aware of Nose's `--pdb` flag
> which drops you into the debugger after an error, but it doesn't work here
> because this crash seems to be happening at
On Wed, Oct 5, 2011 at 2:11 PM, Amaury Forgeot d'Arc wrote:
> 2011/10/5 Ram Rachum :
> > I have hundreds of tests, and PyPy fails before a single one begins. It
> > seems that PyPy crashes somewhere in nose's initialization.
> > Isn't there a way to find the last Python line run before the crash
>
2011/10/5 Ram Rachum :
> I have hundreds of tests, and PyPy fails before a single one begins. It
> seems that PyPy crashes somewhere in nose's initialization.
> Isn't there a way to find the last Python line run before the crash without
> stepping with a finer granularity every time?
Not without a
On Wed, Oct 5, 2011 at 2:07 PM, Amaury Forgeot d'Arc wrote:
> 2011/10/5 Ram Rachum :
> > I am running PyPy from terminal, bash provided by msys. The error still
> > comes up in a dialog and the shell contains only the output from `nose`
> up
> > to the failure, with no word on the failure.
>
> Can
2011/10/5 Ram Rachum :
> I am running PyPy from terminal, bash provided by msys. The error still
> comes up in a dialog and the shell contains only the output from `nose` up
> to the failure, with no word on the failure.
Can you still see which test fails?
and then add print statements to determin
On Wed, Oct 5, 2011 at 1:49 PM, Alex Pyattaev wrote:
> 1. Switch to linux. It helps.
>
Not funny.
2. To get a meaningful error log try to run the pypy from terminal. To do
> copy-paste you will need 3-rd party terminal, i.e. power shell. Then you'll
> be
> able to copy the error messages. Witho
2011/10/5 Ram Rachum :
> Hey guys,
> I upgraded to PyPy 1.6 on my 2 Windows XP 32 bit machines. It crashes on
> both system when running the GarlicSim test suite.
> It shows a Windows error dialog saying "pypy.exe has encountered a problem
> and needs to close. We are sorry for the inconvenience."
1. Switch to linux. It helps.
2. To get a meaningful error log try to run the pypy from terminal. To do
copy-paste you will need 3-rd party terminal, i.e. power shell. Then you'll be
able to copy the error messages. Without them it is pretty much impossible to
identify the problem.
3. Another
Hey guys,
I upgraded to PyPy 1.6 on my 2 Windows XP 32 bit machines. It crashes on
both system when running the GarlicSim test suite.
It shows a Windows error dialog saying "pypy.exe has encountered a problem
and needs to close. We are sorry for the inconvenience." and giving this
data:
AppName
33 matches
Mail list logo
