Re: [MonetDB-users] segfault with monetdb_sql().

newer
[MonetDB-users] Multiple core...

older
[MonetDB-users] (no subject)

Guillaume Yziquel

29 Dec 2009 29 Dec '09

10:13 a.m.

Martin Kersten a écrit :

...

...
...
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2aaaaf66d910 (LWP 4061)] 0x00002aaaac676de3 in findBox () from /usr/lib/libmonetdb5.so.5

i miss here the line number, seems that is ubunti specific you can do print i print box[i] print name

Providing debian packages of libraries with debugging symbols would be great.

...

i suspect box[i] is not properly initialized to 0

I'll try to check that.

...

...
...
(gdb) backtrace #0 0x00002aaaac676de3 in findBox () from /usr/lib/libmonetdb5.so.5 this gives one hint, it is likely passed without name causing idcmp to fail #1 0x00002aaaac677086 in openBox () from /usr/lib/libmonetdb5.so.5 #2 0x00002aaab7a51cbb in MTIMEprelude () from

happens while loading the data/time module. It initializes the "time" module

Should I assume that the mtime.mal + lib_mtime.so is the first one to be loaded? Just to know if some dynamic linking successfully happened before or not.

...

...
...
/usr/lib/MonetDB5/lib/lib_mtime.so #3 0x00002aaaac6826cf in ?? () from /usr/lib/libmonetdb5.so.5 #4 0x00002aaaac68b2a0 in runMAL () from /usr/lib/libmonetdb5.so.5 #5 0x00002aaaac67cac7 in MALengine () from /usr/lib/libmonetdb5.so.5 #6 0x00002aaaac67d5f6 in malBootstrap () from /usr/lib/libmonetdb5.so.5 #7 0x00002aaaac669f75 in mal_init () from /usr/lib/libmonetdb5.so.5 #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)

Please tell me what else could be useful.

This was already useful, because i added two additional defense lines to capture improperly set environments.

OK. I'll check.

...

...
...
I am not an CAML expert, but i guess there may be potential issues in location and dynamic loading of the necessary libraries. Where does CAML get the libraries from?

As a rather general statement, dynamic loading is supported within OCaml world. I'm not so sure how this works when it is C code that triggers dynamic loading, with OCaml in bytecode mode...

I have added some extra code to make failing loads more visible. In general, it seems that the modules are not found at the location

I'll ask on the OCaml list for that.

...

...
I would like to pinpoint the segfault more precisely in order to go back to the OCaml mailing list about potential dynamic loading issues. I think it can not find your libraries

set the variable gdk_debug=10 this will show you the environment settings as seen upon start. Including the location where it expect database and libraries to recide.

Will do that. However, I believe it is not a problem of location, as this works out fine when the OCaml binding is compiled to native code. All the best, -- Guillaume Yziquel http://yziquel.homelinux.org/

Show replies by date

Martin Kersten

29 Dec 29 Dec

10:49 a.m.

New subject: [MonetDB-users] segfault with monetdb_sql().

Guillaume Yziquel wrote:

...

Martin Kersten a écrit :

...
...
...
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2aaaaf66d910 (LWP 4061)] 0x00002aaaac676de3 in findBox () from /usr/lib/libmonetdb5.so.5

i miss here the line number, seems that is ubunti specific you can do print i print box[i] print name

Providing debian packages of libraries with debugging symbols would be great. For that we provide the super-source tarball which contains all the sourcecode needed to undertake the actions you are embarking upon.

...
i suspect box[i] is not properly initialized to 0

I'll try to check that.

...
...
...
(gdb) backtrace #0 0x00002aaaac676de3 in findBox () from /usr/lib/libmonetdb5.so.5 this gives one hint, it is likely passed without name causing idcmp to fail #1 0x00002aaaac677086 in openBox () from /usr/lib/libmonetdb5.so.5 #2 0x00002aaab7a51cbb in MTIMEprelude () from

happens while loading the data/time module. It initializes the "time" module

Should I assume that the mtime.mal + lib_mtime.so is the first one to be loaded? Just to know if some dynamic linking successfully happened before or not. no. it is not the first one. For that you have to breakpoint on loadLibrary.

...

