Is there anyone that can think of a solution for this problem?
cc1: warnings being treated as errors
/Volumes/Scratch/monetdb/stable/monetdb/src/modules/plain/bat.mx: In function 'local_itoa':
/Volumes/Scratch/monetdb/stable/monetdb/src/modules/plain/bat.mx:1253: warning: format '%zd' expects type 'signed size_t', but argument 4 has type 'ssize_t'
I mean... is there a difference between "signed size_t" and "ssize_t"?
Ehrm.
[Orion:src/modules/plain] fabian% uname -a
Darwin Orion.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc PowerBook4,3 Darwin
[Orion:src/modules/plain] fabian% gcc --version
gcc (GCC) 4.0.1 (Apple Computer, Inc. build 5341)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Probably just need to compile without -Werror.
perhaps its triggered by Niels newest ``any type'' changes in
bat_store.mx -- just guessing.
On 04/27/2007 03:47 PM, Jan Rittinger wrote with possible deletions:
> I just managed to install gdb as well and it seems like it is memory
> related (BTW pathfinder works).
>
> gdb M4:
> MonetDB>module(sql_server);
> [New Thread 1082132832 (LWP 896)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 182925371136 (LWP 887)]
> 0x0000002a97183c1f in memcpy () from /lib64/tls/libc.so.6
> (gdb) bt
> #0 0x0000002a97183c1f in memcpy () from /lib64/tls/libc.so.6
> #1 0x0000002a9f960718 in ?? ()
> #2 0x0000002a965eff6c in HEAPcopy () from
> /home/ntap/rittinge/work/MonetDB/Linux/lib64/libbat.so.0
> #3 0x0000002a966b340e in BATcopy () from
> /home/ntap/rittinge/work/MonetDB/Linux/lib64/libbat.so.0
> #4 0x0000002a965f0a34 in BATkdiff () from
> /home/ntap/rittinge/work/MonetDB/Linux/lib64/libbat.so.0
> #5 0x0000002a9e8713f9 in load_trans () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/MonetDB4/lib/lib_sql_server.so
>
> #6 0x0000002a9e873b65 in store_init () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/MonetDB4/lib/lib_sql_server.so
>
> #7 0x0000002a9e846b1a in mvc_init () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/MonetDB4/lib/lib_sql_server.so
>
> #8 0x0000002a9e80276a in sql_frontend_wrap () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/MonetDB4/lib/lib_sql_server.so
>
> #9 0x0000002a95f8bd48 in interpret () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #10 0x0000002a95f9c0aa in interpret_assignment () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #11 0x0000002a95f8bfb6 in interpret () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #12 0x0000002a95f9bb29 in interpret_seqblock () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #13 0x0000002a95f8bf98 in interpret () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #14 0x0000002a95a32d44 in CMDcatch () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/MonetDB4/lib/lib_builtin.so.0
> #15 0x0000002a95f8bd48 in interpret () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #16 0x0000002a95f9bebb in interpret_assignment () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #17 0x0000002a95f9c2af in interpret_var () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #18 0x0000002a95f8c118 in interpret () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #19 0x0000002a95f9bb29 in interpret_seqblock () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #20 0x0000002a95f8bf98 in interpret () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #21 0x0000002a95f8c4ec in interpret () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #22 0x0000002a95f9bb29 in interpret_seqblock () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #23 0x0000002a95f8bf98 in interpret () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #24 0x0000002a95f9e289 in handleRequest () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #25 0x0000002a95f9efc9 in doRequest () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #26 0x0000002a95fe280e in monetInterpreter () from
> /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0
> #27 0x00000000004020f1 in main ()
>
> gdb M5:
>
> (gdb) run --dbinit="include sql;"
> Starting program: /home/ntap/rittinge/work/MonetDB4/Linux/bin/mserver5
> --dbinit="include sql;"
> [Thread debugging using libthread_db enabled]
> [New Thread 182918905952 (LWP 938)]
> # MonetDB Server v5.0.0_beta2_1
> # Copyright (c) 1993-2007 CWI, all rights reserved
> # Compiled for x86_64-suse-linux/64bit with 32bit OIDs dynamically linked
> # dbname:demo
> # Visit http://monetdb.cwi.nl/ for further information
> [New Thread 1082132832 (LWP 939)]
> #warning: please don't forget to set your vault key!
> #(see /home/ntap/rittinge/work/MonetDB4/Linux//etc/monetdb5.conf)
> >
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1082132832 (LWP 939)]
> 0x0000002a969f8c1f in memcpy () from /lib64/tls/libc.so.6
> (gdb) bt
> #0 0x0000002a969f8c1f in memcpy () from /lib64/tls/libc.so.6
> #1 0x0000000000b373d8 in ?? ()
> #2 0x0000002a95d2bf6c in HEAPcopy () from
> /home/ntap/rittinge/work/MonetDB/Linux/lib64/libbat.so.0
> #3 0x0000002a95def40e in BATcopy () from
> /home/ntap/rittinge/work/MonetDB/Linux/lib64/libbat.so.0
> #4 0x0000002a95d2ca34 in BATkdiff () from
> /home/ntap/rittinge/work/MonetDB/Linux/lib64/libbat.so.0
> #5 0x0000002aa0403c59 in load_trans () from
> /home/ntap/rittinge/work/MonetDB4/Linux//lib64/MonetDB5/lib/lib_sql.so
> #6 0x0000002aa04063c5 in store_init () from
> /home/ntap/rittinge/work/MonetDB4/Linux//lib64/MonetDB5/lib/lib_sql.so
> #7 0x0000002aa03d937a in mvc_init () from
> /home/ntap/rittinge/work/MonetDB4/Linux//lib64/MonetDB5/lib/lib_sql.so
> #8 0x0000002aa039507b in SQLinit () from
> /home/ntap/rittinge/work/MonetDB4/Linux//lib64/MonetDB5/lib/lib_sql.so
> #9 0x0000002a956ad57b in initScenario () from
> /home/ntap/rittinge/work/MonetDB4/Linux//lib64/libmal.so.0
> #10 0x0000002a956ad81f in setScenario () from
> /home/ntap/rittinge/work/MonetDB4/Linux//lib64/libmal.so.0
> #11 0x0000002a9568528b in MSscheduleClient () from
> /home/ntap/rittinge/work/MonetDB4/Linux//lib64/libmal.so.0
> #12 0x0000002a9f80e371 in doChallenge () from
> /home/ntap/rittinge/work/MonetDB4/Linux//lib64/MonetDB5/lib/lib_mserver.so
> #13 0x0000002a9f80ece9 in SERVERlistenThread () from
> /home/ntap/rittinge/work/MonetDB4/Linux//lib64/MonetDB5/lib/lib_mserver.so
> #14 0x0000002a9663db8f in start_thread () from /lib64/tls/libpthread.so.0
> #15 0x0000002a96a414b3 in clone () from /lib64/tls/libc.so.6
>
--
Jan Rittinger
Database Systems
Technische Universität München (Germany)
http://www-db.in.tum.de/~rittinge/
Project account wrote:
> Testing results of sql in /export/scratch2/monet/Testing/Current with GDKdebug=10 DIFFER from those of 2007.04.28_04-03-41 !
>
> Maybe YOUR checkins since 28.04.2007, 04:03:41 caused some of the problems:
>
> buildtools
> MonetDB
> clients
> MonetDB4
> MonetDB5 mk(a)cwi.nl
> sql mk(a)cwi.nl niels(a)cwi.nl romulog(a)users.sourceforge.net
>
> Check http://monetdb.cwi.nl/Development/TestWeb/Current/sql/ for details !
>
>
> Old file: Mtest10..2007.04.28_04-03-41..out
> New file: Mtest10..2007.04.29_04-16-39..out
> ===========================================
>
>
> Summary:
> ========
>
> * 1 New systems
> !! 3 Systems now DON'T produce output !!
I compiled my sources before the commit with optimization on:
--enable-strict --enable-assert --enable-optimize --enable-bits=64
Why the variable initialized, but never used is not detected by this
compilation? Which compilation must be done to detect these kind of errors?
Regards,
Romulo
Hi all,
Recently Jan Flokstra added for me a new extension module for
MonetDB/XQuery, called "probxml", in the pathfinder source tree. In this
way, I now have a good place to put the additional C-functions and
MIL-procs needed for probabilistic XML. I have, however, also XQuery
functions, i.e., an .xq file with "declare function foo (...) as ... {
... };" in it. To use them, a query needs to add the declaration "import
module namespace pxml = URL at LOCATION;"
My question is where to place the .xq file in the pathfinder source tree
and what to use as URL and LOCATION. Since this is a rather generic
source tree organization question, I decided to pose it here.
Kind regards,
Maurice.
--
----------------------------------------------------------------------
Dr.Ir. M. van Keulen - Assistant Professor, Data Management Technology
Univ. of Twente, Dept of EEMCS, POBox 217, 7500 AE Enschede, Netherlands
Email: m.vankeulen(a)utwente.nl, Phone: +31 534893688, Fax: +31 534892927
Room: ZI 3039, WWW: http://www.cs.utwente.nl/~keulen
Hello,
The following links of the M4 documentation
(http://www.monetdb.nl/projects/monetdb/MonetDB/Version4/Documentation/monet…)
are dead:
- Overview
- MIL Guide
- MEL Guide
- Kernel Guide
Clicking on thoese links results in:
[an error occurred while processing this directive]
Will someone please have a look at it?
Thanks,
Jennie
Fabian wrote:
> Update of /cvsroot/monetdb/MonetDB5/src/modules/atoms
> In directory sc8-pr-cvs16:/tmp/cvs-serv28157
>
> Modified Files:
> Makefile.ag
> Log Message:
> color.mx uses floor, which (at least on my machine -- for as long as
> it's running) needs -lm during linking.
Have no libm on W2K. Other modules abuse LDFLAGS = -lm and this
seems to be ignored be the Makefile.msc generator - so LDFLAGS
works somehow as a workaround. Whats your policy in this regard?
Steffen
Sjoerd Mullender wrote:
> Update of /cvsroot/monetdb/MonetDB5/src/mal
> In directory sc8-pr-cvs16:/tmp/cvs-serv372
>
> Modified Files:
> mal_interpreter.mx
> Log Message:
> Set trivially settable properties.
> This is done in a central place so that as little code as possible
> needs to be changed, and the effect is a big as possible.
This change greatly increases the need to push for 'private BATs as
default', because every call to BATdescriptor initiates expensive locking.
At this level in the interpreter it doubles the overhead of accessing
the BATs!
Otherwise, this change have to be moved to the individual operations
with, of course, the increased maintenance.