Date: 2003-11-12 05:22:46 +0100
From: Jens Teubner <>
To: Stefan Manegold <<Stefan.Manegold>>
Version: -- development

Last updated: 2003-11-27 09:14:10 +0100

Comment 135

Date: 2003-11-12 17:22:46 +0100
From: Jens Teubner <>

Build on SuSE 8.1 fails when --enable-optimize is set.

$ ./configure --prefix=/somewhere/MonetDB-4.3.14c
--enable-optimize
...
$ make
make all-recursive
make[1]: Entering directory /local_tmp/teubner2/MonetDB-4.3. 14c' Making all in src make[2]: Entering directory /local_tmp/teubner2/MonetDB-4.3.
14c/src'
Making all in utils
make[3]: Entering directory /local_tmp/teubner2/MonetDB-4.3. 14c/src/utils' Making all in Mx make[4]: Entering directory /local_tmp/teubner2/MonetDB-4.3.
14c/src/utils/Mx'
gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I. -O2 -Wall -W -O6
-fomit-frame-pointer -finline-functions -malign-loops=4
-malign-jumps=4 -malign-functions=4 -fexpensive-optimizations
-funroll-all-loops -funroll-loops -frerun-cse-after-loop
-frerun-loop-opt -Werror-implicit-function-declaration -Werror
-Wno-format -Wno-sign-compare -Wno-unused -DUNIX
-DMX_CXX_SUFFIX="cc" -c test -f 'Mx.c' || echo './'Mx.c
cc1: warnings being treated as errors
cc1: warning: -malign-loops is obsolete, use -falign-loops
cc1: warning: -malign-jumps is obsolete, use -falign-jumps
cc1: warning: -malign-functions is obsolete, use -falign-functions
make[4]: *** [Mx.o] Error 1
make[4]: Leaving directory /local_tmp/teubner2/MonetDB-4.3. 14c/src/utils/Mx' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory /local_tmp/teubner2/MonetDB-4.3.
14c/src/utils'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory /local_tmp/teubner2/MonetDB-4.3. 14c/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory /local_tmp/teubner2/MonetDB-4.3.
14c'
make: *** [all] Error 2

Compiler version is GCC 3.2 (coming with SuSE 8.1). Incorrectly
detected by configure?

Stefan has an account on our system. So he might want to
reproduce the problem himself here. Just log in to titan02.inf.
uni-konstanz.de. Under /local_tmp you can create as much data
as you like. Just untar 4.3.14c, run bootstrap and configure as
above. The make process fails at the first source file. Without
--enable-optimize everything's fine.

Comment 136

Date: 2003-11-27 21:14:10 +0100
From: @drstmane

Logged In: YES
user_id=572415

fixed conf/monet.m4 in main branch:

fixed extraction of the pure (GCC-) version number from $CC --version: trailing characters are optional.

GCC 3.2 on SuSE Linux 8.1 requires "-D_XOPEN_SOURCE=600"
instead of "-D_XOPEN_SOURCE=500" to define "__USE_XOPEN2K"
in /usr/include/features.h and hence activate the prototype
of gethostname in /usr/include/unistd.h .

Users of Monet_4-3-14_c that experienced the above problem
should apply the attached patch to conf/monet.m4 and
re-compile MonetDB (i.e., bootstrap, configure, make, make
install).

Comment 137

Date: 2005-10-06 13:51:50 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TESTed by COMPILATION

Comment 138

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 840797 at http://sourceforge.net/support/tracker.php?aid=840797

Date: 2003-12-03 10:08:53 +0100
From: @arjan
To: @njnes
Version: -- development

Last updated: 2003-12-03 06:17:47 +0100

Comment 189

Date: 2003-12-03 10:08:53 +0100
From: @arjan

latest (last night) checkout, using the queries below:

CREATE TABLE aap (id BLOB);
COMMIT;

DROP TABLE aap;
CREATE TABLE aap (id BLOB);

Crashes the server:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 49156 (LWP 965)]
0x4484db71 in validate_tables (s=0x8b452b8,
os=0x83bfbc8) at sql_mvc.mx:2270
2270 for (o =
t->columns.set->h, p = ot->columns.set- >h;
Current language: auto; currently c
(gdb) bt
0 0x4484db71 in validate_tables (s=0x8b452b8,
os=0x83bfbc8)
at sql_mvc.mx:2270
1 0x4484dc78 in validate (tr=0x8b38b10) at
sql_mvc.mx:2313
2 0x4484de53 in mvc_commit (m=0x8b38ad8, chain=0,
name=0x8bc5fb0 "")
at sql_mvc.mx:2368
3 0x447fd531 in mvc_commit_wrap (res=0x8b1a1e8,
m=0x0, chain=0x0, name=0x0)
at sql_server.mx:295
4 0x447facfb in mvc_commit_wrap_unpack608413784
(argc=4, argv=0x8bcd788)
at sql_server.glue.c:170
5 0x400369dd in interpret (stk=49, lt=0x81f0bc8,
res=0xbf3fb844)
at monet_interpreter.mx:960
6 0x400399be in interpret_assignment (stk=49,
lt=0x81ec5b0, res=0xbf3fb844)
at monet_interpreter.mx:1417
7 0x400358ba in interpret (stk=49, lt=0x81ec5b0,
res=0xbf3fb844)
at monet_interpreter.mx:589
8 0x40039cdd in interpret_seqblock (stk=49,
lt=0x81eee28, res=0xbf3fb844,
scope=1) at monet_interpreter.mx:1462
9 0x40035926 in interpret (stk=48, lt=0x81eee28,
res=0xbf3fb844)
at monet_interpreter.mx:596
10 0x40036e60 in interpret (stk=48, lt=0x81eba98,
res=0xbf3fb844)
at monet_interpreter.mx:946
11 0x447feb06 in backend_interpret (procstk=0,
name=0x0, args=0x0)
at sql_session.mx:199
---Type to continue, or q to quit---
12 0x447fef1c in sqlexecute (be=0x8bc4530,
out=0x8b39248, stk=4)
at sql_session.mx:348
13 0x447ff925 in sqlclient (stk=4, lt=0x2000,
res=0xbf3ffa84)
at sql_session.mx:526
14 0x40035f66 in interpret (stk=4, lt=0x81e9bf0,
res=0xbf3ffa84)
at monet_interpreter.mx:681
15 0x400452b0 in handleRequest (t=0x404deb5c,
q=0x8b45d78, res=0xbf3ffa84)
at monet_queue.mx:503
16 0x400456f0 in doRequest (t=0x404deb5c, preference=0x0)
at monet_queue.mx:527
17 0x400801ea in monetInterpreter (status=0xbf7fd290)
at monet_process.mx:115
18 0x404f2e31 in pthread_start_thread () from
/lib/libpthread.so.0
19 0x404f2eaf in pthread_start_thread_event () from
/lib/libpthread.so.0
20 0x4071930a in clone () from /lib/libc.so.6

Comment 190

Date: 2003-12-03 18:17:47 +0100
From: @njnes

Logged In: YES
user_id=43556

users of blobs needed to load the blob module
this is now allways done by sql_server module

Comment 191

Date: 2005-10-06 15:07:52 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
Test exists as src/test/big-example.sql

Comment 192

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 853148 at http://sourceforge.net/support/tracker.php?aid=853148

Date: 2002-10-15 10:58:05 +0200
From: @arjenpdevries
To: @njnes
Version: -- development

Last updated: 2002-10-18 10:33:19 +0200

Comment 11

Date: 2002-10-15 22:58:05 +0200
From: @arjenpdevries

set daemon mode (uncomment deamon=no in monet.conf);
start Mserver

it gives the error:
!ERROR: putRequest: nil request received

Comment 12

Date: 2002-10-15 22:59:14 +0200
From: @arjenpdevries

Logged In: YES
user_id=572978

BTW:
daemon is not spelled deamon, so that configuration setting
could be improved as well :)

(i.e., daemon=no ipv deamon=no)

Comment 13

Date: 2005-10-06 13:04:37 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: CLAIMED BY niels
BugDay_2005-10-06: Done/SUCCES
test script added as

tests/BugDay_2005-10-06_4.9.3/Tests/monet_daemon.SF-623743

Comment 14

Date: 2008-10-15 23:28:14 +0200
From: @skinkie

Does anyone have any interest in making --daemon=yes working?

Comment 15

Date: 2008-10-16 00:20:14 +0200
From: @drstmane

--set monet_daemon=yes works fine for me, so what is the/your problem?

Comment 16

Date: 2008-10-16 00:30:35 +0200
From: @skinkie

My problem is that I try to read documentation:

/opt/cherokee/bin/mserver5 --help
Usage: /opt/cherokee/bin/mserver5 [options] [scripts]
--daemon=yes|no run in background [no]

/opt/cherokee/bin/mserver5 --daemon=yes
MonetDB server v5.7.0, based on kernel v1.25.0
Serving database 'demo', using 2 threads
Compiled for x86_64-unknown-linux-gnu/64bit with 64bit OIDs dynamically linked
Copyright (c) 1993-2008 CWI, all rights reserved
Visit http://monetdb.cwi.nl/ for further information
warning: please don't forget to set your vault key!
(see /opt/cherokee/etc/monetdb5.conf)
Listening for connection requests on mapi:monetdb://127.0.0.1:50000/

/opt/cherokee/bin/mserver5 --set monet_daemon=yes
MonetDB server v5.7.0, based on kernel v1.25.0
Serving database 'demo', using 2 threads
Compiled for x86_64-unknown-linux-gnu/64bit with 64bit OIDs dynamically linked
Copyright (c) 1993-2008 CWI, all rights reserved
Visit http://monetdb.cwi.nl/ for further information
warning: please don't forget to set your vault key!
(see /opt/cherokee/etc/monetdb5.conf)
Listening for connection requests on mapi:monetdb://127.0.0.1:50000/

(now I see this also in the latest version of today, but that is inside a VM now, so I cannot copy/paste)

So why do we have different results? I also tried to update the configuration file, a change to 'yes' also is not working.

Comment 17

Date: 2008-10-16 02:38:53 +0200
From: @drstmane

also --daemon=yes work fine for me and it seems to work for you, doesn't it?

At least I cannot see any "different results" ...

Again my question, what exactly is the/your problem???

Comment 18

Date: 2008-10-16 02:53:11 +0200
From: @skinkie

That the server doesn't get into 'daemon' mode?

I don't see a prompt back on my screen... or should I interpreted that it does not fork to the background automatically as 'daemon' mode?

nemesis skinkie /opt/monetdb/bin/mserver5 --daemon=yes
MonetDB Server v5.0.0
Copyright (c) 1993-2007 CWI, all rights reserved
Compiled for x86_64-unknown-linux-gnu/64bit with 64bit OIDs dynamically linked
dbname:demo
Visit http://monetdb.cwi.nl/ for further information
warning: please don't forget to set your vault key!
(see /opt/monetdb/etc/monetdb5.conf)

nemesis skinkie /opt/monetdb/bin/mserver5 --set monet_daemon=yes
MonetDB Server v5.0.0
Copyright (c) 1993-2007 CWI, all rights reserved
Compiled for x86_64-unknown-linux-gnu/64bit with 64bit OIDs dynamically linked
dbname:demo
Visit http://monetdb.cwi.nl/ for further information
warning: please don't forget to set your vault key!
(see /opt/monetdb/etc/monetdb5.conf)

Anyway you can see the differences above, that is not consistent. First clearly doesn't get into a mode where a user is not able to enter something. The second actually is, but I don't call something daemonizing if I still need to add an & behind it.

So the expected behavior would be to fork to the background?

Comment 19

Date: 2008-10-16 07:58:38 +0200
From: @grobian

@skinkie: this "disagreement" to what daemon mode should mean resulted amongst other things in merovingian. The --daemon flag is absolutely useless, and doesn't do what it suggests to, and should preferably be removed from M5. (IMO)

Comment 20

Date: 2008-10-16 10:47:39 +0200
From: @drstmane

@"skinkie":
I see, didn't get that this was your "problem" --- well, I usually simply run mserver5 --daemon=yes & and that works fine --- I agree that the documentation might be misleading; in case you consider this a bug, feel free to file a clear bug report for that; we do not have much time for "solving riddles" ...

Apart from that, you might indeed want to consider using merovingian as "mr-meltdown" suggested ...

Comment 21

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 623743 at http://sourceforge.net/support/tracker.php?aid=623743