...
...
...
/usr/lib/MonetDB5/lib/lib_mtime.so #3 0x00002aaaac6826cf in ?? () from /usr/lib/libmonetdb5.so.5 #4 0x00002aaaac68b2a0 in runMAL () from /usr/lib/libmonetdb5.so.5 #5 0x00002aaaac67cac7 in MALengine () from /usr/lib/libmonetdb5.so.5 #6 0x00002aaaac67d5f6 in malBootstrap () from /usr/lib/libmonetdb5.so.5 #7 0x00002aaaac669f75 in mal_init () from /usr/lib/libmonetdb5.so.5 #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)

Please tell me what else could be useful.

This was already useful, because i added two additional defense lines to capture improperly set environments.

OK. I'll check.

...
...
...
I am not an CAML expert, but i guess there may be potential issues in location and dynamic loading of the necessary libraries. Where does CAML get the libraries from?

As a rather general statement, dynamic loading is supported within OCaml world. I'm not so sure how this works when it is C code that triggers dynamic loading, with OCaml in bytecode mode...

I have added some extra code to make failing loads more visible. In general, it seems that the modules are not found at the location

I'll ask on the OCaml list for that.

I think you really should involve an OCaml programmer with C experience to embark upon this track. And follow the suggested implementation steps, i.e. first linking in the mapilibrary. That is ultimately the interaction between OCaml and the server. Any entanglement at a lower level, e.g. the column store, calls for really strong C programming expertise. The estimate time for the former is a few weaks, the latter may easily take a year to do it properly.

...

...
...
I would like to pinpoint the segfault more precisely in order to go back to the OCaml mailing list about potential dynamic loading issues. I think it can not find your libraries

set the variable gdk_debug=10 this will show you the environment settings as seen upon start. Including the location where it expect database and libraries to recide.

Will do that. However, I believe it is not a problem of location, as this works out fine when the OCaml binding is compiled to native code.

Programming is like mathematics not based on belief, but finding proofs using the proper tools and analysis steps. I have seen no proof that the MonetDB modules are properly loaded yet, nor if you have set the environment paths correctly. And then I ignore possible low level interferences (e.g.malloc) that might occur when linking two systems this way. The action described sofar are really basic steps towards C programming and testing. regards, Martin

...

All the best,

Guillaume Yziquel

12:16 p.m.

New subject: [MonetDB-users] segfault with monetdb_sql().

Martin Kersten a écrit :

...

...
Providing debian packages of libraries with debugging symbols would be great.

For that we provide the super-source tarball which contains all the sourcecode needed to undertake the actions you are embarking upon.

OK. I'll patch the Debian packages to do that. I already did something similar for Debian packages of R.

...

...
Should I assume that the mtime.mal + lib_mtime.so is the first one to be loaded? Just to know if some dynamic linking successfully happened before or not.

no. it is not the first one. For that you have to breakpoint on loadLibrary.

Thanks. Will do.

...

I think you really should involve an OCaml programmer with C experience to embark upon this track. And follow the suggested implementation steps, i.e. first linking in the mapilibrary. That is ultimately the interaction between OCaml and the server. Any entanglement at a lower level, e.g. the column store, calls for really strong C programming expertise. The estimate time for the former is a few weaks, the latter may easily take a year to do it properly.

Hmmm.. no. Reasons are: I want to do it myself. OCaml programmer with C experience willing to work on MonetDB are quite scarce. And I'm not necessarily the worst when it comes to OCaml/C/C++ interaction. For now, I have one priority: embedding MonetDB in OCaml bytecode. This is the bottleneck for what I want to do. I willing to postpone lower level stuff, but not the embedding.

...

...
Will do that. However, I believe it is not a problem of location, as this works out fine when the OCaml binding is compiled to native code.

Programming is like mathematics not based on belief, but finding proofs using the proper tools and analysis steps.

Yes. That's the learning curve I'm on, and I'm happy to do so. (But the act of doing mathematics is quite based on beliefs and intuitions, nonetheless...)

...

I have seen no proof that the MonetDB modules are properly loaded yet,

Indeed, there is yet no proof. Knowing the good tool to use to check that MonetDB modules are properly loaded, in the OCaml native code context, would be useful.

