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/
