Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 1B6DA200C02 for ; Fri, 6 Jan 2017 02:20:53 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 185DC160B42; Fri, 6 Jan 2017 01:20:53 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 5E604160B33 for ; Fri, 6 Jan 2017 02:20:52 +0100 (CET) Received: (qmail 21491 invoked by uid 500); 6 Jan 2017 01:20:51 -0000 Mailing-List: contact user-help@lucy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@lucy.apache.org Delivered-To: mailing list user@lucy.apache.org Received: (qmail 21474 invoked by uid 99); 6 Jan 2017 01:20:51 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Jan 2017 01:20:51 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id CE9951A7BB1 for ; Fri, 6 Jan 2017 01:20:50 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.679 X-Spam-Level: * X-Spam-Status: No, score=1.679 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id kmr7e4hyTUAT for ; Fri, 6 Jan 2017 01:20:49 +0000 (UTC) Received: from mail-it0-f51.google.com (mail-it0-f51.google.com [209.85.214.51]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 13DEC5F286 for ; Fri, 6 Jan 2017 01:20:49 +0000 (UTC) Received: by mail-it0-f51.google.com with SMTP id x2so2004795itf.1 for ; Thu, 05 Jan 2017 17:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ubQEp2czGMzAu4wjm1kKlTje5eVcDrOXhSnXjJrzgpo=; b=gmQrsCix0CxgHRjjW10AiNFBNfCgdC9n46guIEjEI7Gn/zQywJ2D4YoUozwo3IwkuP 1jZBmAqPHNmrpXm0AhdZFKyRZd+p+X8kQvPgaKbLALz6PPQFq0w0sPBaRY3wFKw8DhUV m+nFGg324ZippyvKCieyE2+p7sHfIuikhiVAtW7D+y61s/3/e9hIinnEvd54G8vBI17B u5+lJKVSrid+0gemy2tqxQk8fuNcdlbyA4JFPczIUK1C5i1ZhjlZ8xP7NVf6NA88qyL1 9uoHOOz0KWlcGsKdoHEv4vVgeJTRSg88VivXm7vF7DAvpAbjPVkkb6r7vHUsRMpd1oL2 JbFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ubQEp2czGMzAu4wjm1kKlTje5eVcDrOXhSnXjJrzgpo=; b=aCS8b72L5b8X4ciVSooT5sp5repN5+ihEy12i0BSPFehyS/LY6+OB15U766A5WdRuz JQiGqIBJ05cGs8Kg9QsaPzp2U276H6jJuMWYwn1HrAWiTpI15w4Yq6FjCp4ArNH7QV3t jmAUGEhUrIBZiorLIYpg2XbzrBwsjdluy/QXe7ldanTe9A5w3r1wdq47vpwge2R4Bk8T 8G0P/8gxwLH0li/98sknNWWoElMiM83yc/FPBAhDJ9RZbR793XOuo8yeDoouRZ7tbY3Y 9P4VgE6999Qn+jAbzX/IhuLOtBb63kc7qlw0Q3DU/gZ886Wa9v1WfR5gS6LKoc1naPlH 8pIA== X-Gm-Message-State: AIkVDXKUL4k3l2DpNzayTujRlB7c0aVcvZIxDjHDcz+nugwF5KC1yJ3hA5RFm5ZnyGfYPg2crR9RhbhPlAHDDg== X-Received: by 10.36.197.198 with SMTP id f189mr588767itg.96.1483665645108; Thu, 05 Jan 2017 17:20:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.124.197 with HTTP; Thu, 5 Jan 2017 17:20:44 -0800 (PST) In-Reply-To: References: From: Serkan Mulayim Date: Thu, 5 Jan 2017 17:20:44 -0800 Message-ID: To: user@lucy.apache.org Content-Type: multipart/alternative; boundary=94eb2c07f7a0be0a00054562d3b9 Subject: [lucy-user] Re: C library - DECREFing PolySearcher archived-at: Fri, 06 Jan 2017 01:20:53 -0000 --94eb2c07f7a0be0a00054562d3b9 Content-Type: text/plain; charset=UTF-8 Sorry guys, 1 more update: when I build the app with -O2 and without -g, the issue is gone. This makes me think that there is something wrong with the timing, and related to threads. Just speculating :) On Thu, Jan 5, 2017 at 5:08 PM, Serkan Mulayim wrote: > Update: I can reproduce it with IndexSearcher too. Previously I had said > that it was only happening in PolySearcher... > > On Thu, Jan 5, 2017 at 4:31 PM, Serkan Mulayim > wrote: > >> Hi guys, >> >> I have a question regarding the searchers (PolySearcher and >> IndexSearcher). >> >> I wrote an application to do searching and indexing for 2 cases: 1- >> unified index(searched via IndexSearcher) 2- splitted index (there are >> around 12 indexes to be searched via PolySearcher). Both indexes have the >> same number of documents in total. >> >> In order to make the application simpler, for every search query I create >> the related searcher, do the search, and then close it (I do closing by >> DECREF). So basically a searcher is created and removed. >> >> For the queries that do not have any results, for the IndexSearcher, I do >> not see any issues. For the same query with Poly search, I receive the >> following LLDB output. If I wait in the LLDB with a breakpoint before >> DECREFing the PolySearcher this issue does not happen. >> >> Process 44678 stopped >> * thread #1: tid = 0x325b47, 0x0000000100004c0a >> test3searchs`cfish_dec_refcount(vself=0x0000000103abe060) + 10 at >> clownfish.c:100, queue = 'com.apple.main-thread', stop reason = >> EXC_BAD_ACCESS (code=1, address=0x28) >> frame #0: 0x0000000100004c0a test3searchs`cfish_dec_refcount(vself=0x0000000103abe060) >> + 10 at clownfish.c:100 >> 97 cfish_dec_refcount(void *vself) { >> 98 cfish_Obj *self = (Obj*)vself; >> 99 cfish_Class *klass = self->klass; >> -> 100 if (klass->flags & CFISH_fREFCOUNTSPECIAL) { >> 101 if (SI_immortal(klass)) { >> 102 return (uint32_t)self->refcount; >> 103 } >> >> >> I believe it is not directly related to the number of results returned. >> But something happens when we try to DECREF very quickly. I see that we >> need pthread. This makes me think that search and DECREF does not happen in >> the same thread, but I do not want to be confusing so no more comments >> regarding the threads :). >> >> Has anyone seen this issue? Do you have any suggestions? Is there a >> concern in creating a new searcher and destroying it by DECREF every time >> (other than a possible slowness)? Is there a better way to destroy a >> searcher? >> >> Thanks, >> Serkan >> >> > --94eb2c07f7a0be0a00054562d3b9--