...

nor if you have set the environment paths correctly.

See the bottom of this email: http://markmail.org/message/rpv6ovrmsp3hsqi7

...

And then I ignore possible low level interferences (e.g.malloc) that might occur when linking two systems this way.

From the point of view of OCaml, there's no issue. There's an OCaml heap, on which OCaml does its own memory management and garbage collection. You can use malloc, allocating a pointer in the C heap, without interfering with the OCaml heap. When wrapping a pointer, you just have to make sure that you include a finaliser so that OCaml's garbage collector frees the mallocated space when the wrapping OCaml value goes out of scope. Nothing magic. Concerning threads, it's a bit more painful. But as long as you do not use the OCaml Thread library, you can do anything you want, including callbacks containing OCaml code. When you use the Thread library, you have to take care of OCaml's master lock when doing OCaml callbacks from C code. Nothing magic here either. Overall, OCaml is quite friendly to C code.

...

The action described sofar are really basic steps towards C programming and testing.

Yes. I reckon that C is not exactly my cup of tea. But if I've been able to embed the R interpreter into OCaml, with my load of segfaults and conflicting signal handling between OCaml and R, for instance, I believe I should be able to get something decent working at some point with this MonetDB binding. All the best, -- Guillaume Yziquel http://yziquel.homelinux.org/

Guillaume Yziquel

30 Dec 30 Dec

11:03 p.m.

New subject: [MonetDB-users] segfault with monetdb_sql().

Martin Kersten a écrit :

...

Guillaume Yziquel wrote:

...
Martin Kersten a écrit :

...
...
...
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2aaaaf66d910 (LWP 4061)] 0x00002aaaac676de3 in findBox () from /usr/lib/libmonetdb5.so.5

i miss here the line number, seems that is ubunti specific you can do print i print box[i] print name

Here it is:

...

(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)

And weirdly, when I run gdb on the native code version, I get the same values for i, box[i] and name, but it doesn't segfault at this specific point:

...

(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)

As for Debian packages with debugging symbols on amd64, you can find monetdb5-server-debug on my repository: http://yziquel.homelinux.org/debian/pool/main/m/monetdb5-server-debug/ Instructions, in french, for the repo, are here: http://yziquel.homelinux.org/topos/debian-repository.html By the way, please note that the Debian package of monetdb5-server does not compile properly with newer autoconfs. Autoconf 2.65 doesn't work fine. Updating the package to a newer autoconf or modifying the Build-Depends field to limit the version to 2.63 or lower would be a good idea. Moreover, the packages fail to build from source. If you already have binary packages installed, you can indeed recompile the source, but if you do not, you encounter problems with dpkg-shlibdeps / dh_shlibdeps. Such as:

...

dpkg-shlibdeps: erreur: impossible de trouver la bibliothèque libmonetdb5.so.5 demandée par debian/monetdb5-server-dbg/usr/bin/mserver5 (format ELF : « elf64-x86-64 », RPATH : « /usr/lib »). Note : les bibliothèques ne sont pas recherchées dans d'autres paquets binaires qui n'ont pas de fichier shlibs ou de fichier de symboles. Pour aider dpkg-shlibdeps à trouver des bibliothèques privées, vous devriez définir LD_LIBRARY_PATH. dh_shlibdeps: dpkg-shlibdeps -Tdebian/monetdb5-server-dbg.substvars debian/monetdb5-server-dbg/usr/bin/stethoscope debian/monetdb5-server-dbg/usr/bin/mserver5 debian/monetdb5-server-dbg/usr/bin/Mbeddedmal returned exit code 2 make: *** [binary-predeb-IMPL/monetdb5-server-dbg] Erreur 9 dpkg-buildpackage: erreur: fakeroot debian/rules binary a produit une erreur de sortie de type 2

So you have a problem compiling the package from source.

...

...
...
i suspect box[i] is not properly initialized to 0

Well, it seems that it is properly initialised to 0.

...

...
...
...
...
(gdb) backtrace #0 0x00002aaaac676de3 in findBox () from /usr/lib/libmonetdb5.so.5

this gives one hint, it is likely passed without name causing idcmp to fail

