- developers-list - monetdb.org

Re: [Monetdb-developers] [Monetdb-checkins] buildtools/autogen/autogen am.py, , 1.45, 1.46 msc.py, , 1.34, 1.35
by Stefan Manegold 04 Sep '07

04 Sep '07

On Tue, Sep 04, 2007 at 12:30:16PM +0000, Sjoerd Mullender wrote: > Update of /cvsroot/monetdb/buildtools/autogen/autogen > In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv27558/autogen/autogen > > Modified Files: > am.py msc.py > Log Message: > Make it possible to have conditional symlinks. Great. THANKS! I missed that one the other day, but then forgot about it ... Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 0

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/compiler compile.c, , 1.120, 1.121
by Sjoerd Mullender 04 Sep '07

04 Sep '07

Jan Rittinger wrote: > Update of /cvsroot/monetdb/pathfinder/compiler > In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv19410 > > Modified Files: > compile.c > Log Message: > -- Cleaned up the SQL code generation. > > -- Completed Manuels checkin in compile.c from 08/21. > > > Index: compile.c > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/compiler/compile.c,v > retrieving revision 1.120 > retrieving revision 1.121 > diff -u -d -r1.120 -r1.121 > --- compile.c 21 Aug 2007 10:17:29 -0000 1.120 > +++ compile.c 4 Sep 2007 10:01:30 -0000 1.121 > @@ -28,6 +28,7 @@ > * Universitaet Muenchen, respectively. All Rights Reserved. > * > * $Id$ > + * $Id$ > */ > > Isn't this overdoing it just a little bit? ;-) -- Sjoerd Mullender

2 1

Re: [Monetdb-developers] [Monetdb-checkins] MonetDB5/src/tools monetdb.mx, , 1.19, 1.20
by Sjoerd Mullender 31 Aug '07

31 Aug '07