Date: 2003-12-18 11:12:09 +0100
From: Manfred Stienstra <>
To: @sjoerdmullender
Version: -- development

Last updated: 2004-01-16 10:44:32 +0100

Comment 210

Date: 2003-12-18 11:12:09 +0100
From: Manfred Stienstra <>

The following error:

monet_interpreter.mx: In function `interpret_batcast':
monet_interpreter.mx:1306: warning: dereferencing
type-punned pointer will break strict-aliasing rules
make[4]: *** [monet_interpreter.lo] Error 1

With the following version of gcc:

Reading specs from
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs
Configured with:
/var/tmp/portage/gcc-3.3.2-r4/work/gcc-3.3.2/configure
--prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info
--enable-shared --host=i686-pc-linux-gnu
--target=i686-pc-linux-gnu --with-system-zlib
--enable-languages=c,c++,f77,objc
--enable-threads=posix --enable-long-long
--disable-checking --enable-cstdio=stdio
--enable-clocale=generic --enable-__cxa_atexit
--enable-version-specific-runtime-libs
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3
--with-local-prefix=/usr/local --enable-shared
--disable-nls --disable-multilib
Thread model: posix
gcc version 3.3.2 20031201 (Gentoo Linux 3.3.2-r4,
propolice)

Comment 211

Date: 2003-12-18 11:31:15 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

There is already code in configure to deal with gcc 3.3.X
for this very problem. The code triggers on CC=gcc and gcc
--version producing 3.3.X.
So, what exactly is your CC variable set to? If it isn't
exactly "gcc", you need to add -Wno-strict-aliasing yourself.

Comment 212

Date: 2003-12-18 11:50:18 +0100
From: Manfred Stienstra <>

Logged In: YES
user_id=100227

dwerg@ack] monetdb) echo $CC
gcc

It looks like it didn't work because I had CFLAGS set to -O3
-march=athlon-xp -pipe

Comment 213

Date: 2003-12-18 12:51:56 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

Does this mean you figured out how to get it to work? Can
the bug be closed then?
Did you set CFLAGS at compile time or at configure time? If
the former I can see how that overrides the definition of
CFLAGS in the Makefiles, and how you then lost the
-Wno-strict-aliasing flag.

Comment 214

Date: 2003-12-18 16:28:57 +0100
From: Manfred Stienstra <>

Logged In: YES
user_id=100227

Yes, it's working now. But the CFLAGS were set at configure
time.

Comment 215

Date: 2004-01-16 10:44:32 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

Closing, since I think this issue was basically pilot error.
Perhaps the configure process needs even better
documentation, but that would be a different bug report.

Comment 216

Date: 2005-10-06 15:30:35 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TESTed by COMPILATION

Comment 217

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 862156 at http://sourceforge.net/support/tracker.php?aid=862156

Date: 2003-11-12 06:32:50 +0100
From: Jens Teubner <>
To: @sjoerdmullender
Version: -- development

Last updated: 2003-12-12 12:41:09 +0100

Comment 139

Date: 2003-11-12 18:32:50 +0100
From: Jens Teubner <>

On a system with perfctr libraries available and GCC 3.2.3,
configure complains

checking libperfctr.h usability... no
checking libperfctr.h presence... yes
configure: WARNING: libperfctr.h: present but cannot be
compiled
configure: WARNING: libperfctr.h: check for missing prerequisite
headers?
configure: WARNING: libperfctr.h: proceeding with the
preprocessor's result
configure: WARNING: ------------------------------------
configure: WARNING: Report this to bug-autoconf@gnu.
org.
configure: WARNING: ------------------------------------
checking for libperfctr.h... yes

Building Monet then fails.

libperfctr.h uses inline', although this is not defined in ANSI C. The Monet configure script should check for the inline' keyword
and define it to empty, if inline' is not allowed. This is done in configure with AC_C_INLINE, but later on, compiler switches become more restrictive, and inline' is no longer allowed.

From config.log:

configure:11308: gcc -c -g -O2 -ansi -std=c99
-D_POSIX_SOURCE -D_POSIX_C_SOURCE=199506L
-D_XOPEN_SOURCE=500 -Wall -W -I/usr/src/linux-2.4.
20/include conftest.c >&5
In file included from /opt/gcc-3.2.3/include/linux/perfctr.h:9,
from /usr/local/include/libperfctr.h:10,
from configure:11369:
/opt/gcc-3.2.3/include/asm/perfctr.h:55: syntax error before
"unsigned"
/opt/gcc-3.2.3/include/asm/perfctr.h:61: syntax error before
"unsigned"
/opt/gcc-3.2.3/include/asm/perfctr.h:66: syntax error before
"int"
/opt/gcc-3.2.3/include/asm/perfctr.h:71: syntax error before
"unsigned"
/opt/gcc-3.2.3/include/asm/perfctr.h:76: syntax error before
"unsigned"
/opt/gcc-3.2.3/include/asm/perfctr.h:81: syntax error before
"unsigned"
configure:11311: $? = 1
configure: failed program was:
[...]
| include <libperfctr.h>
configure:11327: result: no

Comment 140

Date: 2003-12-02 11:11:35 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

I just checked in a new version of configure.ag (1.82) on
the HEAD branch that hopefully fixes this bug. Can you test?

Comment 141

Date: 2003-12-12 12:41:09 +0100
From: Jens Teubner <>

Logged In: YES
user_id=731390

Not reproducable after Sjoerd's changes.

Comment 142

Date: 2005-10-06 13:52:26 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TESTed by COMPILATION

Comment 143

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 840847 at http://sourceforge.net/support/tracker.php?aid=840847

Date: 2003-02-26 11:37:03 +0100
From: @sjoerdmullender
To: Peter Boncz <>
Version: -- development

Last updated: 2003-08-30 12:10:04 +0200

Comment 61

Date: 2003-02-26 11:37:03 +0100
From: @sjoerdmullender

In radix.mx, function rearrange_chunks there is code
that passes an int second argument to BUNindex which is
then cast to BUN by the macro.

The module uses ints in many places where it should
probably use size_t, ptrdiff_t or oid instead to get
the required range. But in this case the use of an
integral type is questionable for an other reason as
well. BINindex calculates the index of the BUN in the
BAT. So the argument should be a BUN in the BAT. But
the argument seems to be an offset already. Maybe what
is meant here is just arg/BUNsize to get the BUN index?

Comment 62

Date: 2003-08-30 12:10:04 +0200
From: @sjoerdmullender

Logged In: YES
user_id=43607

Seems to be fixed.

Comment 63

Date: 2005-10-06 13:30:30 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST / COMPILATION

Comment 64

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 693537 at http://sourceforge.net/support/tracker.php?aid=693537

Date: 2002-08-30 09:57:26 +0200
From: Alex van Ballegooij <>
To: @njnes
Version: -- development

Last updated: 2013-12-09 23:27:07 +0100

Comment 1

Date: 2002-08-30 09:57:26 +0200
From: Alex van Ballegooij <>

void bats behave differntly fomr oid bats under insertion,
yet it is possible to unexpectedly end up with void
bats after certain operations (e.g. join), which could
lead to unpredictable behavior.

See testscript BugReports/Tests/no.173 .

This is the documentation included in the test script itself:

The void-bats behave strange under insertion,
Either errors should be given consequently
(as soon as a tuple 'out-of-sequence' is inserted)
or void bats should be materialized to oid when
needed.

I would argue for the latter, as there is no real reason
for a user to expect the bat in this example to be void,
(a join result of a [oid,oid] and a [oid,int] bat), yet
it behaves differently from what a user would expect
from the (expected) [oid,int] bat.

The provided stable output has been hand-crafted to
depict that which I argue to be the 'correct' output.

Comment 2

Date: 2005-10-04 18:48:48 +0200
From: @drstmane

Logged In: YES
user_id=572415

BugDay_2005-10-06: Done.
test script avialbale as
tests/BugsViaSourgeforce/Tests/ID.602271.*

Comment 3

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 602271 at http://sourceforge.net/support/tracker.php?aid=602271

Comment 17347

Date: 2012-06-06 16:08:22 +0200
From: @njnes

Changeset 36b7be236d87 made by Niels Nes [email protected] in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=36b7be236d87

Changeset description:

fixed bug #3096
	1) added missinge sql create functions for date/time/timestamp
	2) fixed problem with median on empty column

Comment 19318

Date: 2013-11-03 18:06:18 +0100
From: MonetDB Mercurial Repository <>

Changeset ff552d5d57c1 made by Niels Nes [email protected] in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=ff552d5d57c1

Changeset description:

push candidates into join. For now only enabled if run with debug #1<<15.

Comment 19400

Date: 2013-12-09 23:27:07 +0100
From: MonetDB Mercurial Repository <>

Changeset 8428e8ce3226 made by Niels Nes [email protected] in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=8428e8ce3226

Changeset description:

small fixes
	1) make sure we always log (for now we log too much, ie each time the full timestamp bats)
		see new tr_pos_tsbats.
	2) use length of real bat (not too long timestamp bats)
		in bat_table.c
	3) cleanup some more code/debug statements

Date: 2004-02-17 09:14:51 +0100
From: @mlkersten
To: Peter Boncz <>
Version: -- development

Last updated: 2004-02-17 10:12:07 +0100

Comment 236

Date: 2004-02-17 09:14:51 +0100
From: @mlkersten

Expression handling is assymetric in parameter passing

monet>s:=string("hello",0,2);
monet>print(s);
[ "he" ]
monet>s:=string("hello",0,2+1);
monet>print(s);
[ "hel" ]
monet>s:=string("hello",0,5-1);
!ERROR: "s:=string("hello",0,5-1);"
! ^
! can't help you here, sorry.
monet>s:= string("hello",0, (5-1));
!ERROR: "s:= string("hello",0, (5-1));"
! ^
! can't help you here, sorry.
monet>s:= string("hello",0, 5 -1);
!ERROR: "s:= string("hello",0, 5 -1);"
! ^
! can't help you here, sorry.

Comment 237

Date: 2004-02-17 09:20:19 +0100
From: @mlkersten

Logged In: YES
user_id=490798

The user should use a space between - and 1 to avoid the
lexical analyser to recognize it as a -1 token, which would
lead to a syntax error.

Comment 238

Date: 2005-10-06 15:40:42 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists

BugReports/Tests/no.062.milS

Comment 239

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 898543 at http://sourceforge.net/support/tracker.php?aid=898543

Date: 2003-12-03 04:50:19 +0100
From: @drstmane
To: Jens Teubner <>
Version: -- development

Last updated: 2003-12-03 06:55:00 +0100

Comment 197

Date: 2003-12-03 16:50:19 +0100
From: @drstmane

System: RedHat Linux 9, gcc-3.2.2,
Sleepycat/BerkeleyDB-4.1.25

While Jens' new check for the correct signature of
DB->open seems to work fine, the actual DB->open call
fails on the above system when call pf-shred on an
-f0.01 XMark document:

manegold@draco:~/XMark $ pf-shred -v f-0.01
!ERROR: could not open DB `nsloc_dbXikeSk': Invalid
argument

After switching off the BerkeleyDB support/usage
(configure --without-berkeleydb), it runs fine:

manegold@draco:~/XMark $ pf-shred -v f-0.01
document size (serialized) 1161615 byte(s)
document size (encoded) 1883248 byte(s), ~ 1.6x
larger
document depth 12
document nodes 1

• element nodes 17131
• attribute nodes 3917
• text nodes 31088
• comment nodes 0
• processing instruction nodes 0
  = nodes 52137
  encoding time 12s 148ms 476us [233us/node]

Could it be that a null-pointer is no good default
value for the DB_TXN parameter of BerkeleyDB-4.1.25's
DB->open?

Comment 198

Date: 2003-12-03 18:55:00 +0100
From: Jens Teubner <>

Logged In: YES
user_id=731390

pf-shred has used the DB_TRUNCATE flag in the DB->open() call. In
some versions of BerkeleyDB this will working with previously created
empty files (as they had been created using mkstemp). BerkeleyDB 4.
1.25 returns the above error in that case.

pf-shred will now create a temporary directory and create database
files using DB->open() with the DB_CREATE flag.

Comment 199

Date: 2005-10-06 15:10:06 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TESTed by configure/COMPILATION

Comment 200

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 853367 at http://sourceforge.net/support/tracker.php?aid=853367

Date: 2003-12-02 07:46:25 +0100
From: Manfred Stienstra <>
To: @sjoerdmullender
Version: -- development

Last updated: 2003-12-02 08:02:53 +0100

