Node.js View Query Crashes Silently

Node.js SDK
1

Calling vew.query() crashes node.js process without error. The CB admin console stats show that the requests are being made, but the process exits before the callback function is called.

try {
var view = cb.view(“designDoc”, “viewName”, null);
view.query(null, function (err, viewResults) {

        });
    } catch (err) {
        console.log(err);
    }

I’m using Windows 7 / libcouchbase v2.1.3 / couchnode v1.0.0.

Is anyone else having this issue?

Update:
After building couchnode with debug info, I now get an assertion failure (see comment below) when calling a view. The call stack can be seen below

couchbase_impl.node!_free_dbg_nolock(void * pUserData, int nBlockUse) Line 1328 C++
couchbase_impl.node!_free_dbg(void * pUserData, int nBlockUse) Line 1265 C++
couchbase_impl.node!free(void * pUserData) Line 50 C++

couchbase_impl.node!free_bufinfo_common(lcb_buf_info * bi) Line 186 C
couchbase_impl.node!release_writebuf(lcb_io_opt_st * iobase, lcb_sockdata_st * sd, lcb_io_writebuf_st * buf) Line 412 C
libcouchbase.dll!000007feee4d1b4d() Unknown
couchbase_impl.node!write_callback(uv_write_s * req, int status) Line 436 C

The failed assert is checking CrtIsValidHeapPointer (windows function), and the pointer being passed to this is lcb_buf_info->ringbuffer (see plugin-libuv.c line 186). lcb_buf_info->root contains the request headers for the view request being made. The entire lcb_buf_info can be seen below:

  •   bi	0x000000000370aa68 {root=0x0000000000397f10 "GET /default/_design/SimUsers/_view/licenses_owned?limit=5 HTTP/1.1\r\nUser-Agent: libcouchbase/2.1.3\r\nConnection: close\r\nAccept: application/json\r\nHost: couchbase.winmachine:8092\r\n\r\n" ...}	lcb_buf_info *

  •   root	0x0000000000397f10 "GET /default/_design/SimUsers/_view/licenses_owned?limit=5 HTTP/1.1\r\nUser-Agent: libcouchbase/2.1.3\r\nConnection: close\r\nAccept: application/json\r\nHost: couchbase.winmachine:8092\r\n\r\n"	char *
  size	0	unsigned __int64
  ringbuffer	0x000000000032b2d0 {...}	ringbuffer_st *

  •   iov	0x000000000370aa80 {{iov_base=0x0000000000397f10 "GET /default/_design/SimUsers/_view/licenses_owned?limit=5 HTTP/1.1\r\nUser-Agent: libcouchbase/2.1.3\r\nConnection: close\r\nAccept: application/json\r\nHost: couchbase.winmachine:8092\r\n\r\n" ...}, ...}	lcb_iovec_st[2]

  •   [0]	{iov_base=0x0000000000397f10 "GET /default/_design/SimUsers/_view/licenses_owned?limit=5 HTTP/1.1\r\nUser-Agent: libcouchbase/2.1.3\r\nConnection: close\r\nAccept: application/json\r\nHost: couchbase.winmachine:8092\r\n\r\n" ...}	lcb_iovec_st

  •   [1]	{iov_base=0x0000000000397f10 "GET /default/_design/SimUsers/_view/licenses_owned?limit=5 HTTP/1.1\r\nUser-Agent: libcouchbase/2.1.3\r\nConnection: close\r\nAccept: application/json\r\nHost: couchbase.winmachine:8092\r\n\r\n" ...}	lcb_iovec_st

I’m starting to think that this may be a libcouchbase_2.1.3 issue and not a couchnode issue, but I’m not sure at this point. Maybe Brett or someone else on the couchnode team can better determine where the issue lies.

2

Unfortunately I am unable to reproduce this issue. I am using Windows 7 x64 with Visual Studio 2012. Node.js version v0.10.18. libcouchbase x64 2.1.3 downloaded from couchbase.com and placed in C:\couchbase. Couchnode 1.0.0 built from npm. For me, your example code above executes flawlessly (though I do have to swap out ‘designDoc’ and ‘viewName’ with views that I have available). Would you be able to provide any more details on the dataset that you are using as well as your view code? It may also be helpful to know what your build environment looks like.

Cheers, Brett

3

Also, same view code works fine when running node.js process on mac.

4

I was originally running 32bit node.js with libcoucbase_x86_vc10 when I first experienced this issue. I’ve since reinstalled node.js using the 64bit version and then installed couchnode with libcouchbase_amd64_vc11 (both couchnode installs were done via npm). The new environment did NOT solve the problem.

I’ve tried using the viewQuery class with and without options and using various (valid) designDoc/view pairs. The view syntax doesn’t seem to be a problem, though, since the http requests are completing successfully (see below).

The only thing that I’m doing that might be considered unconventional is that my dev couchbase server is on a mac. With that said, when I capture the tcp packets going through port 8092, I can see that the entire http response for the view query is being received from the server (plus get and sets work fine). So it seems that communication with the “cluster” is working properly.

Views were working properly with the old api (v0.0.12), not that it really matters since I’m sure that that code has been substantially gutted.

5

I just installed couchbase-server 2.1.1 on this windows machine and tried running the view query locally on this newly installed server, but I’m getting the same crash.

Let me know if there is any other info that I could give or things that I could try.

6

Okay, one last thing. I reinstalled couchnode with the --debug flag and now I get an assert when running a view query:

Programs: C:\Program Files\nodejs\node.exe
File: f:\dd\vctools\crt_bld\self_64_amd64\crt\src\dbgheap.c
Line: 1322

Expression: _CrtIsValidHeapPointer(pUserData)

Invalid pointer it seems, but I don’t have a call stack yet because I’m not sure how to debug a .dll without linking to it with another c++ app. I’m assuming that I’ll have to run node.exe in the debugger in order to do this. I’ll plan on giving that a try tomorrow morning and posting the results.

7

See update on OP.

8

May be you have same issue as I reported some time ago: http://www.couchbase.com/issues/browse/JSCBC-62

9

SkeLLLa, we are likely having the same issue.

If you comment out line 185 and 186 of “couchbaseDirectory\include\libcouchbase\plugins\io\libuv\plugin-libuv.c” and npm install couchbase with this edited source code, it will prevent views from crashing node.js.

//free(bi->root);
//free(bi->ringbuffer);

DO NOT DO THIS ON PRODUCTION MACHINES. Commenting these lines introduces a memory leak but may be useful if you are developing on Windows and deploying on Linux.