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/