Comment 185

Date: 2003-12-02 19:46:25 +0100
From: Manfred Stienstra <>

For some time now the sql cvs HEAD doesn't bootstrap
because of permission problems. It works when run as
root, but not as a user.

I've attached the bootstrap output.

Comment 186

Date: 2003-12-02 20:02:53 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

The bootstrap process normally removes and recreates a bunch
of files. If you first run bootstrap as root and then as
non-root, the second run can't remove the files that were
created during the first run, and then can't overwrite them,
giving the error you saw.

The solution: remove everything and start over, this time as
non-root.

Comment 187

Date: 2005-10-06 15:06:36 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TESTed by bootstrap

Comment 188

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 852790 at http://sourceforge.net/support/tracker.php?aid=852790

Date: 2003-12-04 08:11:27 +0100
From: @mlkersten
To: Peter Boncz <>
Version: -- development

Last updated: 2003-12-11 06:37:20 +0100

Comment 201

Date: 2003-12-04 08:11:27 +0100
From: @mlkersten

After running the script below for the 3rd time the
server crashes in vfprintf after an infinite recursive
module load, TBL_loadmodule line 1582

This test generates an array in the same way the RAM
frontend would.
The array is filled with color values, to produce a
pretty picture
in the SpatialView visualization.

it requires the color, array, and, mmath modules to
be loaded:
module("color","array","mmath");
{

var width := 40;
var height := 30;
var x_axis := grid(height,width,1,0);
var y_axis := grid(1,height,width,0);

var r := [abs]([int]([]([sin]([/](dbl,dbl
(width)/(2.0LLM_PI))),255
.0LL)));
var g := [abs]([int]([]([sin]([/](dbl,dbl
(height)/(2.0LLM_PI))),25
5.0LL)));
var b := abs,dbl(width+height)
/(2.0LL*M_PI))),255.0LL)));

var values := rgb;

Note this should be 'table', not 'print', but at present
monet doesnt
produce column types in the table output, hence we
revert back to the
plain print funciton.

print(x_axis,y_axis,values);

}
drop("color");
drop("array");
drop("mmath");

Comment 202

Date: 2003-12-11 16:37:34 +0100
From: @drstmane

Logged In: YES
user_id=572415

Added test tests/BugsViaSourgeforce/Tests/ID.853867 in CVS.

This test successfully runs the script 10 times (one
Mserver, 10 different MapiClient sessions) without any problems.
Might the bug be fixed by now?
Or didn't I understand the bug report correctly?

Stefan

Comment 203

Date: 2003-12-11 18:37:20 +0100
From: @mlkersten

Logged In: YES
user_id=490798

The problem has been fixed by PB. It appeared to be a bug when
you enter a single line statement including a module load
and drop,
where the module loaded also included a MIL block.
it required a patch in the MIL parser.

Comment 204

Date: 2005-10-06 15:28:09 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST / SUCCESS
Test added as
tests/BugDay_2005-10-06_4.9.3/Tests/Recursive_module_load.SF-853867

Comment 205

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 853867 at http://sourceforge.net/support/tracker.php?aid=853867

Date: 2004-01-08 06:54:47 +0100
From: @drstmane
To: @sjoerdmullender
Version: -- development

Last updated: 2004-02-05 06:58:46 +0100

Comment 223

Date: 2004-01-08 18:54:47 +0100
From: @drstmane

OS + compiler:
RedHat Linux 9 (Kernel 2.4.20), gcc 3.2.2 & icc 7.1
SuSE Linux 8.1 (Kernel 2.4.21), gcc 3.2

Since 12.12.2003, the test
src/mapi/Tests/manyMapiClients and
src/mapi/examples/C/Tests/smack01 show very instable
behaviour in the above systems, mostly crashing on
assertions in stream, or running into a timeout.
On 11.12.2003, there were no test result.
Until 10.12.2003, the tests seem to have run fine.
Hence, the problems might be related to some changes on
10.12.2003 and/or 11.12.2003.
I have no idea, yet(?), what's is actually going wrong
and/or what might have caused the problems.

Strangely, 64-bit Linux (Red Hat Linux Advanced
Workstation 2.1, Kernel 2.4.18, gcc 3.3.1/icc 7.1 &
Debian 3.0, Kernel 2.4.23, gcc 3.3.2) seem to work fine
on these tests...

Comment 224

Date: 2004-01-16 10:46:07 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

Is this resolved with my hack in MT_global_exit?

Comment 225

Date: 2004-01-16 14:03:05 +0100
From: @drstmane

Logged In: YES
user_id=572415

No, unfortunately, the problem is still there, at least on
RedHat Linux 9 (Kernel 2.4.20), gcc 3.2.2 & icc 7.1;
it seem to have "disappeared" on
SuSE Linux 8.1 (Kernel 2.4.21), gcc 3.2, though.

See the TestWeb for details:
http://monetdb.cwi.nl/TestWeb/Current/MonetDB/MonetDB/.mTests103/index.html

Comment 226

Date: 2004-02-05 18:58:45 +0100
From: @drstmane

Logged In: YES
user_id=572415

The problem seems to have been fixed by the recent changes
in the MAPI-stream/-socket handling.

Comment 227

Date: 2005-10-06 15:34:52 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
Test exists as smack01

Comment 228

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 873203 at http://sourceforge.net/support/tracker.php?aid=873203

Date: 2004-02-04 03:50:44 +0100
From: @grobian
To: GDK devs <>
Version: -- development

Last updated: 2004-03-11 08:53:20 +0100

Comment 229

Date: 2004-02-04 15:50:44 +0100
From: @grobian

When using the Xeport command to achieve (the next)
block from the server with multiple connections, the
server seems to crash with a segmentation fault. I
haven't been able to get this when using only one
connection. The problem also doesn't appear when using
multiple connections that do not issue Xeport.

Comment 230

Date: 2005-10-06 15:49:17 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST / SUCCESS
Tested by jdbc test Test_Cautocommit

Comment 231

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 890471 at http://sourceforge.net/support/tracker.php?aid=890471

The original assignee of this bug does not have
an account here. Reassigning to the default assignee
for the component, [email protected].
Previous assignee was [email protected].

Date: 2003-11-09 08:09:05 +0100
From: @drstmane
To: @sjoerdmullender
Version: -- development

Last updated: 2003-12-02 11:42:41 +0100

Comment 131

Date: 2003-11-09 20:09:05 +0100
From: @drstmane

Platform: INS-1 test system "win2000"
OS: WindowsNT5.0 (aka Windows2000)
Compiler: MSVC++6.0

On Windows, the C-MapiClient and the C-Mapi examples
fail with
"Assertion failed: !s->errnr, file
.......\src\common\stream.mx, line 777"
or
"Assertion failed: !s->errnr, file
.......\src\common\stream.mx, line 793"
or
"!ERROR mapi_reconnect: : No error"

