Local scope has already been closed

[Mark Hahn]

At some point in my app I'm getting this error when running v0.6.3 ...

    FATAL ERROR: v8::HandleScope::Close() Local scope has already been closed

However, when I switch back to v0.4.12 it doesn't happen.

Has anyone seen this symptom before?  I haven't chased down where it happens yet.  I was hoping someone was familiar with this symptom and save me the trouble.

[Jake Verbaten]

hiredis issue may be related : https://github.com/mranney/node_redis/issues/150

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Mark Hahn]

That is the exact symptom but I don't use redis.  I suspect it is a problem in node 0.6.x.

When I get the time I will find the point in my code where this happens.  Meanwhile I'm back on 0.4.12 to keep on working.

[Marco Rogers]

Mark. That hiredis thread seems to point to issues with versioning. Perhaps your modules have been built against the wrong versions of node or node-waf. Especially since you say you're switching back and forth. Are you rebuilding the binary each time and are you sure you're switching paths so you're not mixing the build tools? No offense. I would just hate for you to spend a lot of time only to find out this was an easy forehead slapping moment.

:Marco

[Mark Hahn]

My server build has only had node installed via nvm.  So it may be an  nvm problem.

On Mon, Nov 28, 2011 at 11:08 PM, Marco Rogers <marco....@gmail.com> wrote:

Mark. That hiredis thread seems to point to issues with versioning. Perhaps your modules have been built against the wrong versions of node or node-waf. Especially since you say you're switching back and forth. Are you rebuilding the binary each time and are you sure you're switching paths so you're not mixing the build tools? No offense. I would just hate for you to spend a lot of time only to find out this was an easy forehead slapping moment.

:Marco

--

[Nathan Rajlich]

Make sure you recompile the module.

[Mark Hahn]

>  Make sure you recompile the module. 

What module are you talking about?

[Marco Rogers]

Yeah, by rebuild the binary I was talking about your module that uses C bindings. But I realize now that you never stated that and I assumed. Are you using any C addons and if so, can you tell if the problem originates there?

:Marco

[Mark Hahn]

I use nothing but javascript.

[Ben Noordhuis]

Can you post the backtrace? You get it by running your script like this:

$ gdb --args node script.js
run
# wait until the fatal error
backtrace

[Mark Hahn]

I switched back and it's not happening in my current version of code.  I'll stay on 0.6.3 until/if it happens again.

[Mark Hahn]

Btw, can I run `gdb --args node script.js` inside node-dev?  If so I can have it running all the time during my development.

[Mark Hahn]