It seems that name has the value "time". Moreover, I do not exactly understand the meaning of the idcmp function. What's the big difference between idcmp and strcmp?

...

...
...
...
...
#1 0x00002aaaac677086 in openBox () from /usr/lib/libmonetdb5.so.5 #2 0x00002aaab7a51cbb in MTIMEprelude () from

happens while loading the data/time module. It initializes the "time" module

Should I assume that the mtime.mal + lib_mtime.so is the first one to be loaded? Just to know if some dynamic linking successfully happened before or not.

no. it is not the first one. For that you have to breakpoint on loadLibrary.

Here's the output for this breakpoint:

...

(gdb) break loadLibrary Function "loadLibrary" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (loadLibrary) pending. (gdb) run Starting program: /usr/bin/ocamlrun test/monetdb_sql.byte [Thread debugging using libthread_db enabled] [New Thread 0x2aaaaf670910 (LWP 24370)] [Switching to Thread 0x2aaaaf670910 (LWP 24370)]

Breakpoint 1, loadLibrary (filename=0x642dd8 "mdb", flag=1) at mal_linker.c:94 94 int mode = RTLD_NOW | RTLD_GLOBAL; (gdb) backtrace #0 loadLibrary (filename=0x642dd8 "mdb", flag=1) at mal_linker.c:94 #1 0x00002aaaac69f85d in parseLibrary (cntxt=0x2aaaac981000) at mal_parser.c:719 #2 0x00002aaaac6a9c98 in parseMAL (cntxt=0x2aaaac981000, curPrg=0x656a78) at mal_parser.c:3440 #3 0x00002aaaac67118b in malInclude (c=0x2aaaac981000, name=0x2aaaac6ce8e0 "mal_init", listing=0) at mal_import.c:87 #4 0x00002aaaac671f80 in malBootstrap () at mal_session.c:32 #5 0x00002aaaac662fa5 in mal_init () at mal.c:61 #6 0x00002aaaab91ef60 in ?? () from /usr/lib/libembeddedsql5.so #7 0x00002aaaab39b73a in start_thread () from /lib/libpthread.so.0 #8 0x00002aaaab67c69d in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () (gdb) info locals mode = 10922 nme = "\330-d\000\000\000\000\000\002\001\000\000\000\000\000\000\003\000\000\000\000\000\000\000\031\060紪*\000\000mdb\000\000\000\000\000H\372f\257\252*", '\000' , "\002\000\000\000\000\000\000`\016\220\253\252*\000\000\020\002\000\000\000\000\000\000P\372f\257\252*\000\000\000\000\000\000\000\000\000\000\003\000\000\000\000\000\000\000\240jb\253\252*\000\000H\334e\000\000\000\000\000\t\003g\253\252*\000\000\000\000\000\000\000\000\000\000\v", '\000' , " \327e\000\000\000\000\000\220\372f\257\252*\000\000 \327e\000\000\000\000\000\270\246\371\255\252*\000\000@\200̪\252*\000\000\003\000\000\000\000\000\000\000\227\352a\253\252*\000\000\300\360a\253\252*\000\000`\016\220\253\252*\000\000(\000\000\000\000\000\000\000\200X:\253\252*\000\000 `e\000\000\000\000\000@\200̪\252*\000\000"... handle = 0x2aaab4e7301a fullname = 0x2aaaaf66fdb0 "\360\375f\257\252*" s = 0x2aaaac69da19 "H\213E\350H\213\200`\001" idx = 0 errmsg = 0x102
(gdb) continue Continuing.

Breakpoint 1, loadLibrary (filename=0x65db48 "unix", flag=1) at mal_linker.c:94 94 int mode = RTLD_NOW | RTLD_GLOBAL; (gdb) Continuing.

Breakpoint 1, loadLibrary (filename=0x665de8 "lock", flag=1) at mal_linker.c:94 94 int mode = RTLD_NOW | RTLD_GLOBAL; (gdb) Continuing.

Breakpoint 1, loadLibrary (filename=0x67cfc8 "sema", flag=1) at mal_linker.c:94 94 int mode = RTLD_NOW | RTLD_GLOBAL; (gdb) Continuing.

[...]

