From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id CE180BC37 for ; Thu, 31 Dec 2009 00:50:46 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiADAD12O0tV2gB5h2dsb2JhbACDa5UegkcBAQEKCwgHFYg7pBeNa4Etgi5WBIkn X-IronPort-AV: E=Sophos;i="4.47,478,1257116400"; d="scan'208";a="40771792" Received: from emailfrontal2.citycable.ch ([85.218.0.121]) by mail3-smtp-sop.national.inria.fr with SMTP; 31 Dec 2009 00:50:46 +0100 Received: from [192.168.0.12] (unknown [85.218.92.99]) (Authenticated sender: guillaume.yziquel@citycable.ch) by emailfrontal2.citycable.ch (Postfix) with ESMTPA id 0EB0E8342D9; Thu, 31 Dec 2009 00:50:39 +0100 (CET) Message-ID: <4B3BE756.2000401@citycable.ch> Date: Thu, 31 Dec 2009 00:50:46 +0100 From: Guillaume Yziquel Reply-To: guillaume.yziquel@citycable.ch User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707) MIME-Version: 1.0 To: Jake Donham Cc: caml-list@inria.fr Subject: Re: [Caml-list] Wrapping C code using pthread. References: <4B352731.2060306@citycable.ch> <20091227114253.a0a9ff49.ygrekheretix@gmail.com> <4B3750D8.8000209@citycable.ch> <20091227232724.f95c1105.ygrekheretix@gmail.com> <4B37D2AD.5000600@citycable.ch> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; guillaume:01 guillaume:01 gdb:01 bytecode:01 segfault:01 gdb:01 ocamlrun:01 bytecode:01 -custom:01 ocamlrun:01 cvs:01 ifdef:01 printf:01 unset:01 unset:01 Jake Donham a =C3=A9crit : > On Sun, Dec 27, 2009 at 1:33 PM, Guillaume Yziquel > wrote: > >> If someone knows how to use gdb on a bytecode executable to locate the >> segfault in MonetDB's .so file, I'd be quite happy to know. >=20 > You can just gdb ocamlrun, then run with the bytecode file as > argument. (Assuming you are not building in -custom mode.) Thanks Jake. For the record, here is the last mail I sent on the MonetDB users=20 mailing list on this topic: http://sourceforge.net/mailarchive/forum.php?thread_name=3D4B3BDC5E.10801= %40citycable.ch&forum_name=3Dmonetdb-users I encountered a weird issue while running gdb --args ocamlrun, which=20 doesn't appear in native code. Here is the binded C source code in which=20 gdb steps into: Line 330 of mal_box.mx, available at http://monetdb.cvs.sourceforge.net/viewvc/monetdb/MonetDB5/src/mal/mal_bo= x.mx?revision=3D1.101&view=3Dmarkup You got this function > 322 Box > 323 findBox(str name) > 324 { > 325 int i; > 326=20 > 327 mal_set_lock(mal_contextLock, "findBox"); > 328=20 > 329 for (i =3D 0; i < MAXSPACES; i++) > 330 if (box[i] !=3D NULL && name && idcmp(name, box[i]->name) =3D=3D= 0) { > 331 #ifdef DEBUG_MAL_BOX > 332 stream_printf(GDKout, "found the box '%s' %d\n", name, i); > 333 #endif > 334 mal_unset_lock(mal_contextLock, "findBox"); > 335 return box[i]; > 336 } > 337 mal_unset_lock(mal_contextLock, "findBox"); > 338 #ifdef DEBUG_MAL_BOX > 339 stream_printf(GDKout, "could not find the box '%s' \n", name); > 340 #endif > 341 return 0; > 342=20 > 343 } And gdb complains with bytecode OCaml. Segfault. > (gdb) run > Starting program: /usr/bin/ocamlrun test/monetdb_sql.byte > [Thread debugging using libthread_db enabled] > [New Thread 0x2aaaaf670910 (LWP 23863)] >=20 > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x2aaaaf670910 (LWP 23863)] > 0x00002aaaac66c42c in findBox (name=3D0x2aaab7ac6a37 "time") at mal_box= .c:89 > 89 if (box[i] !=3D NULL && idcmp(name, box[i]->name) =3D=3D = 0) { > (gdb) backtrace > #0 0x00002aaaac66c42c in findBox (name=3D0x2aaab7ac6a37 "time") at mal= _box.c:89 > #1 0x00002aaaac66c54a in openBox (name=3D0x2aaab7ac6a37 "time") at mal= _box.c:107 > #2 0x00002aaab7ac03b4 in MTIMEprelude () at mtime.c:2147 > #3 0x00002aaaac67e7f6 in runMALsequence (cntxt=3D0x2aaaac981000, mb=3D= 0x669348, startpc=3D1, stoppc=3D0, stk=3D0x2aaaaf66fb80, env=3D0x0, p= cicaller=3D0x0) at mal_interpreter.c:3260 > #4 0x00002aaaac67443a in runMAL (cntxt=3D0x2aaaac981000, mb=3D0x669348= , startpc=3D1, mbcaller=3D0x0, env=3D0x0, pcicaller=3D0x0) > at mal_interpreter.c:272 > #5 0x00002aaaac6738b7 in MALengine (c=3D0x2aaaac981000) at mal_session= .c:580 > #6 0x00002aaaac671fdb in malBootstrap () at mal_session.c:37 > #7 0x00002aaaac662fa5 in mal_init () at mal.c:61 > #8 0x00002aaaab91ef60 in ?? () from /usr/lib/libembeddedsql5.so > #9 0x00002aaaab39b73a in start_thread () from /lib/libpthread.so.0 > #10 0x00002aaaab67c69d in clone () from /lib/libc.so.6 > #11 0x0000000000000000 in ?? () > (gdb) print i > $1 =3D 0 > (gdb) print box[i] > $2 =3D (Box) 0x0 > (gdb) print name > $3 =3D (str) 0x2aaab7ac6a37 "time" > (gdb) But in native code, it works quite well: > (gdb) break findBox > Function "findBox" not defined. > Make breakpoint pending on future shared library load? (y or [n]) y > Breakpoint 1 (findBox) pending. > (gdb) run > Starting program: /home/yziquel/git/ocaml-monetdb5/test/monetdb_sql.nat= ive [Thread debugging using libthread_db enabled] > [New Thread 0x2aaaaf467910 (LWP 15910)] > [Switching to Thread 0x2aaaaf467910 (LWP 15910)] >=20 > Breakpoint 1, findBox (name=3D0x2aaab78bda37 "time") at mal_box.c:86 > 86 mal_set_lock(mal_contextLock, "findBox"); > (gdb) info locals > i =3D 10922 > (gdb) step > 88 for (i =3D 0; i < MAXSPACES; i++) > (gdb) info locals > i =3D 10922 > (gdb) step > 89 if (box[i] !=3D NULL && idcmp(name, box[i]->name) =3D=3D = 0) { > (gdb) info locals > i =3D 0 > (gdb) print i > $1 =3D 0 > (gdb) print box[i] > $2 =3D (Box) 0x0 > (gdb) step > 88 for (i =3D 0; i < MAXSPACES; i++) > (gdb) print name > $3 =3D (str) 0x2aaab78bda37 "time" > (gdb) What's weird is the context seems to be exactly the same: i=3D0, box[i]=3D= 0,=20 and name=3D"time". The segfault happens, as I believe, when doing the comparison box[i] !=3D NULL I'm quite baffled by a segfault on such an expression, as box[i] seems=20 to be valid memory. Enlightenment would be highly appreciated. For some context, there are some pthreads going on and some dynamic=20 loading. But it hardly seems to be the issue. All the best, --=20 Guillaume Yziquel http://yziquel.homelinux.org/