I remembered how to create it and I can cause it at will now. Here is the results of what you asked for.  Unfortunately when I entered backtrace my console window just sat there with no output.  I did a `top

TBGdev drykup > gdb --args node /ria/src/ria.js main

GNU gdb (GDB) 7.1-ubuntu

Copyright (C) 2010 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 "i486-linux-gnu".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...

Reading symbols from /root/.nvm/v0.6.3/bin/node...done.

(gdb) run

Starting program: /root/.nvm/v0.6.3/bin/node /ria/src/ria.js main

[Thread debugging using libthread_db enabled]

[New Thread 0xb7b3eb70 (LWP 29782)]

<maindev> 11-11-29 14:47:53.448 LOG: ------ Starting RIA Application

<maindev> 11-11-29 14:47:53.799 LOG: ------ Starting DB Change Router (seqnum 21)

[New Thread 0xb72eeb70 (LWP 29783)]

<maindev> 11-11-29 14:47:54.016 LOG: ------ Starting Client Comm

<maindev> 11-11-29 14:47:54.031 LOG: ------ Starting Notification Manager

<maindev> 11-11-29 14:47:54.140 LOG: ------ Starting View URL Router (port 81)

<maindev> 11-11-29 14:47:58.044 LOG: GET /

<sockdev> 11-11-29 14:47:59.607 Session_mgr: Page Registered (connect) <0662 5c4c 1326> dev.comps2.info

FATAL ERROR: v8::HandleScope::Close() Local scope has already been closed

backtrace

[Mark Hahn]

(Continuing last msg ...)

 I did a `top` cmd in another console window and nothing interesting was running.

[Mark Hahn]

I will chase down the point of execution in my code where it happens.

[Ben Noordhuis]

On Tue, Nov 29, 2011 at 23:52, Mark Hahn <ma...@hahnca.com> wrote:
> I will chase down the point of execution in my code where it happens.

Can you add this before the `run` step?

break api.cc:764

For extra karma points, compile with `./configure --debug` and test
with node_g instead of node. :-)

[Mark Hahn]

It still didn't break.  Here is the terminal session. Note that I had to do a 'Make breakpoint pending...'.

If you want I could clone my server and let you play.  You'd have to say you agree to not copy my code.

gdb --args node /ria/src/ria.js main

GNU gdb (GDB) 7.1-ubuntu

Copyright (C) 2010 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 "i486-linux-gnu".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...

Reading symbols from /root/.nvm/v0.6.3/bin/node...done.

(gdb) break api.cc:764

No source file named api.cc.

Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (api.cc:764) pending.

(gdb) run

Starting program: /root/.nvm/v0.6.3/bin/node /ria/src/ria.js main

[Thread debugging using libthread_db enabled]

[New Thread 0xb7b3eb70 (LWP 30684)]

<maindev> 11-11-29 15:05:14.589 LOG: ------ Starting RIA Application

<maindev> 11-11-29 15:05:14.966 LOG: ------ Starting DB Change Router (seqnum 27)

[New Thread 0xb72e6b70 (LWP 30685)]

<maindev> 11-11-29 15:05:15.126 LOG: ------ Starting Client Comm

<maindev> 11-11-29 15:05:15.139 LOG: ------ Starting Notification Manager

<maindev> 11-11-29 15:05:15.281 LOG: ------ Starting View URL Router (port 81)

<maindev> 11-11-29 15:05:20.785 LOG: session_mgr: Error opening f25ba9e7b1c25a010b129bff52000662 404

<maindev> 11-11-29 15:05:20.789 Session_mgr: Session Opened 317a2ee479626142b232161033000cf7, ip: 127.0.0.1

<maindev> 11-11-29 15:05:20.789 LOG: GET /

<sockdev> 11-11-29 15:05:22.821 Session_mgr: Page Registered (connect) <0cf7 17a8 1753> dev.comps2.info

[Ben Noordhuis]

On Wed, Nov 30, 2011 at 00:10, Mark Hahn <ma...@hahnca.com> wrote:
> It still didn't break.  Here is the terminal session. Note that I had to do
> a 'Make breakpoint pending...'.

Right, gdb probably can't find it because the release builds don't
contain enough debug symbol information. It will work with debug
builds, i.e. node_g.

[Mark Hahn]

Can you point me to instructions for the easiest way to do a debug build?  Can it be done with NVM?

[Ben Noordhuis]

On Wed, Nov 30, 2011 at 00:25, Mark Hahn <ma...@hahnca.com> wrote:
> Can you point me to instructions for the easiest way to do a debug build?
>  Can it be done with NVM?

Not sure about nvm, don't use it myself, but building debug builds is trivial:

$ git clone https://github.com/joyent/node.git
cd node
./configure --debug
make

You now have a node_g in the repo's root directory.

[Mark Hahn]

I've tried this build twice.  Both times it seems to build and the final `ln -fs out/Debug/node node_g` returns no error.  But afterwards the out/Debug directory is missing.  There is only an out/Release. 

Here is the beginning of my build.  I just noticed that the make output says "BUILDTYPE=Release".

TBGdev node >  ./configure --debug

configure options: {'shared_v8': None, 'openssl_includes': None, 'without_snapshot': None, 'shared_v8_includes': None, 'shared_v8_libpath': None, 'openssl_libpath': None, 'shared_cares_includes': None, 'dest_cpu': None, 'without_ssl': None, 'shared_cares': None, 'prefix': None, 'no_ssl2': None, 'debug': True, 'shared_cares_libpath': None, 'shared_v8_libname': None, 'gdb': None, 'with_dtrace': None}

sh: pkg-config: not found

creating  ./options.gypi

['-f', 'make', '/root/node/node.gyp', '-I', '/root/node/common.gypi', '-I', '/root/node/options.gypi', '--depth=.', '--generator-output', '/root/node/out', '-Goutput_dir=/root/node/out', '-Dtarget_arch=ia32', '-Dcomponent=static_library', '-Dlibrary=static_library']

TBGdev node > make

make -C out BUILDTYPE=Release

make[1]: Entering directory `/root/node/out'

  CC(target) /root/node/out/Release/obj.target/http_parser/deps/http_parser/http_parser.o

  AR(target) /root/node/out/Release/obj.target/deps/http_parser/libhttp_parser.a