Breakpoint 1, loadLibrary (filename=0xd0ef98 "opt_remoteQueries", flag=0) at mal_linker.c:94 94 int mode = RTLD_NOW | RTLD_GLOBAL; (gdb) Continuing.

Breakpoint 1, loadLibrary (filename=0xd0f8f8 "crackers", flag=0) at mal_linker.c:94 94 int mode = RTLD_NOW | RTLD_GLOBAL; (gdb) Continuing.

Program received signal SIGSEGV, Segmentation fault. 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)

So in the malBootstrap in mal_session.c, malInclude seems to work fine, and malEngine fails. However, I'm stll unsure about how to check that the libraries have been properly loaded.

...

...
...
...
I would like to pinpoint the segfault more precisely in order to go back to the OCaml mailing list about potential dynamic loading issues.

I think it can not find your libraries

How can I check that? Moreover, I'm quite surprise about the segfault I get, since box[i] is set to 0.

...

if (box[i] != NULL && idcmp(name, box[i]->name) == 0) {

As &&'s semantics are to evaluate the idcmp expression only when box[i] != NULL evaluates to true, there are two possibilities: -1- idcmp is called, which means that box[i] != NULL evaluates to true. As box[i] has value 0, this seems rather fishy. -2- idcmp is not called. But then I really wonder why an expression such as box[i] != NULL would segfault. However, when run on native code, we are in the same situation. But adressing box[i]->name would yield a segfault. Which does not occur. Therefore idcmp is not called in native code. I find this really curious.

...

...
...
set the variable gdk_debug=10 this will show you the environment settings as seen upon start. Including the location where it expect database and libraries to recide.

I've set gdk_debug=10 in /etc/monetdb5.conf. I checked that my code is called with this parameter. But I do not understand where I should look for debugging output.

...

...
Will do that. However, I believe it is not a problem of location, as this works out fine when the OCaml binding is compiled to native code.

Programming is like mathematics not based on belief, but finding proofs using the proper tools and analysis steps. I have seen no proof that the MonetDB modules are properly loaded yet,

For this, I do not know how to check. A hint would be welcome.

...

nor if you have set the environment paths correctly.

Here is the value with which GDKinit is called:

...

(gdb) break GDKinit Function "GDKinit" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (GDKinit) pending. (gdb) run Starting program: /usr/bin/ocamlrun test/monetdb_sql.byte [Thread debugging using libthread_db enabled] [New Thread 0x2aaaaf562910 (LWP 15715)] [Switching to Thread 0x2aaaaf562910 (LWP 15715)]

Breakpoint 1, GDKinit (set=0x659540, setlen=57) at gdk_utils.c:1440 warning: Source file is more recent than executable. 1440 char *dbname = mo_find_option(set, setlen, "gdk_dbname"); (gdb) p *set@setlen $1 = {{kind = opt_builtin, name = 0x642d10 "gdk_arch", value = 0x642d30 "64bitx86_64-pc-linux-gnu"}, {kind = opt_builtin, name = 0x642d60 "gdk_version", value = 0x642d80 "1.34.2"}, {kind = opt_builtin, name = 0x642da0 "prefix", value = 0x642dc0 "/usr"}, {kind = opt_builtin, name = 0x642de0 "exec_prefix", value = 0x6320d0 "${prefix}"}, {kind = opt_builtin, name = 0x6320f0 "gdk_dbname", value = 0x632110 "tst"}, {kind = opt_builtin, name = 0x632130 "gdk_dbfarm", value = 0x655880 "/var/MonetDB"}, {kind = opt_builtin, name = 0x6558a0 "gdk_debug", value = 0x6558c0 "8"}, {kind = opt_builtin, name = 0x6558e0 "gdk_alloc_map", value = 0x655900 "yes"}, {kind = opt_builtin, name = 0x655920 "gdk_vmtrim", value = 0x655940 "yes"}, {kind = opt_builtin, name = 0x655960 "monet_admin", value = 0x655980 "adm"}, {kind = opt_builtin, name = 0x6559a0 "monet_prompt", value = 0x6559c0 ">"}, {kind = opt_builtin, name = 0x6559e0 "monet_welcome", value = 0x655a00 "yes"}, {kind = opt_builtin, name = 0x655a20 "monet_mod_path", value = 0x655a40 "${exec_prefix}/lib/MonetDB"}, {kind = opt_builtin, name = 0x655a70 "monet_daemon", value = 0x655a90 "yes"}, {kind = opt_builtin, name = 0x655ab0 "host", value = 0x655ad0 "localhost"}, {kind = opt_builtin, name = 0x655af0 "mapi_port", value = 0x655b10 "50000"}, {kind = opt_builtin, name = 0x655b30 "mapi_noheaders", value = 0x655b50 "no"}, {kind = opt_builtin, name = 0x655b70 "mapi_debug", value = 0x655b90 "0"}, {kind = opt_builtin, name = 0x655bb0 "mapi_clients", value = 0x655bd0 "2"}, {kind = opt_builtin, name = 0x655bf0 "sql_debug", value = 0x655c10 "0"}, {kind = opt_builtin, name = 0x655c30 "standoff_ns", value = 0x655c50 "http://monetdb.cwi.nl/standoff"}, {kind = opt_builtin, name = 0x655c80 "standoff_start", value = 0x655ca0 "start"}, {kind = opt_builtin, name = 0x655cc0 "standoff_end", value = 0x655ce0 "end"}, { kind = opt_config, name = 0x642ae0 "prefix", value = 0x642b00 "/usr"}, {kind = opt_config, name = 0x642b20 "config", value = 0x642b40 "/etc/monetdb5.conf"}, {kind = opt_config, name = 0x642b60 "monet_mod_path", value = 0x642b80 "${exec_prefix}/lib/MonetDB5:${exec_prefix}/lib/MonetDB5/lib:${exec_prefix}/lib/MonetDB5/bin"}, { kind = opt_config, name = 0x642c10 "prefix", value = 0x642c30 "/usr"}, {kind = opt_config, name = 0x642c50 "exec_prefix", value = 0x642c70 "${prefix}"}, {kind = opt_config, name = 0x642c90 "gdk_dbfarm", value = 0x642cb0 "/var/MonetDB5/dbfarm"}, {kind = opt_config, name = 0x642cd0 "gdk_dbname", value = 0x642cf0 "demo"}, { kind = opt_config, name = 0x655d00 "gdk_alloc_map", value = 0x655d20 "no"}, {kind = opt_config, name = 0x655d40 "gdk_embedded", value = 0x655d60 "no"}, {kind = opt_config, name = 0x655d80 "gdk_debug", value = 0x655da0 "10"}, {kind = opt_config, name = 0x655dc0 "monet_mod_path", value = 0x655de0 "${exec_prefix}/lib/MonetDB5:${exec_prefix}/lib/MonetDB5/lib:${exec_prefix}/lib/MonetDB5/bin"}, {kind = opt_config, name = 0x655e50 "monet_daemon", value = 0x655e70 "no"}, {kind = opt_config, name = 0x655e90 "monet_welcome", value = 0x655eb0 "yes"}, {kind = opt_config, name = 0x655ed0 "mero_msglog", value = 0x655ef0 "/var/log/MonetDB/merovingian.log"}, {kind = opt_config, name = 0x655f20 "mero_errlog", value = 0x655f40 "/var/log/MonetDB/merovingian.log"}, {kind = opt_config, name = 0x656570 "mero_pidfile", value = 0x656590 "/var/run/MonetDB/merovingian.pid"}, {kind = opt_config, name = 0x6561c0 "mero_controlport", value = 0x6561e0 "50001"}, {kind = opt_config, name = 0x656200 "mal_init", value = 0x656220 "${exec_prefix}/lib/MonetDB5/mal_init.mal"}, {kind = opt_config, name = 0x656260 "mal_listing", value = 0x656280 "2"}, {kind = opt_config, name = 0x6562a0 "mapi_port", value = 0x6562c0 "50000"}, {kind = opt_config, name = 0x6562e0 "mapi_autosense", value = 0x656300 "false"}, {kind = opt_config, name = 0x656320 "mapi_open", value = 0x656340 "false"}, {kind = opt_config, name = 0x656360 "sql_optimizer", value = 0x656380 "default_pipe"}, {kind = opt_config, name = 0x6563a0 "default_pipe", value = 0x6563c0 "inline,remap,evaluate,costModel,coercions,emptySet,aliases,mergetable,deadcode,constants,commonTerms,joinPath,deadcode,reduce,garbageCollector,dataflow,history,multiplex"}, {kind = opt_config, name = 0x656480 "replication_pipe", value = 0x6564a0 "inline,remap,evaluate,costModel,coercions,emptySet,aliases,mergetable,deadcode,constants,commonTerms,joinPath,deadcode,reduce,garbageCollector,dataflow,history,replication,multiplex"}, {kind = opt_config, name = 0x656a60 "accumulator_pipe", value = 0x656a80 "inline,remap,evaluate,costModel,coercions,emptySet,aliases,mergetable,deadcode,constants,commonTerms,joinPath,deadcode,reduce,accumulators,garbageCollector,dataflow,history,multiplex"}, {kind = opt_config, name = 0x6565c0 "recycler_pipe", value = 0x6565e0 "inline,remap,evaluate,costModel,coercions,emptySet,aliases,deadcode,constants,commonTerms,joinPath,deadcode,recycle,reduce,garbageCollector,dataflow,history,multiplex"}, {kind = opt_config, name = 0x656690 "cracker_pipe", value = 0x6566b0 "inline,remap,evaluate,costModel,coercions,emptySet,aliases,selcrack,deadcode,constants,commonTerms,joinPath,deadcode,reduce,garbageCollector,dataflow,history,multiplex"}, {kind = opt_config, name = 0x656760 "datacell_pipe", value = 0x656780 "inline,remap,evaluate,costModel,coercions,emptySet,aliases,deadcode,constants,commonTerms,joinPath,datacell,deadcode,reduce,garbageCollector,dataflow,history,multiplex"}, {kind = opt_config, name = 0x656830 "octopus_pipe", value = 0x656850 "inline,remap,evaluate,costModel,coercions,emptySet,mitosis,aliases,mergetable,deadcode,constants,commonTerms,joinPath,octopus,deadcode,reduce,garbageCollector,dataflow,history,multiplex"}, {kind = opt_config, name = 0x656920 "mitosis_pipe", value = 0x656940 "inline,remap,evaluate,costModel,coercions,emptySet,mitosis,aliases,mergetable,deadcode,constants,commonTerms,joinPath,reorder,deadcode,reduce,garbageCollector,dataflow,history,multiplex"}, {kind = opt_cmdline, name = 0x642bf0 "gdk_dbfarm", value = 0x656a10 "/home/yziquel/sandbox/monetdb"}, { kind = opt_cmdline, name = 0x656a40 "gdk_dbname", value = 0x655f80 "testdb"}, {kind = opt_cmdline, name = 0x656b40 "gdk_embedded", value = 0x656b60 "yes"}} (gdb)

I think I have already explained that the following issues (malloc, threads) are not a problem.

...

And then I ignore possible low level interferences (e.g.malloc) that might occur when linking two systems this way. The action described sofar are really basic steps towards C programming and testing.

All the best, -- Guillaume Yziquel http://yziquel.homelinux.org/

Guillaume Yziquel

2 Jan 2 Jan

4:49 a.m.

New subject: [MonetDB-users] segfault with monetdb_sql().

Guillaume Yziquel a écrit :

...

Martin Kersten a écrit :

...
Guillaume Yziquel wrote:

...
Martin Kersten a écrit :

...
...
...
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2aaaaf66d910 (LWP 4061)] 0x00002aaaac676de3 in findBox () from /usr/lib/libmonetdb5.so.5