See tests
src/mapi/Tests/monet_BATs
src/mapi/examples/C/Tests/*
src/monet/Tests/modrefcnt2
src/monet/Tests/monet_mod_cnt-copy_C
src/tools/Tests/client
src/tools/Tests/multiClientSeq

The MapiClient.py seem to work fine, though.
See test
src/mapi/Tests/manyMapiClients

Thanks to Marco Dekker ([email protected]) for
reporting this bug (via mail to [email protected]).

My apologies for not watching the test output carefully
enough to detect this bug immediately when it occurred...

Sjoerd,
I assigned this to you to have at least a first look;
if necessary, you may of course consult Martin and/or
Niels.

Comment 132

Date: 2003-12-02 11:42:41 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

Recent changes in mapi seem to have fixed this bug. I can
now successfully connect and disconnect a MapiClient on Windows.

Any errors still in the test web are different errors and
need a different bug report.

Comment 133

Date: 2005-10-06 13:51:14 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
Test exists as src/mapi/Tests/monet_BATs
src/mapi/examples/C/Tests/*
src/monet/Tests/modrefcnt2
src/monet/Tests/monet_mod_cnt-copy_C
src/tools/Tests/client
src/tools/Tests/multiClientSeq

Comment 134

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 838893 at http://sourceforge.net/support/tracker.php?aid=838893

Date: 2002-11-22 05:08:39 +0100
From: Maurice van Keulen <>
To: Stefan Manegold <<Stefan.Manegold>>
Version: -- development

Last updated: 2002-11-22 07:37:38 +0100

Comment 46

Date: 2002-11-22 17:08:39 +0100
From: Maurice van Keulen <>

Sporadically, a bug in "kintersect" is haunting me. The
result of the operation is not correct. I finally
managed to construct an example that reproduces the
bug. The attached file contains two exported bats and a
small script that imports them and performs a
kintersect. The result should be empty, but somehow one
element ends up in the result anyway. To make the bug
visible, I try to look up the elements of the result in
one of the operands of kintersect. Since it is an
intersection, those values should always be there,
shouldn't they?

Monet Database Server V4.3.6
Copyright (c) 1993-2002, CWI. All rights reserved.
compiled for i686-suse-linux/32bit; dynamically linked.
monet>dr:="/local_tmp";
monet>b:=new(oid,str);
monet>b.import(dr + "/b.export.txt");
monet>c:=new(oid,void);
monet>c.import(dr + "/c.export.txt");
monet>d:=c.kintersect(b);
monet>d@batloop { b.find($h).print; }
!ERROR: CMDfind: value not found.
!ERROR: CMDfind: operation failed.
!ERROR: print(param 1): evaluation error.

Comment 47

Date: 2005-10-06 13:26:02 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
Test exists as tests/BugsViaSourgeforce/Tests/ID.642351.milS

Comment 48

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 642351 at http://sourceforge.net/support/tracker.php?aid=642351

Date: 2002-08-30 05:04:14 +0200
From: @arjenpdevries
To: @njnes
Version: -- development

Last updated: 2020-10-12 17:52:14 +0200

Comment 4

Date: 2002-08-30 17:04:14 +0200
From: @arjenpdevries

see test no.173.

a join with a .reverse.mirror-ed void-oid-bat gives a
non-empty
result while it should have been empty.

Comment 5

Date: 2002-08-30 17:07:25 +0200
From: @arjenpdevries

Logged In: YES
user_id=572978

test no.173 has turned into test no.174

Comment 6

Date: 2005-10-06 12:36:35 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed [niels].
BugDay_2005-10-06: Done
Bug reported over existing test no.173 and no.174

Comment 7

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 602463 at http://sourceforge.net/support/tracker.php?aid=602463

Comment 28161

Date: 2020-10-12 17:52:14 +0200
From: MonetDB Mercurial Repository <>

Changeset 69fe7bc578b3 made by Niels Nes [email protected] in the MonetDB repo, refers to this bug.

For complete details, see https//devmonetdborg/hg/MonetDB?cmd=changeset;node=69fe7bc578b3

Changeset description:

fix 2 more tests

Date: 2003-12-02 04:15:32 +0100
From: @swingbit
To: GDK devs <>
Version: -- development

Last updated: 2003-12-02 04:57:22 +0100

Comment 181

Date: 2003-12-02 16:15:32 +0100
From: @swingbit

To properly describe this bug a monospace font is required.
Thus, I enclose a text file as attachment.

Comment 182

Date: 2003-12-02 16:57:22 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

Fixed in CVS.

Comment 183

Date: 2005-10-06 15:05:55 +0200
From: @njnes

Logged In: YES
user_id=43556

ugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST / SUCCES
Test added as
tests/BugDay_2005-10-06_4.9.3/Tests/Confusing_error.SF-852659.milC

Comment 184

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 852659 at http://sourceforge.net/support/tracker.php?aid=852659

The original assignee of this bug does not have
an account here. Reassigning to the default assignee
for the component, [email protected].
Previous assignee was [email protected].

Date: 2003-09-30 11:01:08 +0200
From: @drstmane
To: Peter Boncz <>
Version: -- development

Last updated: 2004-03-17 05:48:11 +0100

Comment 77

Date: 2003-09-30 23:01:08 +0200
From: @drstmane

Scenario:

An Mserver is started,
loads a module (lock) that defines an atom (lock),
an a transient BAT ("test") is created with that atom
in the global scope.

A first client connects, also (re-)loads the same
module (lock) and prints the global BAT "test".
Fine so far.
The first client quits, again.

Then, a second client connects, and tried to print
the global BAT "test", but that fails, complaining
about a BAT with illegal types.
The respective module (lock), however, is still there
with correct reference count of 1.
(cf. test src/monet/Tests/modrefcnt2)

History:

The bug seems to have sneaked in during the CWI_DDI_merge
on August 6, 2003;
since then, the test show a difference in the output.

However, the differences disappeared with Peter's DD-sync,
when the wrong error messages were incorrectly approved.

Comment 78

Date: 2003-10-10 16:25:25 +0200
From: @drstmane

Logged In: YES
user_id=572415

Update:

According to Peter, the current behavior is the desired one,
i.e., clients are not supposed to see any modules that have
been loaded in the global/adm context after the
mapi-listener has been started. Hence, the error messages
about the "illegal type" "lock" are indeed correct. However,
for the sake of consistency (and not to confuse the user),
other commands should stick to these rules, too, e.g.,
"loaded" should only show modules that are indeed loaded by
the very client (or by adm before the mapi-listener was
started), "sigs" should only work for such modules, and what
about commands like "proc" and "vars", and all the "monet_*"
BATs ...???

Here's still some work TODO ... !

Comment 79

Date: 2004-03-04 00:51:26 +0100
From: @peterboncz

Logged In: YES
user_id=591107

this appears to be a feature request rather than a bug report

everythings works OK according to my book (module loads
are client-specific)

there is a distinction between 'logical module load' (i.e.
things are entered in the client-specific ADT,acc,command
parsing tables), and 'physical module load' (the loading of
the .so, and execution of initialization scripts)

what could be bothering is that the MIL procs 'loaded'
and 'sigs' report on the physical status rather than the logical
status.

that may be confusing to some users.

Comment 80

Date: 2004-03-17 17:48:11 +0100
From: @peterboncz

Logged In: YES
user_id=591107

was now fixed: loaded is client specific

the othr issues

• sigs: while not consistent, the current complaint is that sigs
  only works when the module is already loadd, so enforcing
  this should not have priority
• vars: is stackbased and can thus is client-specific

the 'proc' remark I do not understand. If you mean 'procs' to
my best knowledge it is client-specific already.

Comment 81

Date: 2005-10-06 13:33:16 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
Test exists as modrefcnt2

Comment 82

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 815433 at http://sourceforge.net/support/tracker.php?aid=815433

Date: 2003-11-26 11:42:03 +0100
From: Manfred Stienstra <>
To: @njnes
Version: -- development

Last updated: 2003-12-03 06:44:44 +0100

Comment 154

Date: 2003-11-26 23:42:03 +0100
From: Manfred Stienstra <>

I was trying to get some php code to run on the MonetDB
sql server, for this I created the following table:

CREATE TABLE news (
id mediumint,
content text,
user_id int,
date datetime,
PRIMARY KEY (id)
);

After this I inserted the following:

INSERT INTO news (id, content, user_id, date) VALUES
(1, 'dwerg.net word volwassen, er is eindelijk content
en het voicemail archief begint al aardig vol te lopen.
De commentaar en rating code voor de voicemails is ook
al vrij aardig aan het vorderen. Dus dat beloofd nog
wat.\r\n

\r\nMja, het is dat ik veel te veel
tijd heb en het helemaal verkeerd indeel dat het
allemaal nogal lang duurt, maar in principe is het nog
maar een uurtje of 6 werk om het goed te krijgen. Zoals
je kan zien heb ik bij de voicemails al wat leuke
knopjes gezet, en het aantal voicemails dat je in 1
keer ziet verhoogd naar 15. Poepoe.\r\n

\r\nHet is me allemaal wat...\r\n

\r\nMuziek: Air', 1, '2002-02-22 00:21:00');

This went terribly wrong. See the attached file for
MonetDB output.

Comment 155

Date: 2003-11-27 00:01:06 +0100
From: @njnes

Logged In: YES
user_id=43556

Not reproducable on current version with simple Msql frontend.
Using MapiClient (sql_server2) the insert fails as multiline
queries
aren't supported.

Comment 156

Date: 2003-11-27 00:07:51 +0100
From: Manfred Stienstra <>

Logged In: YES
user_id=100227

Do you mean the create table? My php code strips newlines,
so this query works from the php code.

So the actual query would be:

CREATE TABLE news (id mediumint,content text,user_id
int,date datetime,PRIMARY KEY (id));

Comment 157

Date: 2003-12-02 14:13:49 +0100
From: @njnes

Logged In: YES
user_id=43556

could you attach a single sql file with create and insert
statements which have this affect?

Comment 158

Date: 2003-12-03 18:44:44 +0100
From: @njnes

Logged In: YES
user_id=43556

fix in cvs

Comment 159

Date: 2005-10-06 14:28:17 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST / SUCCESS
New test added src/tests/news.sql

Comment 160

Date: 2005-10-06 14:30:45 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST / SUCCESS
New test added in src/tests/news.sql

Comment 161

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 849920 at http://sourceforge.net/support/tracker.php?aid=849920

Date: 2003-11-26 12:58:10 +0100
From: @arjan
To: @njnes
Version: -- development

Last updated: 2003-12-05 12:28:02 +0100

Comment 149

Date: 2003-11-26 00:58:10 +0100
From: @arjan

While inserting about 30MB BLOB data doing a COMMIT
after each insert, the server crashes. The blob data
rotates in size from 100kb to 10MB.

I have attached a bzip2'd file with the queries.

gdb Backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 49156 (LWP 1069)]
0x4484a81f in void_insert_delta (b=0x0, u=0x8ee1ff0) at
sql_mvc.mx:393
393 assert( b->batCacheid != u->batCacheid);
Current language: auto; currently c
(gdb) bt
0 0x4484a81f in void_insert_delta (b=0x0,
u=0x8ee1ff0) at sql_mvc.mx:393
1 0x44851c4f in rollforward_update_table
(tr=0x8c54750, ft=0x86b8328,
tt=0x8c35dd8) at sql_mvc.mx:2144
2 0x44851099 in rollforward_changeset_updates
(tr=0x8c54750, fs=0x87a0220,
1970-01-01 01:00:00 +0100x8392340, b=0x8392328,
rollforward_updates=0x44851700
<rollforward_update_table>,
rollforward_creates=0x448513d0
<rollforward_create_table>,
rollforward_deletes=0x448515d0
<rollforward_drop_table>,
fd=0x4484dee0 <table_dup>) at sql_mvc.mx:1948
3 0x44851cff in rollforward_update_schema (tr=0x724,
fs=0x87a0208, 1970-01-01 01:00:00 +0100x0)
at sql_mvc.mx:2234
4 0x44851099 in rollforward_changeset_updates
(tr=0x8c54750, fs=0x8c54768,
1970-01-01 01:00:00 +0100x8392300, b=0x0,
rollforward_updates=0x44851ca0
<rollforward_update_schema>,
rollforward_creates=0x448516b0
<rollforward_create_schema>,
rollforward_deletes=0x44851670
<rollforward_drop_schema>,
fd=0x4484e090 <schema_dup>) at sql_mvc.mx:1948
5 0x44851d6e in rollforward_trans (tr=0x0) at
sql_mvc.mx:2244
6 0x448520da in mvc_commit (m=0x8c54718, chain=0,
name=0x8b0d2d0 "")
at sql_mvc.mx:2365
7 0x44802531 in mvc_commit_wrap (res=0x0, m=0x724,
chain=0x724,
name=0x724 <Address 0x724 out of bounds>) at
sql_server.mx:295
8 0x447ffcfb in mvc_commit_wrap_unpack859484421
(argc=4, argv=0x8502268) at sql_server.glue.c:170
9 0x40036a0d in interpret (stk=75, lt=0x8501d70,
res=0xbf3fb844)
at monet_interpreter.mx:934
10 0x400399ee in interpret_assignment (stk=75,
lt=0x8501ca0, res=0xbf3fb844)
at monet_interpreter.mx:1384
11 0x400358ea in interpret (stk=75, lt=0x8501ca0,
res=0xbf3fb844)
at monet_interpreter.mx:564
12 0x40039d0d in interpret_seqblock (stk=75,
lt=0x8393810, res=0xbf3fb844,
scope=1) at monet_interpreter.mx:1428
13 0x40035956 in interpret (stk=74, lt=0x8393810,
res=0xbf3fb844)
at monet_interpreter.mx:571
14 0x40036e90 in interpret (stk=74, lt=0x84fdfd8,
res=0xbf3fb844)
at monet_interpreter.mx:920
15 0x44803a76 in backend_interpret (procstk=1828,
name=0x724 <Address 0x724 out of bounds>, args=0x0)
at sql_session.mx:194
16 0x44803e8c in sqlexecute (be=0x8d06df0,
out=0x8c54690, stk=4)
at sql_session.mx:343
17 0x44804845 in sqlclient (stk=4, lt=0x0, res=0x0) at
sql_session.mx:515
18 0x40035f96 in interpret (stk=4, lt=0x81ea9c0,
res=0xbf3ffa84)
at monet_interpreter.mx:656
19 0x400452e0 in handleRequest (t=0x404dfbfc,
q=0x8c616e0, res=0xbf3ffa84)
at monet_queue.mx:503
20 0x40045720 in doRequest (t=0x404dfbfc, preference=0x0)
---Type to continue, or q to quit---
at monet_queue.mx:527

Comment 150

Date: 2003-12-02 14:17:55 +0100
From: @njnes

Logged In: YES
user_id=43556

Could you try the latest sql/monet version. Last couple of
days lots of memory leaks have been fixed. I could however
not reproduce the error message with the bla.sql file.

Comment 151

Date: 2003-12-05 12:28:02 +0100
From: @njnes

Logged In: YES
user_id=43556

fixed in cvs

Comment 152

Date: 2005-10-06 15:51:01 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST / NO TEST
Problem occurs with large input data, this will make our cvs
checkouts too slow

Comment 153

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 849327 at http://sourceforge.net/support/tracker.php?aid=849327

Date: 2003-03-11 05:25:05 +0100
From: Jens Teubner <>
To: Stefan Manegold <<Stefan.Manegold>>
Version: -- development

Last updated: 2003-03-31 01:32:28 +0200

Comment 65

Date: 2003-03-11 17:25:05 +0100
From: Jens Teubner <>

The function type() returns an integer value, representing the type of its argument and works correctly.

The functions head() and tail() should do the same for the head or tail of a BAT, respectively. But they do not return an integer as specified in the online help. They return a string representation of the type.

x := new (oid, int);
x.type.print;
[ 4 ]
x.head.print;
[ "oid" ]
"head".help;
PROC: head(BAT[any,any]) : int
MODULE: sys
COMPILED: by boncz on Mar 22 1998
Get head-type as an int

Comment 66

Date: 2003-03-30 18:12:23 +0200
From: @drstmane

Logged In: YES
user_id=572415

The functions head() and tail() are indeed supposed to
return the respective column types of a BAT as string. I
fixed the help-message accordingly.

The respective functions to get the head-/tail-column type
as integer are htype() and ttype().

Comment 67

Date: 2003-03-31 13:32:28 +0200
From: @drstmane

Logged In: YES
user_id=572415

for the sake of completeness:
set proper Resolution, Category, & Group.

btw: the latter should read "MonetDB 4.3.X", there is no
"MonetDB 4.7.X"
(yet?) ...

Comment 68

Date: 2005-10-04 17:51:25 +0200
From: @drstmane

Logged In: YES
user_id=572415

BugDay_2005-10-06: Claimed.

Comment 69

Date: 2005-10-04 18:05:56 +0200
From: @drstmane

Logged In: YES
user_id=572415

BugDay_2005-10-06: Done:
test script added as
tests/BugDay_2005-10-06_4.9.3/Tests/return_types_of_head_and_tail.SF-701641.*

Comment 70

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 701641 at http://sourceforge.net/support/tracker.php?aid=701641

Date: 2004-02-10 10:36:57 +0100
From: @mlkersten
To: Stefan Manegold <<Stefan.Manegold>>
Version: -- development

Last updated: 2004-03-23 08:49:34 +0100

Comment 232

Date: 2004-02-10 22:36:57 +0100
From: @mlkersten

The selectivity estimates for tables with >100K
elements and a selectivity factor > 20% are severely
hampered by the table realloc strategy.

Solution. For all (larger) tables take the time to get
some basic statistics, e.g. the min/max or possibly a
coarse histogram. Use this information to obtain a
better estimate of the result size.

requires patches to gdk_batop/GDK_select*

[source: Cracker experiments]

Comment 233

Date: 2004-03-23 08:49:34 +0100
From: @drstmane

Logged In: YES
user_id=572415

converted to RFE 921586

Comment 234

Date: 2005-10-06 15:37:42 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST / NO TEST
Is a performance problem

Comment 235

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 894704 at http://sourceforge.net/support/tracker.php?aid=894704

Date: 2003-10-02 06:44:33 +0200
From: @drstmane
To: Stefan Manegold <<Stefan.Manegold>>
Version: -- development

Last updated: 2003-12-18 10:59:14 +0100

Comment 88

Date: 2003-10-02 18:44:33 +0200
From: @drstmane

[ Peter, this is not to "urge" you, but purely for the
"bookkeeping"! ]
( Sure, other volantiers are welcome to have a look and
fix the bug ;-)

Since Peter's "DD-sync", test
src/modules/plain/Tests/xtables
test seems to hang (busily!).
A short look in gdb seems to indicate, that the
"orderby" sub-test spends
very much time in lines 272-278 of gdk_qsort.mx:

     if (swap_cnt == 0) {  /* Switch to insertion

sort */
for (pm = (char *) a + buf->width; pm <
(char *) a + MULT_WIDTH(n); pm += buf->width)
for (pl = pm; pl > (char *) a
&& @2_@3_@4E(pl, pl - buf->width);
pl -= buf->width)
@1_SWAP(@3, pl, pl -
buf->width);
return;
}