... <snip> ...

[Ben Noordhuis]

Sorry, my mistake. You can either check out the v0.6 branch or build
with `make BUILDTYPE=Debug`. We're changing build systems in master.

[Mark Hahn]

Hmm.  I'm not having good luck, but I'm not bothered (to quote british teens).  

Node_g erred out immediately instead of waiting for me to perform the action that crashes it. I tried it with the breakpoint also but it never broke.  Maybe you can learn something from it.

TBGdev node > gdb --args /root/node/node_g /ria/src/ria.js main

GNU gdb (GDB) 7.1-ubuntu

Copyright (C) 2010 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 "i486-linux-gnu".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...

Reading symbols from /root/node/node_g...done.

(gdb) run

Starting program: /root/node/node_g /ria/src/ria.js main

[Thread debugging using libthread_db enabled]

[New Thread 0xb7cd9b70 (LWP 7435)]

<maindev> 11-11-29 21:46:41.958 LOG: ------ Starting RIA Application

<maindev> 11-11-29 21:46:45.870 LOG: ------ Starting DB Change Router (seqnum 32)

[New Thread 0xb74b2b70 (LWP 7436)]

<maindev> 11-11-29 21:46:48.999 LOG: ------ Starting Client Comm

<maindev> 11-11-29 21:46:49.414 LOG: ------ Starting Notification Manager

/root/node/node_g: symbol lookup error: /ria/src/node_modules/hashlib.node: undefined symbol: _ZN2v811HandleScopeC1Ev

[Thread 0xb74b2b70 (LWP 7436) exited]

[Thread 0xb7cd9b70 (LWP 7435) exited]

Program exited with code 0177.

(gdb) backtrace

No stack.

(gdb)

[Ben Noordhuis]

Well, I can tell you're using at least one native add-on (hashlib) and
it's compiled against a different version of Node.

[Mark Hahn]

>  Well, I can tell you're using at least one native add-on (hashlib) and it's compiled against a different version of Node. 

While it would not at all be surprising that I've done something stupid, in this case I've never heard of anything called hashlib and I have never installed any native add-ons.  The directory I was compiling in came straight from the git clone cmd you gave me.  Each time I retry I do a rm -rf node in my root dir.

Could NVM be at fault somehow?  What can I do to chase down this mysterious hashlib?

[Mark Hahn]

I grepped my node source folder for hashlib and here is the result.  Can you tell me what this means?

TBGdev node > grep -ir hashlib .

grep: ./node: No such file or directory

./tools/wafadmin/Utils.py:                      from hashlib import md5

./tools/wafadmin/Scripting.py:  try: from hashlib import sha1 as sha

./tools/gyp/pylib/gyp/MSVSNew.py:# hashlib is supplied as of Python 2.5 as the replacement interface for md5

./tools/gyp/pylib/gyp/MSVSNew.py:# and other secure hashes.  In 2.6, md5 is deprecated.  Import hashlib if

./tools/gyp/pylib/gyp/MSVSNew.py:  import hashlib

./tools/gyp/pylib/gyp/MSVSNew.py:  _new_md5 = hashlib.md5

./tools/gyp/pylib/gyp/xcodeproj_file.py:# hashlib is supplied as of Python 2.5 as the replacement interface for sha

./tools/gyp/pylib/gyp/xcodeproj_file.py:# and other secure hashes.  In 2.6, sha is deprecated.  Import hashlib if

./tools/gyp/pylib/gyp/xcodeproj_file.py:  import hashlib

./tools/gyp/pylib/gyp/xcodeproj_file.py:  _new_sha1 = hashlib.sha1

./deps/v8/tools/presubmit.py:  import hashlib

./deps/v8/tools/presubmit.py:  md5er = hashlib.md5