The segfault happens in this line of the function findBox. And more specifically when evaluating box[i]->name.

...

...
89 if (box[i] != NULL && idcmp(name, box[i]->name) == 0) {

The disassembled code for function findBox (amd64, Linux) is:

...

Dump of assembler code for function findBox: 0x00002aaaac66c388 : push %rbp 0x00002aaaac66c389 : mov %rsp,%rbp 0x00002aaaac66c38c : sub $0x20,%rsp

Function prelude is just above.

...

0x00002aaaac66c390 : mov %rdi,-0x18(%rbp)

Stores the argument of the function into the stack. Here, a pointer to the string "time".

...

0x00002aaaac66c394 : mov 0x26d1d5(%rip),%rax # 0x2aaaac8d9570 0x00002aaaac66c39b : mov (%rax),%eax 0x00002aaaac66c39d : test %eax,%eax 0x00002aaaac66c39f : je 0x2aaaac66c3f7

This is a test on GDKprotected, and execution goes from here into the macro mal_set_lock. Doesn't seem to be a big deal. After the macro, execution goes to

...

0x00002aaaac66c3a1 : mov 0x26d288(%rip),%rax # 0x2aaaac8d9630 0x00002aaaac66c3a8 : mov (%rax),%eax 0x00002aaaac66c3aa : and $0x400,%eax 0x00002aaaac66c3af : test %eax,%eax 0x00002aaaac66c3b1 : je 0x2aaaac66c3eb 0x00002aaaac66c3b3 : mov 0x26d28e(%rip),%rax # 0x2aaaac8d9648 0x00002aaaac66c3ba : mov (%rax),%rdi 0x00002aaaac66c3bd : mov 0x26d17c(%rip),%rcx # 0x2aaaac8d9540 0x00002aaaac66c3c4 : lea 0x6202d(%rip),%rdx # 0x2aaaac6ce3f8 0x00002aaaac66c3cb : lea 0x61fd5(%rip),%rsi # 0x2aaaac6ce3a7 0x00002aaaac66c3d2 : mov $0x0,%eax 0x00002aaaac66c3d7 : callq 0x2aaaac662438 0x00002aaaac66c3dc : mov 0x26d265(%rip),%rax # 0x2aaaac8d9648 0x00002aaaac66c3e3 : mov (%rax),%rdi 0x00002aaaac66c3e6 : callq 0x2aaaac662038 0x00002aaaac66c3eb : mov 0x26d14e(%rip),%rdi # 0x2aaaac8d9540 0x00002aaaac66c3f2 : callq 0x2aaaac662518

End of the mal_set_lock macro. And the two following lines are the beginning of the for() loop on i.

...

0x00002aaaac66c3f7 : movl $0x0,-0x4(%rbp) 0x00002aaaac66c3fe : jmpq 0x2aaaac66c4ba

After this line above, execution goes to but comes back very quickly to the line below.

...

0x00002aaaac66c403 : mov -0x4(%rbp),%eax 0x00002aaaac66c406 : mov 0x26d193(%rip),%rdx # 0x2aaaac8d95a0 0x00002aaaac66c40d : cltq 0x00002aaaac66c40f : mov (%rdx,%rax,8),%rax 0x00002aaaac66c413 : test %rax,%rax 0x00002aaaac66c416 : je 0x2aaaac66c4b6

Above is the expression 'box[i] != NULL'. As execution continues to the lines below, it seems that box[i] is indeed not NULL.

...

0x00002aaaac66c41c : mov -0x4(%rbp),%eax 0x00002aaaac66c41f : mov 0x26d17a(%rip),%rdx # 0x2aaaac8d95a0 0x00002aaaac66c426 : cltq 0x00002aaaac66c428 : mov (%rdx,%rax,8),%rax 0x00002aaaac66c42c : mov 0x28(%rax),%rsi

Segmentation fault happens at the line just above. We were just preparing the argument 'box[i]->name' for the idcmp function. (This segfault has been observed with ddd. I could not figure out how to get gdb to step into machine code instruction from its command line.)

...

0x00002aaaac66c430 : mov -0x18(%rbp),%rdi 0x00002aaaac66c434 : callq 0x2aaaac662b48

So:

...

...
...
...
i suspect box[i] is not properly initialized to 0

Well, it seems that it is properly initialised to 0.

and 'print box[i]' misleadingly gave a '(Box) 0x0'... (that I still do not understand). So what does it mean, if box[i] is not properly initialised to 0? All the best, -- Guillaume Yziquel http://yziquel.homelinux.org/

5473

Age (days ago)

5477

Last active (days ago)

List overview

Download

4 comments

2 participants

participants (2)

Guillaume Yziquel
Martin Kersten