On 2007-08-31 19:14, Fabian wrote: > Update of /cvsroot/monetdb/MonetDB5/src/tools > In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv4192 > > Modified Files: > monetdb.mx > Log Message: > reduce overkill > > > Index: monetdb.mx > =================================================================== > RCS file: /cvsroot/monetdb/MonetDB5/src/tools/monetdb.mx,v > retrieving revision 1.19 > retrieving revision 1.20 > diff -u -d -r1.19 -r1.20 > --- monetdb.mx 31 Aug 2007 17:09:13 -0000 1.19 > +++ monetdb.mx 31 Aug 2007 17:14:21 -0000 1.20 > @@ -610,7 +610,6 @@ > } > > if (stats != NULL) { > - char path[8096]; > err e; > > if (stats->state == SABdbRunning) { > @@ -627,11 +626,12 @@ > } > > if (force == 0) { > + char answ; > printf("you are about to remove database %s\n", dbname); > printf("ALL data in this database will get lost, " > "are you sure? [y/N] "); > - scanf("%c", path); > - if (path[0] == 'y' || path[0] == 'Y') { > + scanf("%c", &answ); > + if (answ == 'y' || answ == 'Y') { > /* do it! */ > } else { > printf("battle control terminated\n"); > > Even better would be to use getchar(). scanf is still considerable overkill for reading a character. But also remember to read the rest of the line (also when using scanf). -- Sjoerd Mullender

1 0

[Monetdb-developers] Some help to understand this error output from m5...
by Romulo Goncalves 31 Aug '07

31 Aug '07

I am using monetBD5 with datacell module and I got the following crash. I know it is related with memory map and maybe a valgrind execution would be a nice thing to do. However, I would like more feedback from the experts: insert 1188567930287233: line :[0,3] /ufs/goncalve/scratch/MonetDB/MonetDB5/lib/libmal.so.0[0x2aaaaaace64f] /ufs/goncalve/scratch/MonetDB/MonetDB5/lib/libmal.so.0(reenterMAL+0x7a)[0x2aaaaaac94d5] /ufs/goncalve/scratch/MonetDB/MonetDB5/lib/MonetDB5/lib/lib_datacell.so[0x2aaabccb2207] /lib64/libpthread.so.0[0x33dba062f7] /lib64/libc.so.6(clone+0x6d)[0x33daace86d] ======= Memory map: ======== 00400000-00405000 r-xp 00000000 08:13 9634823 /net/amelia/export/scratch1/goncalve/MonetDB/MonetDB5/bin/mserver5 00604000-00605000 rw-p 00004000 08:13 9634823 /net/amelia/export/scratch1/goncalve/MonetDB/MonetDB5/bin/mserver5 00605000-00d4e000 rw-p 00605000 00:00 0 [heap] 40000000-40001000 ---p 40000000 00:00 0 40001000-40801000 rw-p 40001000 00:00 0 40801000-40802000 ---p 40801000 00:00 0 40802000-41002000 rw-p 40802000 00:00 0 41002000-41003000 ---p 41002000 00:00 0 41003000-41803000 rw-p 41003000 00:00 0 41803000-41804000 ---p 41803000 00:00 0 41804000-42004000 rw-p 41804000 00:00 0 42004000-42005000 ---p 42004000 00:00 0 42005000-42805000 rw-p 42005000 00:00 0 42805000-42806000 ---p 42805000 00:00 0 42806000-43006000 rw-p 42806000 00:00 0 43006000-43007000 ---p 43006000 00:00 0 43007000-43807000 rw-p 43007000 00:00 0 33da600000-33da61a000 r-xp 00000000 08:15 2578621 /lib64/ld-2.5.so 33da819000-33da81a000 r--p 00019000 08:15 2578621 /lib64/ld-2.5.so 33da81a000-33da81b000 rw-p 0001a000 08:15 2578621 /lib64/ld-2.5.so 33daa00000-33dab46000 r-xp 00000000 08:15 2578761 /lib64/libc-2.5.so 33dab46000-33dad46000 ---p 00146000 08:15 2578761 /lib64/libc-2.5.so 33dad46000-33dad4a000 r--p 00146000 08:15 2578761 /lib64/libc-2.5.so 33dad4a000-33dad4b000 rw-p 0014a000 08:15 2578761 /lib64/libc-2.5.so 33dad4b000-33dad50000 rw-p 33dad4b000 00:00 0 33dae00000-33dae82000 r-xp 00000000 08:15 2578841 /lib64/libm-2.5.so 33dae82000-33db081000 ---p 00082000 08:15 2578841 /lib64/libm-2.5.so 33db081000-33db082000 r--p 00081000 08:15 2578841 /lib64/libm-2.5.so 33db082000-33db083000 rw-p 00082000 08:15 2578841 /lib64/libm-2.5.so 33db200000-33db202000 r-xp 00000000 08:15 2578887 /lib64/libdl-2.5.so 33db202000-33db402000 ---p 00002000 08:15 2578887 /lib64/libdl-2.5.so 33db402000-33db403000 r--p 00002000 08:15 2578887 /lib64/libdl-2.5.so 33db403000-33db404000 rw-p 00003000 08:15 2578887 /lib64/libdl-2.5.so 33db600000-33db614000 r-xp 00000000 08:15 4234966 /usr/lib64/libz.so.1.2.3 33db614000-33db813000 ---p 00014000 08:15 4234966 /usr/lib64/libz.so.1.2.3 33db813000-33db814000 rw-p 00013000 08:15 4234966 /usr/lib64/libz.so.1.2.3 33dba00000-33dba15000 r-xp 00000000 08:15 2578924 /lib64/libpthread-2.5.so 33dba15000-33dbc14000 ---p 00015000 08:15 2578924 /lib64/libpthread-2.5.so 33dbc14000-33dbc15000 r--p 00014000 08:15 2578924 /lib64/libpthread-2.5.so 33dbc15000-33dbc16000 rw-p 00015000 08:15 2578924 /lib64/libpthread-2.5.so 33dbc16000-33dbc1a000 rw-p 33dbc16000 00:00 0 33dce00000-33dce35000 r-xp 00000000 08:15 4225510 /usr/lib64/libreadline.so.5.1 33dce35000-33dd034000 ---p 00035000 08:15 4225510 /usr/lib64/libreadline.so.5.1 33dd034000-33dd03c000 rw-p 00034000 08:15 4225510 /usr/lib64/libreadline.so.5.1 33dd03c000-33dd03d000 rw-p 33dd03c000 00:00 0 33de200000-33de203000 r-xp 00000000 08:15 2578939 /lib64/libtermcap.so.2.0.8 33de203000-33de402000 ---p 00003000 08:15 2578939 /lib64/libtermcap.so.2.0.8 33de402000-33de403000 rw-p 00002000 08 Program received signal SIGABRT, Aborted. [Switching to Thread 1124096320 (LWP 24972)] 0x00000033daa30065 in raise () from /lib64/libc.so.6 (gdb) up #1 0x00000033daa31b00 in abort () from /lib64/libc.so.6 (gdb) up #2 0x00000033daa6825b in __libc_message () from /lib64/libc.so.6 (gdb) up #3 0x00000033daa6f504 in _int_free () from /lib64/libc.so.6 (gdb) up #4 0x00000033daa72b2c in free () from /lib64/libc.so.6 (gdb) up #5 0x00002aaaab40b504 in GDKfree (blk=0xa9e948) at /ufs/goncalve/MonetDB/MonetDB/src/gdk/gdk_utils.mx:1140 1140 free(((char *) s) - 8); (gdb) up #6 0x00002aaaab36e349 in HEAPfree (h=0xac36a0) at /ufs/goncalve/MonetDB/MonetDB/src/gdk/gdk_heap.mx:265 265 GDKfree(h->base); (gdb) up #7 0x00002aaaab4a907a in heapfree (src=0xac36a0, dst=0x43004290) at /ufs/goncalve/MonetDB/MonetDB/src/gdk/gdk_bat.mx:630 630 HEAPfree(src); Regards, Romulo

2 2

[Monetdb-developers] Release plans
by Sjoerd Mullender 29 Aug '07

29 Aug '07

We are planning to start a new "Stable" branch in about one to two weeks time in preparation for a new release. This new release will consist of all packages. I would like to ask all developers to be conservative with your checkins until that time. This does not mean you're not allowed to check in any fixes or new features, just that I would like to urge you to make extra sure that your changes work. Also, by checking in any changes before we create this new branch, you commit yourself to making sure that the features work flawlessly in two weeks' time. This new release will not contain many new features. It is mostly a bug-fix release with some new stuff. We wanted to do a partial release, but can't because of slight incompatibilities between the current Development and Stable branches, so we need to release either nothing or everything. We've chosen everything. By the way, this is independent from the SQL bug fix release which is going to be released today (and hence will be superseded in a few weeks time). -- Sjoerd Mullender

1 0

Re: [Monetdb-developers] [Monetdb-checkins] clients/src/mapilib Mapi.mx, , 1.19, 1.20
by Sjoerd Mullender 28 Aug '07

28 Aug '07

Shouldn't you compile *before* you check in? Romulo Goncalves wrote: > Update of /cvsroot/monetdb/clients/src/mapilib > In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv7913 > > Modified Files: > Mapi.mx > Log Message: > Include missing library (sys/timeb) to resolve compilation problems on windows. > > > Index: Mapi.mx > =================================================================== > RCS file: /cvsroot/monetdb/clients/src/mapilib/Mapi.mx,v > retrieving revision 1.19 > retrieving revision 1.20 > diff -u -d -r1.19 -r1.20 > --- Mapi.mx 24 Aug 2007 15:18:29 -0000 1.19 > +++ Mapi.mx 28 Aug 2007 08:50:07 -0000 1.20 > @@ -701,6 +701,11 @@ > #include <string.h> > #include <memory.h> > > +/*additional definitions for date and time/* > +#ifdef HAVE_FTIME > +#include <sys/timeb.h> > +#endif > + > #if TIME_WITH_SYS_TIME > # include <sys/time.h> > # include <time.h> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Monetdb-checkins mailing list > Monetdb-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-checkins -- Sjoerd Mullender

3 4

Re: [Monetdb-developers] [Monetdb-checkins] clients/src/mapiclient MapiClient.mx, , 1.73, 1.74
by Sjoerd Mullender 28 Aug '07

28 Aug '07

Wrong on (almost) all counts. It's amazing. Martin Kersten wrote: > Update of /cvsroot/monetdb/clients/src/mapiclient > In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv10235 > > Modified Files: > MapiClient.mx > Log Message: > Move the mode change into one place. Set the default rendering of MAL to This I had already done in the previous checkin, but better because more complete. > align with the console. Best option still is to make mclient part of This is debatable. > the server too. This has *nothing* to do with this checkin (and is debatable anyway). > > > Index: MapiClient.mx > =================================================================== > RCS file: /cvsroot/monetdb/clients/src/mapiclient/MapiClient.mx,v > retrieving revision 1.73 > retrieving revision 1.74 > diff -u -d -r1.73 -r1.74 > --- MapiClient.mx 28 Aug 2007 07:43:07 -0000 1.73 > +++ MapiClient.mx 28 Aug 2007 08:03:57 -0000 1.74 > @@ -243,6 +243,15 @@ > } > > static void > +modeChange(char *reply){ > + if (strstr(reply, "mdb>#EOD")){ > + setPrompt(); > + } else > + if(strncmp(reply,"mdb>",4)==0) > + sprintf(promptbuf,"mdb>"); > +} > + > +static void > SQLsetSpecial(const char *command) > { > if (mode == SQL && command) { > @@ -371,6 +380,7 @@ > do { > if ((reply = fetch_line(hdl)) == NULL) > return 0; > + modeChange(reply); > } while (*reply != '[' && *reply != '='); > return mapi_split_line(hdl); > } Now the change is checked twice. > @@ -412,7 +422,8 @@ > { > char *line; > > - while ((line = fetch_line(hdl)) != 0) { > + while ((line = mapi_fetch_line(hdl)) != 0) { > + modeChange(line); > if (*line == '=') > line++; > fprintf(toConsole, "%s\n", line); Why did you undo my change which did this already? > @@ -1310,7 +1321,7 @@ > continue; > } > case '?': > - if (!isspace((int) line[2]) && mode == MAL) { > + if (mode==MAL ||debugMode() ){ > strcpy(line, line + 1); > break; > } This is the only part of the checkin that has merit, except a comment that the line with ? is sent to the server might be useful. > @@ -1756,7 +1767,8 @@ > > /* default formatter depends on whether we're interactive */ > if (formatter == NOformatter) > - formatter = interactive && interactive_stdin && mode != XQUERY ? TABLEformatter : RAWformatter; > + formatter = interactive && interactive_stdin && mode != XQUERY ? > + (mode==MAL?RAWformatter: TABLEformatter) : RAWformatter; > > if (command) { > /* execute from command-line */ > > If you really insist that in MAL mode the default should be RAW, then write it like this: formatter = interactive && interactive_stdin && mode != XQUERY && mode != MAL ? TABLEformatter : RAWformatter; > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Monetdb-checkins mailing list > Monetdb-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-checkins -- Sjoerd Mullender

2 2

Re: [Monetdb-developers] C-Store as MySQL storage engine
by Daniel J Abadi 26 Aug '07

26 Aug '07

Hi Dossy, There is no source repository/patch submission system in C-Store like you'd see in a mature open source community project. C-Store is only designed to be used as tool by academic researchers to look at the properties of column-oriented database query execution. It is far from a complete database system and parts of the code are quite rudimentary. Further, it has been neglected recently as many of the people who used to code for C-Store are now coding for Vertica. However, I like the idea of using a column-oriented database as a storage engine for MySQL. The thought actually crossed my mind as well recently when I read about Solid using their database as a storage engine for MySQL. My recommendation is that you look into the Monet instead of C-Store, however (http://monetdb.cwi.nl/) They have a far more complete open source column-oriented database. BTW: I came across your blog entry on Vertica recently. IMO, Vertica is much more than Sybase IQ, with far more advanced compression schemes, and the query executer is better able to take advantage of the column-oriented layout (data is kept in columns as long as possible and operated on as such). I think Vertica is about 10 times as fast as IQ. Your blog entry says you have been in contact recently with the director of sales at Vertica who can probably give you more information. D On Fri, 24 Aug 2007, Dossy Shiobara wrote: > Hi! > > Thanks for the work on C-Store and releasing it as open source under the > BSD license. > > Is there a source repository for the project? What's the process for > submitting patches, etc.? > > I'm currently working on using/adapting C-Store as a storage engine for > MySQL. I anticipate needing to make a series of changes to the C-Store > 0.2 code to make this possible and I'd like to try and get those into > the official source tree. > > Thanks, > > -- Dossy > > -- > Dossy Shiobara | dossy(a)panoptic.com | http://dossy.org/ > Panoptic Computer Network | http://panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70) > >

1 0

Re: [Monetdb-developers] Monet crashes with {sum} and {avg}
by Stefan Manegold 24 Aug '07

24 Aug '07

On Fri, Aug 24, 2007 at 11:00:05AM -0400, Agustin Schapira wrote: > Hi Niels, > > Sorry for the late reply --I have been travelling. > > Thanks a lot for the fix. I'm glad that the bug was easy to find and > correct. Which file should I change in the Mars-SuperBall > distribution? Is it > MonetDB4-server/MonetDB4/src/monet/monet_multiplex.mx yep, that's the file. Please let us konw, in case there are any problems with the patch --- I'm not sure, whether there might have been other changes to this file in CVS since the tarbaal was made. > And then should I re-run the monetdb-install.sh script? By the way, > is it possible to can have the script do all the make in a directory > other than /tmp, so I can keep the intermediate files around and I > don't have to recompile EVERYTHING whenever I make a change? I'm not familiar at all with the monetdb-install.sh script, but Niels and/or Fabian can probably help. Stefan > Thanks for the quick fix! > > -- Agustin > > > > >Hi Agustin, > > > >You found an interesting bug. The interpret_setaggr implementation has > >indeed many cases. One set of cases uses an intermediate bat in > >a strait forward (normal inserts) way. This case is the one you > >trigger. > >As soon as many values exist in your input bat the intermediate may > >need extending which happens. > >Now many of the other cases don't used the nested bat in such a > >clean way, but do 'dirty' tricks, such as reusing the heaps of your > >input > >bat. Therefor at the end of interpret_setaggr the nested (bats) are > >cleared by restoring the initial contend. > > > >As you can see restoring the 'initial' contend of the normal > >inserts with > >extends is a problem. I now have a fix for this which I hope to > >check in > >soon. > > > > > >Index: monet_multiplex.mx > >=================================================================== > >RCS file: /cvsroot/monetdb/MonetDB4/src/monet/monet_multiplex.mx,v > >retrieving revision 1.4 > >diff -u -r1.4 monet_multiplex.mx > >--- monet_multiplex.mx 20 Feb 2007 11:32:16 -0000 1.4 > >+++ monet_multiplex.mx 22 Aug 2007 19:06:44 -0000 > >@@ -1430,7 +1430,7 @@ > > BAT *b, *nested, *nested_rev, *histo = 0, *extent = 0, *ret > >= 0; > > size_t minpos; > > int ret_val = -1, varsize, head_type, hidden_vartype = 0; > >- int prop_key, prop_sorted = 0; > >+ int prop_key, prop_sorted = 0, restore = 1; > > GDKfcn direct_call = NULL, packed_call = NULL; > > ValRecord argv_bak; > > BUN p, q, r, s; > >@@ -1688,6 +1688,7 @@ > > assert(batbuns->base!=(ptr)1); > > nested->batDeleted = nested->batInserted = batbuns- > >>base; > > > >+ restore = 0; > > if (direct_call == NULL) { > > if (GDKdebug & 131072) > > THRprintf(GDKout, "setaggr impl: > >non-optimized hash\n"); > >@@ -1814,8 +1815,16 @@ > > argv[1] = argv_bak; > > > > /* undo all our hacks in nested before freeing it */ > >- *(BATstore*) nested = nested_bak; > >- *(BAT*) nested_rev = nested_rev_bak; > >+ if (restore) { > >+ *(BATstore*) nested = nested_bak; > >+ *(BAT*) nested_rev = nested_rev_bak; > >+ } else { > >+ BATstore *n = (BATstore*)nested; > >+ nested->H = &n->H; > >+ nested->T = &n->T; > >+ nested_rev->H = &n->T; > >+ nested_rev->T = &n->H; > >+ } > > BBPreclaim(nested); > > > > if (ret_val < 0) { > > > > > > > >Niels > >> > >>I am having more difficulties with {sum} and {avg}. The problems > >>happen both on 4.16.2 and 4.18.0, on Linux and OS X, compiled with > >>32- and 64- bits, with and without optimizations. > >> > >>I have been able to isolate the problem and write a simple test case > >>that shows the error. The attached file has the contents of a BAT; if > >>you save it and then run the following script: > >> > >>module(ascii_io); > >>var b:=bat(str,int).import(<filename>); > >>var x:={sum}(b); > >> > >>then you will get the following error: > >> > >>*** glibc detected *** double free or corruption (!prev): > >>0x00000000006a6360 *** > >> > >>and Monet will crash. > >> > >>The failing free is called from line 1819 of MonetDB4/src/monet/ > >>monet_multiplex.mx. It's inside the 'interpret_setaggr' function, and > >>it happens only with the 'non-optimized hash' implementation of > >>setaggr starting on line 1694 (in fact, if you sort the BAT before > >>calling {sum}, there will be no error. The same is true for example > >>when you call {count}, which uses a different implementation of > >>setaggr to process the {}). > >> > >>The failing free appears within the 'bunins_failed' label (line > >>1800), which in turn is called by the loop that processes the > >>aggregate when, I think, its call to 'bunins_unary' fails. Here's the > >>failing code, starting on line 1694: > >> > >> BATloopFast(extent, p, q, yy) { > >> [...] > >> if (BATprepareHash(b)) > >> goto bunins_failed; > >> HASHloop(b, b->hhash, hh, last) { > >> r = BUNptr(b, hh); > >> @:bunins_unary(r,hh)@ > >> } > >> [...] > >> } > >> > >>I don't understand why @:bunins_unary(r,hh)@ should fail. I have > >>noticed, however, that if I remove the last couple of lines from the > >>attached file then the call to {sum} doesn't crash. These last two > >>lines are exactly the same as others, so it's not their particular > >>value that matters, but rather the number of rows in the BAT with the > >>"Other" head value. > >> > >>Do you have any suggestions? Any other information that I can provide > >>to help you fix the problem? > >> > >>Thanks a lot again, > >> > >>-- Agustin > >> > >> > >>PS: On OS X, instead of the crash you get an error message "malloc: > >>*** Deallocation of a pointer not malloced: 0x281ee00; This could be > >>a double free(), or free() called with the middle of an allocated > >>block", but for all practical purposes it's the same: the free() is > >>called from the same place in interpret_setaggr. The difference is > >>just in the way the Mac equivalent of glibc handles the double free. > >> > > > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Course",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"Faculty",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"ResearchProject",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Staff",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Student",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > >>"Other",1 > > > >> > >> > >> > > > >>--------------------------------------------------------------------- > >>---- > >>This SF.net email is sponsored by: Splunk Inc. > >>Still grepping through log files to find problems? Stop. > >>Now Search log events and configuration files using AJAX and a > >>browser. > >>Download your FREE copy of Splunk now >> http://get.splunk.com/ > >>_______________________________________________ > >>Monetdb-developers mailing list > >>Monetdb-developers(a)lists.sourceforge.net > >>https://lists.sourceforge.net/lists/listinfo/monetdb-developers > > > > > >-- > > > >Niels Nes, Centre for Mathematics and Computer Science (CWI) > >Kruislaan 413, 1098 SJ Amsterdam, The Netherlands > >room C0.02, phone ++31 20 592-4098, fax ++31 20 592-4312 > >url: http://www.cwi.nl/~niels e-mail: Niels.Nes(a)cwi.nl -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

2 1

[Monetdb-developers] Monet crashes with {sum} and {avg}
by Agustin Schapira 22 Aug '07

22 Aug '07

Hi, I am having more difficulties with {sum} and {avg}. The problems happen both on 4.16.2 and 4.18.0, on Linux and OS X, compiled with 32- and 64- bits, with and without optimizations. I have been able to isolate the problem and write a simple test case that shows the error. The attached file has the contents of a BAT; if you save it and then run the following script: module(ascii_io); var b:=bat(str,int).import(<filename>); var x:={sum}(b); then you will get the following error: *** glibc detected *** double free or corruption (!prev): 0x00000000006a6360 *** and Monet will crash. The failing free is called from line 1819 of MonetDB4/src/monet/ monet_multiplex.mx. It's inside the 'interpret_setaggr' function, and it happens only with the 'non-optimized hash' implementation of setaggr starting on line 1694 (in fact, if you sort the BAT before calling {sum}, there will be no error. The same is true for example when you call {count}, which uses a different implementation of setaggr to process the {}). The failing free appears within the 'bunins_failed' label (line 1800), which in turn is called by the loop that processes the aggregate when, I think, its call to 'bunins_unary' fails. Here's the failing code, starting on line 1694: BATloopFast(extent, p, q, yy) { [...] if (BATprepareHash(b)) goto bunins_failed; HASHloop(b, b->hhash, hh, last) { r = BUNptr(b, hh); @:bunins_unary(r,hh)@ } [...] } I don't understand why @:bunins_unary(r,hh)@ should fail. I have noticed, however, that if I remove the last couple of lines from the attached file then the call to {sum} doesn't crash. These last two lines are exactly the same as others, so it's not their particular value that matters, but rather the number of rows in the BAT with the "Other" head value. Do you have any suggestions? Any other information that I can provide to help you fix the problem? Thanks a lot again, -- Agustin PS: On OS X, instead of the crash you get an error message "malloc: *** Deallocation of a pointer not malloced: 0x281ee00; This could be a double free(), or free() called with the middle of an allocated block", but for all practical purposes it's the same: the free() is called from the same place in interpret_setaggr. The difference is just in the way the Mac equivalent of glibc handles the double free.

2 1