Hi,
Sometimes I get !MALException:setScenario:Scenario not initialized 'sql'
from the server when I try to start it in scenarios that usually work
without any problems. I can't reproduce it consistently, but sometimes I get
it. What does this exception mean?
Thanks.
--
View this message in context: http://www.nabble.com/Meaning-of%3A-Scenario-not-initialized-%27sql%27-tp26…
Sent from the monetdb-users mailing list archive at Nabble.com.
Hi,
I've installed monetdb on *Ubuntu 9.04 Server* with apt-get. These are
the contents of php client
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/php5-monetdb-client
/usr/share/doc/php5-monetdb-client/changelog.Debian.gz
/usr/share/doc/php5-monetdb-client/copyright
I need the moduels, where are they? Thanks. Dariusz.
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/
Hi everybody,
Forgive the reference to a cartoon, but it seems strangely on topic ...
>There's a wonderful comic strip on the web called xkcd; I don't know if
you've heard of it. I have to share this one with you. It's called
"Exploits of a mother":
>
>http://xkcd.com/327/
Happy New Year!
Zoltan Tomory
zoltan.tomory(a)mobot.org
Hello.
As some discussion had gone off-list, here's some relevant background:
The OCaml binding works when the OCaml library is compiled to native
code, and it segfaults when the OCaml library is compiled to bytecode.
Martin Kersten a écrit :
>
> What is the gdb stack trace of the processes involved? segfaults are only
> analysed that way.
Quite new to gdb, so I do not know if this is what you've asked for:
> gdb --args ocamlrun test/monetdb_sql.byte
> GNU gdb (GDB) 7.0-debian
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/bin/ocamlrun...(no debugging symbols found)...done.
> (gdb) run
> Starting program: /usr/bin/ocamlrun test/monetdb_sql.byte
> [Thread debugging using libthread_db enabled]
> [New Thread 0x2aaaaf66d910 (LWP 4061)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x2aaaaf66d910 (LWP 4061)]
> 0x00002aaaac676de3 in findBox () from /usr/lib/libmonetdb5.so.5
> (gdb) backtrace
> #0 0x00002aaaac676de3 in findBox () from /usr/lib/libmonetdb5.so.5
> #1 0x00002aaaac677086 in openBox () from /usr/lib/libmonetdb5.so.5
> #2 0x00002aaab7a51cbb in MTIMEprelude () from /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.
> 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 would like to pinpoint the segfault more precisely in order to go back
to the OCaml mailing list about potential dynamic loading issues.
> We can help (on Xmas days) only with proper output. The level of
> programming
> calls for expertise in dealing with C debuggers, dynamic loaders, and
> thread
> management. Guessing does not bring us further. You have to use the
> right tools.
OK. This is always a good opportunity to learn more about C world...
Thanks for pointing out the right tools.
All the best,
--
Guillaume Yziquel
http://yziquel.homelinux.org/
Hi,
I'm trying to install monetdb in my Linux Ubuntu 9.10 Karmik and have
followed the instructions but have this dependency problem:
monetdb-geom-dev: Depends: libmonetdb5-geom0 not installable
monetdb-testing: Depends: python-monetdb not installable
Regards
Rui Anastácio
Hi,
I have the following issue; I would like to update a new column with
respect to old data.
In essence this would be the idea that I want to do:
update anbikvk set intrekking = (select intrekking from anbi_update
where anbi_update.naam = anbikvk.naam);
The above way does not work, the only other way that I would know would
involve a temporary table. Could anyone elaborate how this is possible
using the update statement?
Stefan
Hello.
I've been having segfaults when using the following wrapper code. (Do
not pay attention to the CAML* macros, and String_val is a macro that
converts a string in OCaml to a C string, and Val_ptr is a function that
wraps up a pointer into OCaml.)
> CAMLprim value ml_monetdb_sql (value ml_dbfarm, value ml_dbname) {
> CAMLparam2(ml_dbfarm, ml_dbname);
> CAMLlocal1(result);
> char * dbfarm;
> char * dbname;
> dbfarm = String_val(ml_dbfarm);
> dbname = String_val(ml_dbname);
> Mapi mapi = monetdb_sql(dbfarm, dbname);
> result = Val_ptr(mapi);
> CAMLreturn(result);
> }
I'm calling this code with dbfarm and dbname set to a place I can write
to, and that does not contain folders, files, or data at the time the
function is called from OCaml code.
When executing the following piece of code from the OCaml toplevel
> #use "topfind";;
> #thread;;
> #load "monetDB5.cma";;
>
> open MonetDB5;;
> let mapi = monetdb_sql "/home/yziquel/sandbox/monetdb" "testdb";;
I get a segfault arising from monetdb's shared libraries (I'm using the
Debian packages on a 64 bits platform):
> yziquel@seldon:~/git/ocaml-monetdb5$ ocaml -init ocamlinit
> Objective Caml version 3.11.1
>
> Findlib has been successfully loaded. Additional directives:
> #require "package";; to load a package
> #list;; to list the available packages
> #camlp4o;; to load camlp4 (standard syntax)
> #camlp4r;; to load camlp4 (revised syntax)
> #predicates "p,q,...";; to set these predicates
> Topfind.reset();; to force that packages will be reloaded
> #thread;; to enable threads
>
> /usr/lib/ocaml/threads: added to search path
> /usr/lib/ocaml/unix.cma: loaded
> /usr/lib/ocaml/threads/threads.cma: loaded
> Erreur de segmentation
Here at the last line...
Looking at the code in
monetdb-sql-2.34.2/src/backends/monet5/embeddedclient.c.in
I'm unable to determine if the segault comes from the invocation of
pthread_create or from the invocation of mapi_start_talking.
> Mapi
> monetdb_sql(char *dbfarm, char *dbname)
> {
> Mapi mid;
> pthread_t sqlthread;
> stream **server;
>
> int len = mo_builtin_settings(&embedded_set);
>
> /* needed, to prevent the MonetDB config file to be used */
> len = mo_add_option(&embedded_set, len, opt_config, "prefix", MONETDB5_PREFIX);
> len = mo_add_option(&embedded_set, len, opt_config, "config", MONETDB5_CONFFILE);
> len = mo_add_option(&embedded_set, len, opt_config, "monet_mod_path",
> "@QXlibdir@@QDIRSEP@MonetDB5@PATHSEP@@QXlibdir@@QDIRSEP@MonetDB5@QDIRSEP@lib@PATHSEP@@QXlibdir@@QDIRSEP@MonetDB5@QDIRSEP@bin");
>
> embedded_len = mo_system_config(&embedded_set, len);
> embedded_len = mo_add_option(&embedded_set, embedded_len, opt_cmdline, "gdk_dbfarm", dbfarm);
> embedded_len = mo_add_option(&embedded_set, embedded_len, opt_cmdline, "gdk_dbname", dbname);
>
> server = mapi_embedded_init(&mid,"sql");
>
> pthread_create(&sqlthread, NULL, start_sql_server, (void *) server);
>
> mapi_start_talking(mid);
>
> return mid;
> }
Could someone give me hints as to what is going wrong here?
All the best,
--
Guillaume Yziquel
http://yziquel.homelinux.org/
> Could you provide the query and schema?
CREATE TABLE STOCKINFO (
STOCK_ID INTEGER NOT NULL,
STOCK_CODE VARCHAR(30),
EX_CODE VARCHAR(30),
SH_CODE VARCHAR(30),
LONGNAME_CN VARCHAR(50),
SHORTNAME_CN VARCHAR(30),
EX_ID INTEGER NOT NULL,
CSRC_CAT INTEGER DEFAULT NULL,
SW_CAT INTEGER DEFAULT NULL,
SH_CAT INTEGER DEFAULT NULL,
HAS_DETAIL BOOLEAN DEFAULT NULL,
BG_CODE VARCHAR(20),
IPO_TIME DATE DEFAULT NULL,
BOARD_CAT INTEGER DEFAULT NULL,
IS_ST BOOLEAN DEFAULT NULL,
HAS_OPTION BOOLEAN DEFAULT NULL,
CURRENCY INTEGER DEFAULT NULL,
CARRY INTEGER DEFAULT NULL,
DECIMALS INTEGER DEFAULT NULL,
MIN_PRICE_CHANGE DOUBLE DEFAULT NULL,
STOCK_CAT INTEGER DEFAULT NULL,
SURGED_LIMIT DOUBLE DEFAULT NULL,
DECLINE_LIMIT DOUBLE DEFAULT NULL,
HIGH_52WK INTEGER DEFAULT NULL,
LOW_52WK INTEGER DEFAULT NULL
);
query:
SELECT STOCK_ID FROM STOCKINFO WHERE LOW_52WK<85 and HIGH_52WK>110 and
EX_ID=15 AND IPO_TIME>'2000-1-1' AND STOCK_CODE LIKE '1%';
I write a simple java program using 4 threads to execute this query
with a connection pool of 4 max active connections. The mserver5
process' memory increase steadily upto 2.5G, then the process crashes
with segmentation fault:(
I have noticed something special, when I run the query using :
ResultSet result = conn.prepareStatement(sql).executeQuery();
the monetdb5 server will consume large amount of memory and crash
definitely. However, when I query using:
ResultSet result = conn.createStatement().executeQuery(sql);
the server's memory usage is very stable.
This may indicate there's something wrong with the prepared statement
of the sql module of MonetDB5.
Below is my test program:
//////////////////////////////////////////////////////////
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.Date;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
import org.apache.commons.dbcp.BasicDataSource;
public class MonetBenchmark {
/**
* @param args
*/
public static void main(String[] args) {
ExecutorService executor = Executors.newFixedThreadPool(4);
final BasicDataSource dataSource = new BasicDataSource();
dataSource.setMaxActive(4);
dataSource.setInitialSize(4);
dataSource.setDriverClassName("nl.cwi.monetdb.jdbc.MonetDriver");
dataSource.setUrl("jdbc:monetdb://localhost/demo");
dataSource.setUsername("monetdb");
dataSource.setPassword("monetdb");
final String sql = "SELECT STOCK_ID FROM STOCKINFO WHERE LOW_52WK<85
and HIGH_52WK>110 and EX_ID=15 AND IPO_TIME>'2000-1-1' AND STOCK_CODE
LIKE '1%';";
System.out.println("running ... " + new Date());;
long start = System.currentTimeMillis();
int loop = 10000;
for (int x = 0; x < loop; x++) {
executor.submit(new Runnable() {
public void run() {
Connection conn = null;
try {
conn = dataSource.getConnection();
ResultSet rs = conn.createStatement().executeQuery(sql);
//using prepared statement will cause the server crashed with
segmentation fault and very big memory usage.
// ResultSet rs = conn.prepareStatement(sql).executeQuery();
while(rs.next()) {
//...
}
} catch (SQLException e) {
e.printStackTrace();
} finally {
try {
conn.close();
} catch (Exception e) {
}
}
}
});
}
try {
executor.shutdown();
executor.awaitTermination(5, TimeUnit.MINUTES);
} catch (InterruptedException e) {
e.printStackTrace();
}
long time = System.currentTimeMillis() - start;
System.out.println(time + " ms for " + loop + " times query! " +
(time / loop) + " ms/q");
}
}
And my last question, is this newest version of MonetDB suitable for
production use if I always use normal jdbc statement to execute my
query?
Thanks alot.