Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

weird crash #38

Closed
GoogleCodeExporter opened this issue Mar 15, 2015 · 10 comments
Closed

weird crash #38

GoogleCodeExporter opened this issue Mar 15, 2015 · 10 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. i'd attached the example code
2.
3.

What is the expected output? What do you see instead?
Print from 0-999 and nothing. Instead i get a crash after 999.

What version of the product are you using? On what operating system?
PyV8 0.8 (win32-2.6 with python 2.6-win32 on x64 machine)

Please provide any additional information below.


Original issue reported on code.google.com by Liubomir...@gmail.com on 22 Feb 2010 at 2:59

Attachments:

@GoogleCodeExporter
Copy link
Author

The same code, with little changes:
jsCtx.eval(str(
"""
var arr = new Array();
for(var i=0;i<1000;i++) {
    arr[i] = "a" + 1;
}
"""
))

arr = jsCtx.locals.arr
for k in arr:
    print k


Prints "stdout" ??

Original comment by Liubomir...@gmail.com on 22 Feb 2010 at 3:07

@GoogleCodeExporter
Copy link
Author

I need to setup a x64 environment and reproduce it, could you reproduce it on 
x86 
system? I tried the latest SVN build, it seems ok

Original comment by flier...@gmail.com on 22 Feb 2010 at 6:00

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

Hm, my test machine is x64, but the installation files (python2.6 + pyv8 are x86
installation), so i dont think this is because of the x64 machine.
Currently i dont have proper Windows machine with x86 :(

I can test it on x86 (ubuntu) the next week if this will help ?

Original comment by Liubomir...@gmail.com on 23 Feb 2010 at 11:59

@GoogleCodeExporter
Copy link
Author

ok, I will install a test machine to verify it soon, thanks anyway

Original comment by flier...@gmail.com on 23 Feb 2010 at 12:09

@GoogleCodeExporter
Copy link
Author

10x for the good support :)
If you need something else, message me here, so i can help :)

Original comment by Liubomir...@gmail.com on 23 Feb 2010 at 12:13

@GoogleCodeExporter
Copy link
Author

I have installed a x64 and x86 test machine, it seems PyV8 v0.8 definitely have 
issue 
to handle a very large array. I guess the root cause is the wrong reference 
count, 
because I have fixed several related issues in the latest SVN build, and it 
seems ok 
to run your test script.

So, could you verify it with the private build in attachment? I think I should 
make 
some paper work to release a new v0.9 version in this week, I wish it could 
solve 
your issue.

Thanks

Original comment by flier...@gmail.com on 24 Feb 2010 at 5:15

  • Changed state: Fixed
  • Added labels: OpSys-All

Attachments:

@GoogleCodeExporter
Copy link
Author

tested and it works :)
10x

Original comment by Liubomir...@gmail.com on 25 Feb 2010 at 6:43

@GoogleCodeExporter
Copy link
Author

Thanks :)

Original comment by flier...@gmail.com on 25 Feb 2010 at 6:45

  • Changed state: Verified

@GoogleCodeExporter
Copy link
Author

Just wondering, is this bug valid in the linux pkg too ?
I'm about to push the new pyv8 on our productions, so just wondering to wait 
for the
new build or its already working (under linux x64) ?

Original comment by Liubomir...@gmail.com on 25 Feb 2010 at 6:54

@GoogleCodeExporter
Copy link
Author

I think it should be a general issue, because the reference count doesn't 
depend on 
the platform. As you known, boost::python handle most of the reference count 
issues, 
but some special situation need be handled by manual.

In fact, the basic features has stabled a few weeks ago, but I had planned to 
release 
PyV8 v0.9 with the full feature Javascript AST support, but the plan was 
delayed :( 
So, the v0.9 will be released in this week without AST by default, because it 
is a 
very independent module.

It means, the SVN code will not be modified except the AST and build related 
issues 
:)

Original comment by flier...@gmail.com on 25 Feb 2010 at 7:06

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant