Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

Nodejs 0.5.10 and asynchronous addons #1920

Closed
pschumi opened this issue Oct 21, 2011 · 4 comments
Closed

Nodejs 0.5.10 and asynchronous addons #1920

pschumi opened this issue Oct 21, 2011 · 4 comments

Comments

@pschumi
Copy link

pschumi commented Oct 21, 2011

I wrote simple databse plugin that use eio to make asynchronous db queries. Plugin works fine with 0.4.12 but core dumps with 0.5.10xxx. I didn't find anything useful from documents so is there something that has changed or is it just a old plain bug ?-) I assume that my code is fine as I have removed all unneccessary and it still core dumps...and yes it works fine with old version.

Here is code. Program never reaches EIO_Query (core dump just after returning this function).

static Handle<Value> Query(const Arguments& args) {
    HandleScope scope;

    MyConnection *connection = ObjectWrap::Unwrap<MyConnection>(args.This());
    cout << "Query" << endl;

    if (args.Length() != 2) {
        return ThrowException(
                Exception::Error( String::New("Wrong number of arguments: [callback, query]")));
    }
    if (!args[0]->IsFunction() || !args[1]->IsString()) {
        return ThrowException(
                Exception::Error( String::New("Invalid query parameter types: [cb, string]")));
    }

    // Extract parameters
    Local<Function> cb = Local<Function>::Cast(args[0]);
    String::AsciiValue ascii(args[1]->ToString());
    string *persistent = new string(*ascii);

    query_t *holder = new query_t();
    holder->instance = connection;
    holder->sqlStmt  = (char*)persistent->c_str();
    holder->cb = Persistent<Function>::New(cb);

    connection->Ref();

    eio_custom(EIO_query, EIO_PRI_DEFAULT, EIO_afterQuery, holder);
    ev_ref(EV_DEFAULT_UC);
    cout << "PH1 "  << endl;

    return Undefined();
}
@bnoordhuis
Copy link
Member

You need to compile with EV_MULTIPLICITY=1 now.

@pschumi
Copy link
Author

pschumi commented Oct 24, 2011

I think that there is something else. I took update and build project with no success. Here is what I did. Fyi: I also tried this few days ago at saturday without success.

git pull origin master
...
Updating 00aa893..7ee29d1
....
make distclean
export EV_MULTIPLICITY=1
./configure --prefix=/opt/node
Checking for program g++ or c++ : /usr/bin/g++
Checking for program cpp : /usr/bin/cpp
Checking for program ar : /usr/bin/ar
Checking for program ranlib : /usr/bin/ranlib
Checking for g++ : ok
Checking for program gcc or cc : /usr/bin/gcc
Checking for gcc : ok
Checking for library dl : yes
Checking for openssl : yes
Checking for library util : yes
Checking for library rt : yes
Checking for CLOCK_MONOTONIC : yes
Checking for fdatasync(2) with c++ : yes
'configure' finished successfully (1.017s)

make -j2
make install

The went to addon project

node-waf configure clean build
npm install -g
node test.js .... and ... KABOOM with same symptoms.

@bnoordhuis
Copy link
Member

Sorry, EV_MULTIPLICITY=1 is a define. Think: gcc -DEV_MULTIPLICITY=1 -c foo.c

If you want to future-proof your module, switch to the libuv API. It should be relatively painless in your case, look for the uv_async_*() functions.

@pschumi
Copy link
Author

pschumi commented Oct 25, 2011

Sorry. It was just typo on my comment. I used """ export CXXFLAGS="export -DEV_MULTIPLICITY=1" """. At least compile time messages looked fine (-DEV_... added). But I'll check uv_async-module. Thank you for your tip.

richardlau pushed a commit to ibmruntimes/node that referenced this issue Sep 18, 2015
PR-URL: nodejs/node#1996

Notable changes

* module: The number of syscalls made during a require() have been
  significantly reduced again (see nodejs#1801 from v2.2.0 for previous
  work), which should lead to a performance improvement
  (Pierre Inglebert) nodejs#1920.
* npm:
  - Upgrade to v2.11.2 (Rebecca Turner) nodejs#1956.
  - Upgrade to v2.11.3 (Forrest L Norvell) nodejs#2018.
* zlib: A bug was discovered where the process would abort if the
  final part of a zlib decompression results in a buffer that would
  exceed the maximum length of 0x3fffffff bytes (~1GiB). This was
  likely to only occur during buffered decompression (rather than
  streaming). This is now fixed and will instead result in a thrown
  RangeError (Michaël Zasso) nodejs#1811.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants