incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <woh...@apache.org>
Subject Re: [jira] [Updated] (COUCHDB-982) [PATCH] couchdb won't work with debug version of spidermonkey
Date Sat, 01 Jun 2013 03:02:54 GMT
Nishimura-さん、

このメールでは、文字化けです。もう一度試すことはできますか?

ジョーン トゥーゼィ

On Wed, May 29, 2013 at 04:47:04PM -0700, Motokazu Nishimura wrote:
> ひまsたにくたggdslまなまはなぬきゆもむのりたひはまさもまねむにゆなゆやたややめみたきさむきめやちゃきらまめ^_^へれをーゃにまあ
> 
> 
> み
> —
> Motokazu Nishimura
> 
> 
> On 木, 5月 30, 2013 at 5:44 午前, Adam Kocoloski (JIRA) <jira@apache.org="mailto:jira@apache.org">>
wrote:
> [ https://issues.apache.org/jira/browse/COUCHDB-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
> 
> Adam Kocoloski updated COUCHDB-982:
> -----------------------------------
> 
>     Component/s:     (was: Database Core)
>                  JavaScript View Server
>     
> > [PATCH] couchdb won't work with debug version of spidermonkey
> > -------------------------------------------------------------
> >
> >                 Key: COUCHDB-982
> >                 URL: https://issues.apache.org/jira/browse/COUCHDB-982
> >             Project: CouchDB
> >          Issue Type: Bug
> >          Components: JavaScript View Server
> >    Affects Versions: 1.0.1
> >            Reporter: Petr Běhan
> >            Priority: Minor
> >
> > Steps to reproduce:
> > 1) configure spidermonkey with --enable-debug --enable-threadsafe and compile it
> > 2) make couchdb use it (in my case install it as system-wide library, or through
LD_LIBRARY_PATH)
> > 3) restart couchdb server
> > 4) attempt to query any view via http
> > Observed behaviour:
> > View query returns nothing, server pegs all CPUs, top shows nothing (spawned children
die too fast to register on top) and /var/log/couchdb/couch.log starts filling with lines
similar to "[Wed, 08 Dec 2010 21:59:37 GMT] [error] [<0.205.0>] OS Process Error <0.1056.0>
:: {os_process_error,{exit_status,134}}" at rate of about 70 errors per second (which itself
is a separate bug in my opinion, it should attempt to call the child once, and if it fails,
stop further attempts and notify client of http/500 error)
> > Problem is in incorrect use of JS_DestroyContext call. JSAPI documentation says
that the context being destroyed may or may not be inside active request. But it doesn't explicitly
mention that the calling thread MUST be set as current for the context. In src/couchdb/priv/couch_js/main.c,
the macro FINISH_REQUEST incorrectly calls JS_ClearContextThread, which is intended to TRANSFER
the context to another thread instead. The JS_DestroyContext call then triggers spidermonkey
assert.
> > Since "JS_NewContext automatically associates the new context with the calling thread.",
I think the thread stuff should be completely dropped from both SETUP_REQUEST and FINISH_REQUEST
macros and let spidermonkey take care of itself (unless there are plans to add threads to
couch_js in future). Following simple patch fixes couchdb on my system:
> > --- src/couchdb/priv/couch_js/main.c.orig       2010-12-09 00:40:40.000000000 +0100
> > +++ src/couchdb/priv/couch_js/main.c    2010-12-09 01:03:34.000000000 +0100
> > @@ -23,11 +23,9 @@
> >  #ifdef JS_THREADSAFE
> >  #define SETUP_REQUEST(cx) \
> > -    JS_SetContextThread(cx); \
> >      JS_BeginRequest(cx);
> >  #define FINISH_REQUEST(cx) \
> > -    JS_EndRequest(cx); \
> > -    JS_ClearContextThread(cx);
> > +    JS_EndRequest(cx);
> >  #else
> >  #define SETUP_REQUEST(cx)
> >  #define FINISH_REQUEST(cx)
> 
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira

-- 
Joan Touzet | joant@atypical.net | wohali everywhere else

Mime
View raw message