I had no time, yet, to check any further, bu
maybe this helps locating and fixing the bug ...

PS: Peter's DDsync is wrapped in CVS-tags
"BeforePetersDDsync" & "AfterPetersDDsync"

Comment 89

Date: 2003-10-02 18:46:26 +0200
From: @drstmane

Logged In: YES
user_id=572415

Ups, I forgot the following:

I ran the xtables test outside Mtest, i.e., without time limit:

========
time Mserver src/modules/plain/Tests/xtables.milM >
/tmp/xtables.out

real 542m20.442s
user 541m26.220s
sys 0m12.490s

hence, it eventually finished after 9 hours (!) on my
machine (non-optimized Mserver), and the output is indeed as
expected
(i.e., correct).

Comment 90

Date: 2003-12-18 22:59:14 +0100
From: @drstmane

Logged In: YES
user_id=572415

I finally managed to locate and fix a couple of more bugs in
GDKqsort[_rev], that sneaked in when "reverse" (decending)
sorting was introduced --- they were "very well hidden" ... |-(

Stefan

Comment 91

Date: 2005-10-06 13:36:24 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
Test exists as ./src/modules/plain/Tests/xtables.milM

Comment 92

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 816667 at http://sourceforge.net/support/tracker.php?aid=816667

Date: 2003-10-03 07:19:19 +0200
From: @drstmane
To: Stefan Manegold <<Stefan.Manegold>>
Version: -- development

Duplicates: #20
Last updated: 2010-05-04 11:11:10 +0200

Comment 98

Date: 2003-10-03 19:19:19 +0200
From: @drstmane

[ Peter, this is not to "urge" you, but purely for the
"bookkeeping"! ]
( Sure, other volantiers are welcome to have a look and
fix the bug ;-)

(most probably) since Peter's "DD-sync", the output of
test no.089 in tests/BugReports/Tests differs from
the stable output; see attached file for details.

Apparently, abort now has no immediate impact on a
persistent unloaded bat, i.e., the inserted BUN is
still present in the BAT after the abort. After
quitting and restarting the server, however, the BUN is
correcly gone.

I guess, this is not correct. The inserted BUN should
be gone right after the abort.

PS: Peter's DDsync is wrapped in CVS-tags
"BeforePetersDDsync" & "AfterPetersDDsync"

Comment 99

Date: 2003-10-03 23:52:04 +0200
From: @drstmane

Logged In: YES
user_id=572415

delete bug report, as it somehow appears twice, now ... !??

Comment 100

Date: 2005-12-20 01:11:54 +0100
From: @drstmane

Logged In: YES
user_id=572415

BugDay: stmane: NO TEST / DUPLICATE

Comment 101

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 817305 at http://sourceforge.net/support/tracker.php?aid=817305

Bug has invalid status, setting status to "NEW".
Previous status was "DELETED".

Comment 13972

Date: 2010-05-04 11:11:10 +0200
From: @grobian

*** This bug has been marked as a duplicate of bug #20 ***

Date: 2003-11-07 02:07:58 +0100
From: Jens Teubner <>
To: @sjoerdmullender
Version: -- development

Last updated: 2003-11-07 02:38:08 +0100

Comment 121

Date: 2003-11-07 14:07:58 +0100
From: Jens Teubner <>

When compiling Monet 4.3.14c with GCC 2.95, glibc 2.2.5 (SuSE
8.0), compilation fails with

gcc -DHAVE_CONFIG_H -I. -I. -I../../../.. -I. -I../../../common -I.
/../../../common -O2 -Wall -W -O6 -fomit-frame-pointer
-finline-functions -malign-loops=4 -malign-jumps=4
-malign-functions=4 -fexpensive-optimizations -funroll-all-loops
-funroll-loops -frerun-cse-after-loop -frerun-loop-opt
-Werror-implicit-function-declaration -Werror -Wno-format
-Wno-sign-compare -Wno-unused -D_REENTRANT -c Mapi.c
-fPIC -DPIC -o Mapi.lo
Mapi.mx: In function mapi_store_bind': Mapi.mx:2392: implicit declaration of function strtof'

The manpage to strtof tells to include stdlib.h when using strtof.

Monet's configure script checks for existence and declaration of
strtof and produces two definitions in config.h: HAVE_STRTOF
and HAVE_DECL_STRTOF (first one set, second not). In Mapi.mx,
only HAVE_STRTOF is checked for, but not HAVE_DECL_STRTOF.

Comment 122

Date: 2003-11-07 14:38:08 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

Apply the attached diff (in the top-level directory of
MonetDB: patch -p0 < Mapi-diff) to fix this problem.

The problem is actually that strtof is defined in the C99
standard, but not in any earlier standards. GCC-2.95 does
not know about C99, so it can't be told to compile according
to that standard, and so it compiles according to the older
C89 standard, and hence does not recognize strtof.

Comment 123

Date: 2005-10-06 13:49:03 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TESTed by COMPILATION
configure takes care of this

Comment 124

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 837849 at http://sourceforge.net/support/tracker.php?aid=837849

Date: 2003-11-07 03:47:07 +0100
From: Jens Teubner <>
To: @sjoerdmullender
Version: -- development

Last updated: 2004-03-14 09:32:02 +0100

Comment 125

Date: 2003-11-07 15:47:07 +0100
From: Jens Teubner <>

Well, I don't know if this is really worth being fixed, but at least
you should be aware of it:

javac fails here with

/usr/lib/java/bin/javac -d . -classpath "" mapi/MapiException.
java mapi/Mapi.java MapiClient.java
mapi/Mapi.java:115: Package java.awt not found in import.
import java.awt.*;
^
mapi/Mapi.java:116: Class java.applet.Applet not found in
import.
import java.applet.Applet;
^
... and some more classes ...

We have Blackdown Java 1.1.8v1 here (coming with SuSE 7.3).
The classpath given on the command line seems to override the
system default classpaths. If I compile without the classpath
switch (/usr/lib/java/bin/javac -d . mapi/MapiException.java ...),
everything works fine. In src/mapi/examples/java I had to add
the system classpath to the classpath on the command line
(/usr/lib/java/lib/classes.zip here).

With Sun JDK 1.4.2, everything works fine, also with Sun JDK 1.
3.1.

Comment 126

Date: 2004-03-14 09:32:02 +0100
From: @njnes

Logged In: YES
user_id=43556

it works with sun jdk 1.3 and 1.4! 1.1.18v1 is too old!

Comment 127

Date: 2004-03-14 21:53:36 +0100
From: @njnes

Logged In: YES
user_id=43556

it works with sun jdk 1.3 and 1.4! 1.1.18v1 is too old!

Comment 128

Date: 2004-03-15 20:25:48 +0100
From: @njnes

Logged In: YES
user_id=43556

it works with sun jdk 1.3 and 1.4! 1.1.18v1 is too old!

Comment 129

Date: 2005-10-06 13:50:25 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TESTed by COMPILATION
also the java compilation is tested by the nightly builds,
we do however limit the number of supported java versions to
1.4.2 and up (currently)

Comment 130

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 837915 at http://sourceforge.net/support/tracker.php?aid=837915

Date: 2003-11-25 03:34:22 +0100
From: @arjan
To: GDK devs <>
Version: -- development

Last updated: 2003-11-25 03:42:11 +0100

Comment 144

Date: 2003-11-25 15:34:22 +0100
From: @arjan

BLOBs did work in the SQL layer, until I submitted a
segfault while inserting a large blob. This segfault
was reportedly fixed, but with the most recent CVS the
SQL layer crashes on inserting a very simple blob tuple
in the database:

create table test ( x blob, y int);
-- (table creation is ok)

insert into test values( blob "(5:11 FC E2 A0 0A)", 1);
-- inserting this tuple crashes the server with the
following message:

Mserver: sql_atom.mx:141: atom_general: Assertion
a->data.vtype >= 0' failed.

** GDB backtrace: **

Mserver: sql_atom.mx:141: atom_general: Assertion
`a->data.vtype >= 0' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 49156 (LWP 7179)]
0x4066c561 in kill () from /lib/libc.so.6
(gdb) bt
0 0x4066c561 in kill () from /lib/libc.so.6
1 0x404f6741 in pthread_kill () from /lib/libpthread.so.0
2 0x404f6a4b in raise () from /lib/libpthread.so.0
3 0x4066c314 in raise () from /lib/libc.so.6
4 0x4066d828 in abort () from /lib/libc.so.6
5 0x40665a5f in __assert_fail () from /lib/libc.so.6
6 0x44823de0 in atom_general (tpe=0x404ff000,
val=0x8bc76e0 "(5:11 FC E2 A0 0A)")
at sql_atom.mx:133
7 0x448408bb in sqlparse (parm=0x8bbc2b0) at
sql_parser.y:1902
8 0x447ffbd4 in sqlexecute (be=0x8bc0730,
out=0x8b1afd0, stk=4) at sql_session.mx:244
9 0x44800845 in sqlclient (stk=4, lt=0x404fccf4,
res=0x2000) at sql_session.mx:515
10 0x40035f96 in interpret (stk=4, lt=0x81e97b0,
res=0xbf3ffa84) at monet_interpreter.mx:656
11 0x400452e0 in handleRequest (t=0x404dfbfc,
q=0x8b27fa8, res=0xbf3ffa84) at monet_queue.mx:503
12 0x40045720 in doRequest (t=0x404dfbfc,
preference=0x0) at monet_queue.mx:527
13 0x4008021a in monetInterpreter (status=0xbf7fd290)
at monet_process.mx:115
14 0x404f3e31 in pthread_start_thread () from
/lib/libpthread.so.0
15 0x404f3eaf in pthread_start_thread_event () from
/lib/libpthread.so.0
16 0x4071a30a in clone () from /lib/libc.so.6

Comment 145

Date: 2003-11-25 15:37:28 +0100
From: @arjan

Logged In: YES
user_id=20087

hmm, it seems the 'blob' column never gets created in the table:

Msql> create table test ( x blob, y int);
Msql>
Msql> select * from test;

| y |

SQL no Rows affected

Comment 146

Date: 2003-11-25 15:42:11 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

BLOB support is marginal. In order to get at least some
BLOB support in the SQL server, before loading the module
sql_server, first load module blob (i.e. execute
module(blob); module(sql_server);).

Comment 147

Date: 2005-10-06 14:18:23 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST / SUCCESS
Test added in src/benchmarks/blob/

Comment 148

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 848988 at http://sourceforge.net/support/tracker.php?aid=848988

The original assignee of this bug does not have
an account here. Reassigning to the default assignee
for the component, [email protected].
Previous assignee was [email protected].

Date: 2003-10-29 11:39:24 +0100
From: @swingbit
To: GDK devs <>
Version: -- development

Duplicates: #23
Last updated: 2010-05-04 10:52:59 +0200

Comment 113

Date: 2003-10-29 11:39:24 +0100
From: @swingbit

I had some strange results running the example coming
with the distribution, sample0.java, which basically
writes 2 rows

[ John, 23 ]
[ Mary, 23 ]

and then retrieves them.

The result is

John is null
Mary is null
^^^^

I also got many of these warnings (trace is on):

"Unrecognized header tag "
It seems like it get confused trying to decode the
header lines.

The C version works fine on this example.

Comment 114

Date: 2003-10-30 13:04:59 +0100
From: @drstmane

Logged In: YES
user_id=572415

delete as it appeared twice (see 832266)

Comment 115

Date: 2005-12-20 01:11:44 +0100
From: @drstmane

Logged In: YES
user_id=572415

BugDay: stmane: NO TEST / DUPLICATE

Comment 116

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 832271 at http://sourceforge.net/support/tracker.php?aid=832271

The original assignee of this bug does not have
an account here. Reassigning to the default assignee
for the component, [email protected].
Previous assignee was [email protected].
Bug has invalid status, setting status to "NEW".
Previous status was "DELETED".

Comment 13966

Date: 2010-05-04 10:52:59 +0200
From: @grobian

*** This bug has been marked as a duplicate of bug #23 ***

Date: 2003-10-14 05:30:45 +0200
From: @drstmane
To: Peter Boncz <>
Version: -- development

Last updated: 2004-03-04 02:53:08 +0100

Comment 102

Date: 2003-10-14 17:30:45 +0200
From: @drstmane

This bug has been reported by Tim Ruhl from DD:

When creating an xtables-histogram on a view BAT and
then removing the view BAT, the respective histogram
accellerator BAT does not get removed.

See the respective test in tests/BugsViaSourgeforce/Tests/
for details.

Comment 103

Date: 2004-03-04 14:53:08 +0100
From: @drstmane

Logged In: YES
user_id=572415

Has been fixed by Peter.
Thanks, Peter!

Comment 104

Date: 2005-10-06 13:41:54 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
Test exists as tests/BugsViaSourgeforce/Tests/ID.823516.milM

Comment 105

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 823516 at http://sourceforge.net/support/tracker.php?aid=823516

Date: 2003-10-02 06:24:20 +0200
From: @drstmane
To: Stefan Manegold <<Stefan.Manegold>>
Version: -- development

Last updated: 2003-10-03 11:40:17 +0200

Comment 83

Date: 2003-10-02 18:24:20 +0200
From: @drstmane

(most probably) since the CWI_DDI_merge,

decimal(0) and decimal("0") incorreclty return nil
on SunOS compiled with the native SUNWspro compiler,
both, with -g and -O3:

========
Monet Database Server V4.3.13
Copyright (c) 1993-2003, CWI. All rights reserved.
compiled for sparc-sun-solaris2.8/32bit; dynamically
linked.
monet>module(decimal);
monet>decimal("0").print;
[ nil ]
monet>decimal(0).print;
[ nil ]
monet>decimal("1").print;
[ 1 ]
monet>decimal(1).print;
[ 1 ]
monet>

Sorry, that I didn't notice this earlier.

(Assigned to Sjoerd, as I assigned my last CWI_DDI_merge
related bug-report to Peter; either might take care,
unless
someone else volantiers ;-)

Comment 84

Date: 2003-10-02 18:27:07 +0200
From: @drstmane

Logged In: YES
user_id=572415

PS: See also tests
src/modules/plain/Tests/decimal
src/modules/plain/Tests/aggr
src/modules/plain/Tests/aggrX3

Comment 85

Date: 2003-10-03 23:40:17 +0200
From: @drstmane

Logged In: YES
user_id=572415

fix for bug-report 816653 "decimal(0) = nil on SunOS-native":

Sun's native C compiler seems to treat bit-fields as unsigned,
even if they are declared as "int", hence, the 16-bit "scale"
element of the "decimal" struct didn't work as expected.
Unfortunately, the compiler doesn't give any worning, and
I found no switch to either enable signed bit-fields or force
an appropiate warning.

Solution: I added a macro
define SCALE(d) ((int)(sht)((d)->scale))
scale that casts scale to a "sht" (signed short int), first,
and thus, the highest bit gets interpreted as sign.

Also added another decimal test used for debugging.

Comment 86

Date: 2005-10-06 13:35:40 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
Test exists as ./src/modules/plain/Tests/decimal_debug.milM

Comment 87

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 816653 at http://sourceforge.net/support/tracker.php?aid=816653

Date: 2002-09-07 11:24:37 +0200
From: @arjenpdevries
To: @njnes
Version: -- development

Last updated: 2002-09-07 01:48:37 +0200

Comment 8

Date: 2002-09-07 11:24:37 +0200
From: @arjenpdevries

marking a void-T table nil gives incorrect results.
See test no.175 in MonetDB_TRECvid branch

Comment 9

Date: 2005-10-06 12:37:39 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed [niels].
BugDay_2005-10-06: Done
Bug reported over existing test no.175

Comment 10

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 605953 at http://sourceforge.net/support/tracker.php?aid=605953

Date: 2002-11-22 04:58:53 +0100
From: Maurice van Keulen <>
To: @njnes
Version: -- development

Last updated: 2003-08-30 12:13:06 +0200

Comment 41

Date: 2002-11-22 16:58:53 +0100
From: Maurice van Keulen <>

The "varval"-function apparently contains a bug
regarding reference counting. See example below:

Monet Database Server V4.3.6
Copyright (c) 1993-2002, CWI. All rights reserved.
compiled for i686-suse-linux/32bit; dynamically linked.
monet>bar:=new(int,int);
monet>varval("bar").print;
!WARNING: BBPunfix: bat(34) has refcnt -1
!WARNING: BBPunfix: bat(34) has refcnt -1

BAT: tmp_34
(int) (int)

!WARNING: BBPunfix: bat(34) has refcnt -1

Comment 42

Date: 2003-02-21 14:39:01 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

I don't know why this was closed, but the bug is still there.

Comment 43

Date: 2003-08-30 12:13:06 +0200
From: @sjoerdmullender

Logged In: YES
user_id=43607

Seems to be fixed in at least 4.3.13.

Comment 44

Date: 2005-10-06 13:24:50 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
Test exists as tests/BugsViaSourgeforce/Tests/ID.642344.

Comment 45

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 642344 at http://sourceforge.net/support/tracker.php?aid=642344

Date: 2003-11-02 03:11:12 +0100
From: @drstmane
To: @njnes
Version: -- development

Last updated: 2003-11-06 12:49:43 +0100

Comment 117

Date: 2003-11-02 15:11:12 +0100
From: @drstmane

When an error is detected, Msql echos the whole
remainder of the current SQL script instead of just the
very command that did fail.
See test src/tests/Tests/marcin3.

(This becomes a big problem when table create fails
during testing and a subsequent script containing n
(hundreds/thousands) inserts (one per line) into this
table. Msql then generates m = n * (n-1) / 2 lines of
error output. This can be huge and fill disks ...)

Comment 118

Date: 2003-11-06 00:49:43 +0100
From: @drstmane

Logged In: YES
user_id=572415

bug has been fixed by Niels

Comment 119

Date: 2005-10-06 13:48:24 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: NO TEST added

Reasons 'Msql is gone', many SQL insert tests exists with
multiple errors

Comment 120

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 834550 at http://sourceforge.net/support/tracker.php?aid=834550

Date: 2003-10-29 11:27:46 +0100
From: @swingbit
To: @mlkersten
Version: -- development

Last updated: 2010-05-04 10:52:59 +0200

Comment 106

Date: 2003-10-29 11:27:46 +0100
From: @swingbit

I had some strange results running the example coming
with the distribution, sample0.java, which basically
writes 2 rows

[ John, 23 ]
[ Mary, 23 ]

and then retrieves them.

The result is

John is null
Mary is null
^^^^

I also got many of these warnings (trace is on):

"Unrecognized header tag "
It seems like it get confused trying to decode the
header lines.

The C version works fine on this example.

Comment 107

Date: 2003-11-05 12:59:58 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

Assigned to Martin.

Comment 108

Date: 2003-12-02 11:47:19 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

Is this still an issue?

Comment 109

Date: 2003-12-02 12:34:36 +0100
From: @swingbit

Logged In: YES
user_id=883451

It works fine now.

Comment 110

Date: 2003-12-02 13:09:08 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

Closing.

Comment 111

Date: 2005-10-06 13:46:22 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
Test exists as src/mapi/examples/java/Tests/sample*

Comment 112

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 832266 at http://sourceforge.net/support/tracker.php?aid=832266

Comment 13967

Date: 2010-05-04 10:52:59 +0200
From: @grobian

*** Bug #24 has been marked as a duplicate of this bug. ***

Date: 2003-12-03 02:02:19 +0100
From: @sjoerdmullender
To: @njnes
Version: -- development

Last updated: 2004-03-09 09:01:44 +0100

Comment 193

Date: 2003-12-03 14:02:19 +0100
From: @sjoerdmullender

Martin wrote (14 Oct 2003):

The way SQL clients are started implies that they
effectively run as DBA threads on the server. This
means that once a person can 'circumvent' the SQL
protection scheme, he has access to everything.

We have to think about alternative schemes.

Comment 194

Date: 2004-03-09 09:01:44 +0100
From: @njnes

Logged In: YES
user_id=43556

grant/revoke and create/drop users had been implemented
(testing is still
needed)

Comment 195

Date: 2005-10-06 15:09:05 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: NO TEST

Comment 196

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 853263 at http://sourceforge.net/support/tracker.php?aid=853263

Date: 2003-10-02 06:54:28 +0200
From: @drstmane
To: Peter Boncz <>
Version: -- development

Last updated: 2010-05-04 11:11:10 +0200

Comment 93

Date: 2003-10-02 18:54:28 +0200
From: @drstmane

[ Peter, this is not to "urge" you, but purely for the
"bookkeeping"! ]
( Sure, other volantiers are welcome to have a look and
fix the bug ;-)

(most probably) since Peter's "DD-sync", the output of
test no.089 in tests/BugReports/Tests differs from
the stable output; see attached file for details.

Apparently, abort now has no immediate impact on a
persistent unloaded bat, i.e., the inserted BUN is
still present in the BAT after the abort. After
quitting and restarting the server, however, the BUN is
correcly gone.

I guess, this is not correct. The inserted BUN should
be gone right after the abort.

PS: Peter's DDsync is wrapped in CVS-tags
"BeforePetersDDsync" & "AfterPetersDDsync"

Comment 94

Date: 2003-10-04 10:36:48 +0200
From: @drstmane

Logged In: YES
user_id=572415

An extended version of test tests/BugReports/Tests/no.089
shows that only saved/unloaded BATs do not get aborted
correctly; on unsaved/hot BATs abort seems to work correctly.
Given this, it is obvious, that the following patch ---
i.e., removing the check, whether a BAT is "dirty" before
calling "BATundo()" in "TMabort()"; this check has been
added by Peter's DDsync --- would fix this problem.

diff -u -r1.21 gdk_tm.mx
--- src/gdk/gdk_tm.mx 5 Sep 2003 18:42:56 -0000 1.21
+++ src/gdk/gdk_tm.mx 4 Oct 2003 08:33:21 -0000
@@ -149,11 +149,9 @@

	if (b == NULL) continue;


	BBPfix(i);

•  if (BATdirty(b)) {
  

•  /* BUN move-backes need a real BAT! */ 
  

•  	b = BBPdescriptor(i);
  

•  	BATundo(b); 
  

•  }
  

•  /* BUN move-backes need a real BAT! */ 
  

•  b = BBPdescriptor(i);
  

•  BATundo(b); 
  
   if (BBP_status(i)&BBPDELETED) {
  
   	BBP_status_on(i, BBPEXISTING, "TMabort");
  
   	if (b->batPersistence != PERSISTENT)
  

========

I have not checked this in, yet, as I'm not sure, whether
the "if (BATdirty(b))" has been added "byt accident" or for
some good reason, which I don't see, yet...

I hope, this helps to fix the bug.

Stefan

Comment 95

Date: 2003-10-10 08:43:49 +0200
From: @drstmane

Logged In: YES
user_id=572415

fixed a DDImerge bug (cf. SF bug report 816672):

TMabort needs to undo changes not only in "dirty" BATs
(BATdirty()), but also in BATs with "diffs" (DELTAdirty()),
i.e., saved/unloaded/swapped-out BATs with differences that
haven't been commit, yet.

Thanks to Niels for the tip where to look.

Actually, I guess, in the DELTAdirty()-case, we do not even
have to load the BAT and apply the BATundo, but could rather
"simply" discard the delta and revive the backup; however, I
don't know (yet) how to do this, hence we stick with the
current solution for the time being --- it should be correct
though it might not be the most efficient way...

Also extended the respective test (tests/BugReports/Tests/no.089

Peter (or Niels) could (one of) you eventually comfirm, that
my fix is actually correct?
Thanks!

Comment 96

Date: 2005-10-06 13:39:46 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
Test exists as tests/BugReports/Tests/no.089.mil

Comment 97

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 816672 at http://sourceforge.net/support/tracker.php?aid=816672

Comment 13973

Date: 2010-05-04 11:11:10 +0200
From: @grobian

*** Bug #21 has been marked as a duplicate of this bug. ***

Date: 2003-09-23 10:12:27 +0200
From: @mlkersten
To: @mlkersten
Version: -- development

Last updated: 2003-12-21 10:53:44 +0100

Comment 71

Date: 2003-09-23 22:12:27 +0200
From: @mlkersten

When starting Mserver --daemon=yes the user is forced
to give an initialization file. This is too strict and
can be dropped.

Comment 72

Date: 2003-09-24 18:45:20 +0200
From: @drstmane

Logged In: YES
user_id=572415

Just a stupid(?) question:

What can I do with an Mserver in daemon-mode that doesn't
get any init/startup script?
Such an Mserver has neither a console nor any mapi or other
remote
access facilities, hence it's very lonely and not very
useful ...
Thus, requiring either a console (monet_daemon=no) as a script
(e.g., to start Mapi or SQL support) is IMHO not too strict,
but rather
healthy. Actually, it could/should(?) be even stricter as
now an empty
script avoid the warning an silently starts a very lonely
and useless
Mserver-daemon... ;-)

Mserver --set monet_daemon=yes
/lib/MonetDB/mapi.mil
or
Mserver --set monet_daemon=yes
/lib/MonetDB/sql_server.mil
IMHO solves the problem: Mserver get a script, and the user
get a useful
Mserver-daemon.

Comment 73

Date: 2003-12-03 14:16:41 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

Assigned to Martin since he should answer Stefan's questions.

Comment 74

Date: 2003-12-21 10:53:44 +0100
From: @mlkersten

Logged In: YES
user_id=490798

it is considered a feature.
A server should explicitly tell what frontends to support

Comment 75

Date: 2005-10-06 13:31:32 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: NO TEST (bug invalid)

Comment 76

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 811366 at http://sourceforge.net/support/tracker.php?aid=811366

Date: 2002-10-31 03:14:03 +0100
From: @sjoerdmullender
To: @sjoerdmullender
Version: -- development

Last updated: 2004-11-30 06:36:01 +0100

Comment 22

Date: 2002-10-31 15:14:03 +0100
From: @sjoerdmullender

The MT_mmap function takes as second argument the OR of
several flags, among which one of MMAP_NORMAL,
MMAP_SEQUENTIAL, etc. These values are defined in
gdk_posix.mx, supposedly with the same values as the
POSIX constants MADV_NORMAL, MADV_SEQUENTIAL, etc.
But who guarantees that they are the same, and that
they fit in the allocated number of bits (MMAP_ADVICE
== 7)?
The proper way of dealing with this is to do a mapping
from MMAP_* to MADV_* in (the Posix version of) MT_mmap.

Comment 23

Date: 2004-11-30 18:36:01 +0100
From: @peterboncz

Logged In: YES
user_id=591107

this was fixed: the MMAP_ constants are now set to the
correct POSIX_MADV_* values

Comment 24

Date: 2005-10-06 13:06:18 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: CLAIMED BY niels
BugDay_2005-10-06: Done/No TEST possible

Comment 25

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 631556 at http://sourceforge.net/support/tracker.php?aid=631556

Date: 2002-11-06 04:49:36 +0100
From: @sjoerdmullender
To: @njnes
Version: -- development

Last updated: 2002-11-23 12:44:15 +0100

Comment 33

Date: 2002-11-06 16:49:36 +0100
From: @sjoerdmullender

The compiler complains:

src/modules/plain/oo7.mx(477) : warning C4700: local
variable 'out' used without having been initialized

and rightly so. The problem is, I don't know what to
initialize it to. I guess stderr and stdout are good
candidates, but I have to wonder too, why is this
variable there in the first place?

Look at the code for context.

Comment 34

Date: 2005-10-06 13:17:37 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: NO TEST / COMPILATION ISSUE
warnings are now treated as errors and therefor will be fixed.

Comment 35

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 634488 at http://sourceforge.net/support/tracker.php?aid=634488

Date: 2002-11-04 04:08:27 +0100
From: @sjoerdmullender
To: @njnes
Version: -- development

Last updated: 2002-11-23 01:05:33 +0100

Comment 30

Date: 2002-11-04 16:08:27 +0100
From: @sjoerdmullender

In interpret_file (src/monet/monet_interpreter.mx), the
file to be interpreted is opened as follows:
if ((fd = fopen(ptr, "rb")) == 0) {
char path[PATHLENGTH];

         if (ptr[0] == DIR_SEP) {
             strcpy(path, ptr);
         }
         fd = fopen(path, "rb");
     }

Apart from the unnecessary binary mode, there is
something else weird going on: If opening fails, and
the file name starts with a DIR_SEP (i.e. is absolute
on Unix and Windows, but relative on Mac) the file name
is copied to a local buffer and the fopen is tried
again using the local buffer. If the file does not
start with a DIR_SEP, this just tries opening a
randomly initialized local buffer. Also, there is no
check on the length of the file name before copying.
Another no no.

It is clear that this code is bogus. But what is the
intention?

Comment 31

Date: 2005-10-06 13:12:01 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: CLAIMED BY niels
BugDay_2005-10-06: NO TEST
bug report about code cleanup, no failing behaviour

Comment 32

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 633313 at http://sourceforge.net/support/tracker.php?aid=633313

Date: 2002-11-18 03:54:16 +0100
From: @sjoerdmullender
To: @sjoerdmullender
Version: -- development

Last updated: 2007-02-20 03:23:26 +0100

Comment 36

Date: 2002-11-18 15:54:16 +0100
From: @sjoerdmullender

We need to take a good look at issues surrounding
CHR_MIN and CHR_MAX with respect to our use of UTF-8.
Perhaps it is best to introduce new types for very
short (8 bit) integers (say, byte and ubyte) and
reserve the type chr for UTF-8 encoded data.

Comment 37

Date: 2004-03-11 08:52:19 +0100
From: @njnes

Logged In: YES
user_id=43556

introduce type byte and remove uchr

Comment 38

Date: 2005-10-06 13:19:50 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TESTs exists
example src/modules/plain/Tests/aggr.milM

Comment 39

Date: 2007-02-20 15:23:26 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607
Originator: YES

I think we can lay this bug to rest.

(char) '\200' is used for chr(nil). All other values for char are valid and interpreted as Unicode code points (i.e. converted to UTF-8 when converted to str and v.v.).

We now have a byte-sized integer type (bte) and the uchr type is dead, may it rest in peace.

Comment 40

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 640125 at http://sourceforge.net/support/tracker.php?aid=640125

Date: 2003-11-28 01:43:45 +0100
From: @drstmane
To: @njnes
Version: -- development

Last updated: 2003-12-02 12:11:49 +0100

Comment 167

Date: 2003-11-28 13:43:45 +0100
From: @drstmane

Platform: INS-1 test system "win2000"
OS: WindowsNT5.0 (aka Windows2000)
Compiler: MSVC++6.0

On Windows, Msql crashes --- just like the C-MapiClient
(see bug report 838893) --- with:

Assertion failed: !s->errnr, file
.......\src\common\stream.mx, line 873

Here's a detailed session:

========
Mserver:

D:\TmpDir\StM>Mserver --set
monet_mod_path=D:\TmpDir\StM\MonetDB\NT\lib\MonetDB;D:\TmpDir\StM\sql\NT\lib\MonetDB
--set sql_port=55555
D:\TmpDir\StM\sql\NT\lib\MonetDB\sql_server.mil
Mserver --set
monet_mod_path=D:\TmpDir\StM\MonetDB\NT\lib\MonetDB;D:\TmpDir\StM\sql\NT\lib\MonetDB
--set sql_port=55555
D:\TmpDir\StM\sql\NT\lib\MonetDB\sql_server.mil
Monet Database Server V4.3.15
Copyright (c) 1993-2003, CWI. All rights reserved.
compiled for i686-pc-win32/32bit; dynamically linked.
monet>clients;
clients;

client name login tree

                  name

int str str str

          type

[ 0, "adm", "no asctime in WIN32", "clients()"

         ]

[ 2, "adm", "no asctime in WIN32",
"mapi_listen(int(find(<monet_environment>,"sql_port")),5,"SQLclient")"
]
[ 3, "adm", "no asctime in WIN32",
"mapi_listen(int(find(<monet_environment>,"mapi_port")),5,"")"
]
monet>Assertion failed: !s->errnr, file
.......\src\common\stream.mx, line 889

abnormal program termination

D:\TmpDir\StM>

Msql:

D:\TmpDir\StM>Msql -umonetdb -Pmonetdb --port=55555
Msql -umonetdb -Pmonetdb --port=55555
Assertion failed: !s->errnr, file
.......\src\common\stream.mx, line 873

abnormal program termination

D:\TmpDir\StM>

See also the sql tests in the test web.

Comment 168

Date: 2003-12-02 12:11:49 +0100
From: @drstmane

Logged In: YES
user_id=572415

Recent changes in (a.o. in stream.mx) seem to have fixed
this bug. I can now successfully connect and disconnect
with Msql on Windows.

Any errors still in the test web are different errors and
need a different bug report.

Comment 169

Date: 2005-10-06 14:41:59 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
Examples are any sql test on windows

Comment 170

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 850726 at http://sourceforge.net/support/tracker.php?aid=850726

Date: 2003-12-01 03:32:51 +0100
From: @swingbit
To: MonetDB4 devs <>
Version: -- development

Last updated: 2003-12-01 10:44:39 +0100

Comment 171

Date: 2003-12-01 15:32:51 +0100
From: @swingbit

Mserver crashes when module sql_server is loaded and a
Mapi session is closed by "quit" command.

This is the way to reproduce de bug:

1. [server side]
   bash$ Mserver
   monet>module(sql_server);

2. [client side]
   bash$ MapiClient
   mil> quit;

now, either issue the "quit" command at server side or
repeat step 2).
In both cases, Mserver crashes with a segmentation fault.

Comment 172

Date: 2003-12-01 17:15:06 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

I can't reproduce this.

If I start Mserver/sql_server in one window and MapiClient
in another and type quit; to MapiClient I get:
mil> quit;
MAPI = anonymous@localhost:50000
ACTION= mapi_fetch_line
QUERY = quit;
ERROR = Lost connection with server
mil>

In other words, the connection is lost, but MapiClient still
lives. If I then type quit; to Mserver, it just exits
without any error messages.

And if instead I just start a new MapiClient and type quit
to it, it gives the same message.

Comment 173

Date: 2003-12-01 21:15:10 +0100
From: @swingbit

Logged In: YES
user_id=883451

Yes, I was running a very early 4.3.14 release.
After an update the problem disappeared, so it was solved in
between.

Comment 174

Date: 2003-12-01 22:44:38 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

Closed since nothing more to do.

Comment 175

Date: 2005-10-06 14:54:00 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
Any MapiClient test will do

Comment 176

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 852098 at http://sourceforge.net/support/tracker.php?aid=852098

The original assignee of this bug does not have
an account here. Reassigning to the default assignee
for the component, [email protected].
Previous assignee was [email protected].

Date: 2003-01-24 04:16:41 +0100
From: @sjoerdmullender
To: @sjoerdmullender
Version: -- development

Last updated: 2003-01-29 01:12:27 +0100

Comment 49

Date: 2003-01-24 16:16:41 +0100
From: @sjoerdmullender

When dropping certain modules you get a crash (core
dump) on IRIX. Try e.g. "module(enum);drop(enum);".

The problem is caused by the fact that some modules use
other modules as library and at the same time load the
other module. When the module (e.g. enum) is loaded,
the system loads the dependant shared libraries (in
this case lib_streams.so) automatically. The module
initialization code then loads that same module
(through the MEL USE statement). This causes the
second module to be loaded again by the system. This
double loading confuses the system no end.

Various solutions are possible, but first an inventory
needs to be made of which modules depend on which other
modules at the C level.

Possible solutions are:

• Partition the set of modules into groups that have
  interdependencies at the C level. Each group is linked
  into a single .so file with multiple names (hard or
  symbolic links). When a module is loaded, find the
  file, and then check, using the stat information of the
  file, whether it has already been loaded. If so, use
  the previously created handle.

• Disallow inter-module dependencies at the C level.
  Each module is standalone. If multiple modules need
  the same functionality, the code should be put into a
  shared library that is used by all of these modules.
  Implicitly loaded shared object files work fine.

• Disallow inter-module dependencies at the C level.
  If a module needs functionality from another module, it
  can only be accessed through indirection through the
  module handle, not by virtue of being linked together.

Comment 50

Date: 2003-01-24 16:50:48 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

The following dependencies cuurrently exist (gleaned from
Makefile.am):

enum depends on streams
salgebra depends on algebra
tpcd depends on cluster
unix depends on blob
vector depends on mmath
qt depends on uchr, bitvector, stats
ddbench depends on xtables, streams, enum

The following actually cause a crash when you just load and
drop the module:
ddbench, enum, qt, unix.

Comment 51

Date: 2003-01-27 14:36:53 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

By not linking modules with other modules I found the
following real dependencies:
unix depends on blob (TYPE_blob);
ddbench depends on enum (enum_chktpe);
qt depends on stats (stats_report).

Comment 52

Date: 2003-01-29 13:12:27 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

Fixed.
The before tag is Monet_4-3-7_BeforeModuleDependencyFix, the
after tag is Monet_4-3-7_AfterModuleDependencyFix.

Comment 53

Date: 2005-10-06 13:27:04 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
This bug is tested by the availability tests

Comment 54

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 674057 at http://sourceforge.net/support/tracker.php?aid=674057

Date: 2003-12-28 05:44:33 +0100
From: @mlkersten
To: Peter Boncz <>
Version: -- development

Last updated: 2004-01-06 10:47:11 +0100

Comment 218

Date: 2003-12-28 17:44:33 +0100
From: @mlkersten

The following one-liner script when ran against
MapiClient (and from Mcockpit) caused the server to
hang on an internal Flex error. Perhaps related to the
recent changes made by Peter in the parser?

Module loaded (sql_server2)
------------------Input---------
VAR name := nil; IF
(view_bbp_name.reverse.exist("address_name")) {
name := bat("address_name");} ELSE { name :=
new(oid,str); name.rename("address_name");
name.persists(true);}
--------- Mserver response------------
fatal flex scanner internal error -- end of buffer missed

Comment 219

Date: 2004-01-06 15:02:45 +0100
From: @drstmane

Logged In: YES
user_id=572415

Tests
MonetDB/tests/BugsViaSourgeforce/Tests/ID.866700
and
sql/src/test/Tests/ID.866700
try but fail to reproduce the bug.
Are the tests wrong, or has the bug been fixed?

Stefan

Comment 220

Date: 2004-01-06 22:47:11 +0100
From: @mlkersten

Logged In: YES
user_id=490798

Problem occurs in MapiClient sending malicious statements due to
array overflow. Not critical anymore

Comment 221

Date: 2005-10-06 15:34:18 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
tests/BugsViaSourgeforce/Tests/ID.866700.milC

Comment 222

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 866700 at http://sourceforge.net/support/tracker.php?aid=866700

Date: 2003-12-01 04:58:44 +0100
From: @swingbit
To: @njnes
Version: -- development

Last updated: 2003-12-02 09:27:59 +0100

Comment 177

Date: 2003-12-01 16:58:44 +0100
From: @swingbit

Trying to create 2 BATs with the same name,

monet> a := new(int, int).rename("a");
monet> b := new(int, int).rename("a");

leads to an error like:

!ERROR: rename(<tmp_177>,a): operation failed

when these commands are issued from Mserver console.

Trying to do the same from MapiClient causes it to hang
on the second "rename".

So far I haven't found the same behaviour on other
"wrong" commands.

Comment 178

Date: 2003-12-02 09:27:59 +0100
From: @njnes

Logged In: YES
user_id=43556

fixed by adding newlines to mil ERROR statements

Comment 179

Date: 2005-10-06 15:00:14 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST / SUCCESS
Test added as
tests/BugDay_2005-10-06_4.9.3/Tests/MapiClient_hang_on_rename.SF-852148.milC

Comment 180

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 852148 at http://sourceforge.net/support/tracker.php?aid=852148

Date: 2002-11-02 02:57:45 +0100
From: @drstmane
To: @njnes
Version: -- development

Last updated: 2002-11-23 05:41:20 +0100

Comment 26

Date: 2002-11-02 14:57:45 +0100
From: @drstmane

In some cases, kunique fails on a str column that
contains >1 empty strings (""). See example below,
and/or the respective test script and stable output in
tests/BugsViaSourgeforce[/Tests]; the files are named
using the ID of this bugreport.

The problem also occurs with
test/Availability[/Tests]/01_Modules_static, most
probably since Peter Boncz added the unicode support on
Oct 9 2002.
I have no idea, where the problem might come from.
Note also, that the problem seems to occur
"non-deterministically"...

========
var v1 := new(void,str).seqbase(0@0);

v1.insert(nil,"");
v1.insert(nil,"b");
v1.insert(nil,"");
v1.insert(nil,"c");
v1.insert(nil,"");
v1.insert(nil,"a");
v1.insert(nil,"");
v1.print;

BAT: tmp_27
(void) (str)

[ 0@0, "" ]
[ 1@0, "b" ]
[ 2@0, "" ]
[ 3@0, "c" ]
[ 4@0, "" ]
[ 5@0, "a" ]
[ 6@0, "" ]

var v2 := v1.reverse.kunique.reverse;
!WARNING: BATpropcheck: BAT tmp_26 was incorrectly
marked keyed!
var v3 := v2.reverse.sort.reverse;
v3.print;

BAT: tmp_28
(oid) (str)

[ 4@0, "" ]
[ 6@0, "" ]
[ 0@0, "" ]
[ 5@0, "a" ]
[ 1@0, "b" ]
[ 3@0, "c" ]

Comment 27

Date: 2002-11-23 17:41:20 +0100
From: @njnes

Logged In: YES
user_id=43556

The strCmp wraper calling strCmpNoNil skipt over the first
byte which is
wrong with 0 length strings
(problem did occure in many other functions then kunique, all
bat ops with strings should have been affected)

Comment 28

Date: 2005-10-06 13:08:45 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: CLAIMED BY niels
BugDay_2005-10-06: Done/SUCCES
Test allready available via
tests/BugsViaSourgeforce/Tests/ID.632575.milS

Comment 29

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 632575 at http://sourceforge.net/support/tracker.php?aid=632575

Date: 2003-12-04 09:37:52 +0100
From: @mlkersten
To: @njnes
Version: -- development

Last updated: 2003-12-05 11:09:31 +0100

Comment 206

Date: 2003-12-04 21:37:52 +0100
From: @mlkersten

De volgende query:

SELECT * FROM a LEFT JOIN b ON a.var1 = b.id WHERE
a.var1 = 'aJan';

via de Mapi.java zorgt dat de mapi eeuwig blijft hangen,
en Msql geeft als uitvoer:

SQL ERROR -1 4: (1) parse error at token (306): join in
statement: select * from a left join in:
SELECT * FROM a LEFT JOIN b ON a.var1 = b.id WHERE
a.var1 = 'aJan';

Postgres geeft op deze query wel gewoon resultaten
terug.

Ondersteund Monet geen joins?!?

Comment 207

Date: 2003-12-05 11:09:31 +0100
From: @njnes

Logged In: YES
user_id=43556

fixed in cvs

scoping bug where a.* failed
parser now assumes OUTER when it only findes LEFT/RIGHT/FULL

Comment 208

Date: 2005-10-06 15:30:11 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
Test exists as
src/test/bugs/foreignkey_leftjoin-bug-sf-854312.sql

Comment 209

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 854312 at http://sourceforge.net/support/tracker.php?aid=854312

Date: 2003-01-31 10:19:00 +0100
From: @sjoerdmullender
To: @sjoerdmullender
Version: -- development

Last updated: 2009-10-02 06:07:48 +0200

Comment 55

Date: 2003-01-31 10:19:00 +0100
From: @sjoerdmullender

The tests of the isnan / isinf / finite functions on
Windows give incorrect results.
The reason (or in any case, one reason) is that the
method used to obtain a NaN doesn't work on Windows.
The test uses log(-1.0) to obtain a NaN, however this
doesn't seem to do the trick. Use the attached program
to obtain the below results:

Cygwin:

• ./a.exe
  0 0: isnan 0 isinf 0 finite 1 fpclassify 2 0000000000000000
  NAN NaN: isnan 1 isinf 0 finite 0 fpclassify 0
  000000000000f87f
  z/z NaN: isnan 1 isinf 0 finite 0 fpclassify 0
  000000000000f8ff
  log(-1.0) -Inf: isnan 0 isinf 1 finite 0 fpclassify 1
  000000000000f0ff
  pow(2.0, 5000.0) Inf: isnan 0 isinf 1 finite 0
  fpclassify 1 000000000000f07f
  pow(-2.0, 5001.0) -Inf: isnan 0 isinf 1 finite 0
  fpclassify 1 000000000000f0ff

Native Windows:
C:\Documents and Settings\sjoerd\My Documents>x.exe
0 0: isnan 0 isinf 0 finite 1 fpclassify 64
0000000000000000
z/z -1.IND: isnan 1 isinf 0 finite 0 fpclassify 2
000000000000f8ff
log(-1.0) -1.IND: isnan 1 isinf 0 finite 0 fpclassify
2 000000000000f8ff
pow(2.0, 5000.0) 1.INF: isnan 0 isinf 1 finite 0
fpclassify 512 000000000000f07f
pow(-2.0, 5001.0) -1.INF: isnan 0 isinf -1 finite 0
fpclassify 4 000000000000f0ff

Comment 56

Date: 2003-01-31 10:22:28 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

I did attacht the file, and I did check the checkmark, but
somehow the file was still not attached. Bloody Windows or
bloody Mozilla?

Comment 57

Date: 2004-03-11 08:54:44 +0100
From: @njnes

Logged In: YES
user_id=43556

windows short comming

Comment 58

Date: 2005-10-06 13:29:17 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST exists
Test exists as src/modules/plain/Tests/mmath.milM

Comment 59

Date: 2009-10-02 18:07:43 +0200
From: @sjoerdmullender

The test output has long since been changed because the method used to produce the NaNs produces a range error instead.
If I create a NaN in C and use that to test the mmath function isnan() it correctly reports that the value is a NaN.
Therefore I now close this bug.

Comment 60

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 678034 at http://sourceforge.net/support/tracker.php?aid=678034

Date: 2003-11-27 10:46:39 +0100
From: @menzowindhouwer
To: Peter Boncz <>
Version: -- development
CC: martin.van.dinther

Last updated: 2014-04-18 18:14:01 +0200

Comment 162

Date: 2003-11-27 10:46:39 +0100
From: @menzowindhouwer

when a script (or a command line) is parsed module
commands are recognized and the modules are loaded
while the MIL is parsed. When the module contains the
definition of an ADT a variable containing the ADT
index is created. This variable should be available
already, as the MIL commands following the module load
may refer to it. In the current Monet version this
variable isn't available, so 'module(url);VAR u :=
new(void,url);' fails as the variable 'url' is unknown ...

!WARNING: interpret: convert identifier 'url' to string.
!ERROR: interpret: no matching MIL operator to
'new(int, str)'.
!MAYBE YOU MEAN:
! new(int, int, lng) : BAT[any,any]
! new(int, int, int) : BAT[any,any]
! new(int, int) : BAT[any,any]

See the test src/monet/Tests/modADTvar.milM

Comment 163

Date: 2003-11-27 10:56:33 +0100
From: @sjoerdmullender

Logged In: YES
user_id=43607

Assigned to Peter.

Comment 164

Date: 2003-12-11 00:12:18 +0100
From: @drstmane

Logged In: YES
user_id=572415

Bug has been fixed by Martin's and Sjoerd's recent changes
in the interpreter.

Comment 165

Date: 2005-10-06 14:40:15 +0200
From: @njnes

Logged In: YES
user_id=43556

BugDay_2005-10-06: Claimed by niels
BugDay_2005-10-06: TEST / SUCCESS
Test added as
tests/BugDay_2005-10-06_4.9.3/Tests/monet_daemon.SF-623743.milS

Comment 166

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 850137 at http://sourceforge.net/support/tracker.php?aid=850137

Comment 19763

Date: 2014-04-18 18:14:01 +0200
From: @mlkersten

*** Bug #3475 has been marked as a duplicate of this bug. ***