Wrapping C code using pthread.

Wrapping C code using pthread.

[Guillaume Yziquel]

Hello.

I'm currently trying to wrap up together a C interface for the MonetDB5 
database system. I'm getting quite a lot of segfaults (a lot of which 
come from MonetDB itself), and I'm therefore wondering the following 
about pthreads and OCaml:

The server is started via a pthread:

pthread_create(&sqlthread, NULL, start_sql_server, (void *) server);

and I would like to know what kind of things I should look at with 
C-side pthreads in order to avoid segfaults...

All the best,

-- 
      Guillaume Yziquel
http://yziquel.homelinux.org/

Re: [Caml-list] Wrapping C code using pthread.

[ygrek]

On Fri, 25 Dec 2009 21:57:21 +0100
Guillaume Yziquel <guillaume.yziquel@citycable.ch> wrote:

> Hello.
> 
> I'm currently trying to wrap up together a C interface for the MonetDB5 
> database system. I'm getting quite a lot of segfaults (a lot of which 
> come from MonetDB itself), and I'm therefore wondering the following 
> about pthreads and OCaml:
> 
> The server is started via a pthread:
> 
> pthread_create(&sqlthread, NULL, start_sql_server, (void *) server);
> 
> and I would like to know what kind of things I should look at with 
> C-side pthreads in order to avoid segfaults...

How does the OCaml code gets executed? Via callbacks from this thread?
If so, have a look at http://caml.inria.fr/mantis/view.php?id=4702

-- 
 ygrek
 http://ygrek.org.ua

Re: [Caml-list] Wrapping C code using pthread.

[Guillaume Yziquel]

ygrek a écrit :
> On Fri, 25 Dec 2009 21:57:21 +0100
> Guillaume Yziquel <guillaume.yziquel@citycable.ch> wrote:
> 
>> Hello.
>>
>> I'm currently trying to wrap up together a C interface for the MonetDB5 
>> database system. I'm getting quite a lot of segfaults (a lot of which 
>> come from MonetDB itself), and I'm therefore wondering the following 
>> about pthreads and OCaml:
>>
>> The server is started via a pthread:
>>
>> pthread_create(&sqlthread, NULL, start_sql_server, (void *) server);
>>
>> and I would like to know what kind of things I should look at with 
>> C-side pthreads in order to avoid segfaults...
> 
> How does the OCaml code gets executed? Via callbacks from this thread?
> If so, have a look at http://caml.inria.fr/mantis/view.php?id=4702

Thanks for the pointer.

No this is not the case. In fact, it's a library that starts an embedded 
database server in its own pthread. Completely distinct from OCaml.

In fact, my trouble is that when things are compiled to native code, it 
works fine. However, things get screwed up when compiled to bytecode, 
resulting in a segfault.

Are pthreads compatible with OCaml bytecode?

All the best,

-- 
      Guillaume Yziquel
http://yziquel.homelinux.org/

Re: [Caml-list] Wrapping C code using pthread.

[ygrek]

On Sun, 27 Dec 2009 13:19:36 +0100
Guillaume Yziquel <guillaume.yziquel@citycable.ch> wrote:

> In fact, my trouble is that when things are compiled to native code, it 
> works fine. However, things get screwed up when compiled to bytecode, 
> resulting in a segfault.
> 
> Are pthreads compatible with OCaml bytecode?

I believe so. Could you post some code and instructions how to build for investigation?

-- 
 ygrek
 http://ygrek.org.ua

Re: [Caml-list] Wrapping C code using pthread.

[Guillaume Yziquel]

ygrek a écrit :
> On Sun, 27 Dec 2009 13:19:36 +0100
> Guillaume Yziquel <guillaume.yziquel@citycable.ch> wrote:
> 
>> In fact, my trouble is that when things are compiled to native code, it 
>> works fine. However, things get screwed up when compiled to bytecode, 
>> resulting in a segfault.
>>
>> Are pthreads compatible with OCaml bytecode?
> 
> I believe so. Could you post some code and instructions how to build for investigation?

I'm working on it. Will look at ocamlforge for this purpose.

I now think, however, that it's not a thread issue. MonetDB loads 
dynamically at startup some other libraries for its own low-level 
language, MAL (for MonetDB Assembly Language). I believe this kind of 
dynamic loading works fine in native code, but doesn't in bytecode.

I've got no issues in native code at all... Only with bytecode.

Haven't located the place in MonetDB where this dynamic loading happens, 
so it's just conjectures for now.

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.

All the best,

-- 
      Guillaume Yziquel
http://yziquel.homelinux.org/

Re: [Caml-list] Wrapping C code using pthread.

[Jake Donham]

On Sun, Dec 27, 2009 at 1:33 PM, Guillaume Yziquel
<guillaume.yziquel@citycable.ch> 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.

You can just gdb ocamlrun, then run with the bytecode file as
argument. (Assuming you are not building in -custom mode.)

Re: [Caml-list] Wrapping C code using pthread.

[Guillaume Yziquel]

Jake Donham a écrit :
> On Sun, Dec 27, 2009 at 1:33 PM, Guillaume Yziquel
> <guillaume.yziquel@citycable.ch> 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.
> 
> 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 
mailing list on this topic:

http://sourceforge.net/mailarchive/forum.php?thread_name=4B3BDC5E.10801%40citycable.ch&forum_name=monetdb-users

I encountered a weird issue while running gdb --args ocamlrun, which 
doesn't appear in native code. Here is the binded C source code in which 
gdb steps into: Line 330 of mal_box.mx, available at

http://monetdb.cvs.sourceforge.net/viewvc/monetdb/MonetDB5/src/mal/mal_box.mx?revision=1.101&view=markup

You got this function

>   322 Box
>   323 findBox(str name)
>   324 {
>   325 	int i;
>   326 
>   327 	mal_set_lock(mal_contextLock, "findBox");
>   328 
>   329 	for (i = 0; i < MAXSPACES; i++)
>   330 		if (box[i] != NULL && name && idcmp(name, box[i]->name) == 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 
>   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)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x2aaaaf670910 (LWP 23863)]
> 0x00002aaaac66c42c in findBox (name=0x2aaab7ac6a37 "time") at mal_box.c:89
> 89            if (box[i] != NULL && idcmp(name, box[i]->name) == 0) {
> (gdb) backtrace
> #0  0x00002aaaac66c42c in findBox (name=0x2aaab7ac6a37 "time") at mal_box.c:89
> #1  0x00002aaaac66c54a in openBox (name=0x2aaab7ac6a37 "time") at mal_box.c:107
> #2  0x00002aaab7ac03b4 in MTIMEprelude () at mtime.c:2147
> #3  0x00002aaaac67e7f6 in runMALsequence (cntxt=0x2aaaac981000, mb=0x669348, startpc=1, stoppc=0, stk=0x2aaaaf66fb80,     env=0x0, pcicaller=0x0) at mal_interpreter.c:3260
> #4  0x00002aaaac67443a in runMAL (cntxt=0x2aaaac981000, mb=0x669348, startpc=1, mbcaller=0x0, env=0x0, pcicaller=0x0)
>     at mal_interpreter.c:272
> #5  0x00002aaaac6738b7 in MALengine (c=0x2aaaac981000) 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 = 0
> (gdb) print box[i]
> $2 = (Box) 0x0
> (gdb) print name
> $3 = (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.native [Thread debugging using libthread_db enabled]
> [New Thread 0x2aaaaf467910 (LWP 15910)]
> [Switching to Thread 0x2aaaaf467910 (LWP 15910)]
> 
> Breakpoint 1, findBox (name=0x2aaab78bda37 "time") at mal_box.c:86
> 86        mal_set_lock(mal_contextLock, "findBox");
> (gdb) info locals
> i = 10922
> (gdb) step
> 88        for (i = 0; i < MAXSPACES; i++)
> (gdb) info locals
> i = 10922
> (gdb) step
> 89            if (box[i] != NULL && idcmp(name, box[i]->name) == 0) {
> (gdb) info locals
> i = 0
> (gdb) print i
> $1 = 0
> (gdb) print box[i]
> $2 = (Box) 0x0
> (gdb) step
> 88        for (i = 0; i < MAXSPACES; i++)
> (gdb) print name
> $3 = (str) 0x2aaab78bda37 "time"
> (gdb)

What's weird is the context seems to be exactly the same: i=0, box[i]=0, 
and name="time".

The segfault happens, as I believe, when doing the comparison

	box[i] != NULL

I'm quite baffled by a segfault on such an expression, as box[i] seems 
to be valid memory. Enlightenment would be highly appreciated.

For some context, there are some pthreads going on and some dynamic 
loading. But it hardly seems to be the issue.

All the best,

-- 
      Guillaume Yziquel
http://yziquel.homelinux.org/