developers-list December 2004

developers-list@monetdb.org

2 participants
2 discussions

[Monetdb-developers] Mserver hangs on quit(); on RedHat 8.0 (psyche)

by Stefan.Manegold＠cwi.nl

Hi again, with the latest MonetDB 4.5.0 on RedHat 8.0 (psyche), Jan (F.;-) experiences a "consistently" hang of the Mserver, once he tries to quit it. See below for details. It did work with older versions of MonetDB, but we hanven't locate more precisely, yet, since which version/code change the hang occurs. My question is, has anybody else ever experienced similar problems? I now vaguely recall, that there might have been some related issue, but I don't remember the details, yet --- could someone who does refresh my mind? Thank you very much in advance! Stefan Forwarded message: > From flokstra(a)cs.utwente.nl Wed Dec 15 09:30:02 2004 > X-Sieve: CMU Sieve 2.2 > Content-Type: text/plain; > charset="us-ascii" > From: Jan Flokstra <flokstra(a)cs.utwente.nl> > Organization: University Twente Enschede > To: Stefan.Manegold(a)cwi.nl (Stefan Manegold) > Subject: Re: Monet problem > Date: Wed, 15 Dec 2004 09:27:45 +0100 > User-Agent: KMail/1.4.3 > References: <20041213155606.9656241044(a)draco.ins.cwi.nl> > In-Reply-To: <20041213155606.9656241044(a)draco.ins.cwi.nl> > Cc: "Peter Boncz" <P.Boncz(a)cwi.nl> > MIME-Version: 1.0 > Old-Content-Transfer-Encoding: quoted-printable > Message-Id: <200412150927.47729.flokstra(a)cs.utwente.nl> > X-Spam-Score: -4.9 () BAYES_00 > X-Scanned-By: milter-spamc/0.25.320 (styx.cwi.nl [192.16.191.21]); Wed, 15 Dec 2004 09:28:11 +0100 > X-Scanned-By: MIMEDefang 2.44 > X-Spam-Flag: NO > X-Spam-Status: NO, hits=0.00 required=5.00 > X-Spam-Level: > X-Spam-Report: Content analysis details: (0.0 points, 5.0 required) > Tests (points, rulename, description): > ____ > X-Virus-Scanned: by cwi.nl (CWI/$Revision: 1.25 $) > Content-Transfer-Encoding: 8bit > > Hi Stefan, > > I am using Redhat Linux, version (uname -a) > > Linux psyche 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux > > and the default compilers on this version. I made an strace of the Mserver > and got the following output (just the tail) > It looks it never returns from the rt_sigsuspend() syscall and this is > indeed very strange! > > Regards, Jan. > > > brk(0x8175000) = 0x8175000 > brk(0x8177000) = 0x8177000 > brk(0x8178000) = 0x8178000 > brk(0x8179000) = 0x8179000 > brk(0x817b000) = 0x817b000 > brk(0x817d000) = 0x817d000 > brk(0x817f000) = 0x817f000 > brk(0x8180000) = 0x8180000 > brk(0x8181000) = 0x8181000 > brk(0x8182000) = 0x8182000 > brk(0x8183000) = 0x8183000 > brk(0x8185000) = 0x8185000 > brk(0x8186000) = 0x8186000 > close(7) = 0 > open("/usr/local/flokstra/lib/MonetDB", > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 7 > fstat64(7, {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0 > fcntl64(7, F_SETFD, FD_CLOEXEC) = 0 > lseek(7, 0, SEEK_SET) = 0 > getdents64(0x7, 0x80a1b90, 0x1000, 0x4006c4eb) = 4096 > open("/usr/local/flokstra/lib/MonetDB/trans.mil", O_RDONLY|O_LARGEFILE) = 8 > fstat64(8, {st_mode=S_IFREG|0755, st_size=70, ...}) = 0 > fstat64(8, {st_mode=S_IFREG|0755, st_size=70, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x4045f000 > read(8, "# This module is generated using"..., 4096) = 70 > read(8, "", 4096) = 0 > close(8) = 0 > munmap(0x4045f000, 4096) = 0 > close(7) = 0 > open("/usr/local/flokstra/lib/MonetDB", > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 7 > fstat64(7, {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0 > fcntl64(7, F_SETFD, FD_CLOEXEC) = 0 > lseek(7, 0, SEEK_SET) = 0 > getdents64(0x7, 0x80a1b90, 0x1000, 0x400709c6) = 4096 > getdents64(0x7, 0x80a1b90, 0x1000, 0x400709c6) = 2504 > open("/usr/local/flokstra/lib/MonetDB/lib_trans.so", O_RDONLY) = 8 > read(8, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\314\16"..., 1024) = > 1024 > fstat64(8, {st_mode=S_IFREG|0755, st_size=78034, ...}) = 0 > old_mmap(NULL, 16136, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0x419f7000 > mprotect(0x419fa000, 3848, PROT_NONE) = 0 > old_mmap(0x419fa000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8, > 0x2000) = 0x419fa000 > close(8) = 0 > write(1, "MonetDB>", 8MonetDB>) = 8 > fstat64(0, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x4045f000 > read(0, quit(); > "quit();\n", 1024) = 8 > write(6, "\200\20G@\2\0\0\0\0\0\0\0\222\253\0@\304\363\377\277\300"..., 148) = > 148 > rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 > rt_sigsuspend([] > > > -- | 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 |

17 years, 7 months

[Monetdb-developers] "pseudo" nested BATs

by Stefan.Manegold＠cwi.nl

Hi MonetDB developers and users, sorry for this "blunt" posting, but I thought, the problem, respectively the solution/recommendation that will hopefully be initiated by this question, might be interesting for some more of you: Triggered by a question from Agustin, I noticed that I (believe it or not ;-) apparently lack some knowledge of / experiences with MonetDB/MIL: Consider you have a variable "a" holding a (possible transient) BAT, and another variable "b" holding a second BAT, which happens to be a view of the first one. Both BATs haven't been baptized ("rename()"), yet; hence they still hold there default names: var a := new(void,int).seqbase(0(a)0).insert(nil,1).insert(nil,2).access(BAT_READ); var b := reverse(a); print(a); #-----------------# # h tmp_29 # name # void int # type #-----------------# [ 0@0, 1 ] [ 1@0, 2 ] print(b); #-----------------# # t tmp_29 # name # int void # type #-----------------# [ 1, 0@0 ] [ 2, 1@0 ] Then, these BATs should be gathered in a "container"-BAT. Since (persistent) nested BATs have disappeared (for good reasons!), we do this by gathering the BAT's name in the container: var c := new(void,str).seqbase(10@0); c.insert(nil,bbpname(a)).insert(nil,bbpname(b)); print(c); #-------------------------# # h tmp_28 # name # void str # type #-------------------------# [ 10@0, "tmp_29" ] [ 11@0, "tmp_29" ] Since the second BAT is only a view of the first one, they share not only the same memory/storage, but also the same (bbp-)name; hence, they are not distinguishable by (only) their (bbp-)names, and thus the container c actually contains the first BAT twice iso each BAT once: print(bat(fetch(c,0))); #-----------------# # h tmp_29 # name # void int # type #-----------------# [ 0@0, 1 ] [ 1@0, 2 ] print(bat(fetch(c,1))); #-----------------# # h tmp_29 # name # void int # type #-----------------# [ 0@0, 1 ] [ 1@0, 2 ] print(bbpname(a)); [ "tmp_29" ] print(bbpname(b)); [ "tmp_29" ] Obviously, the problem can be solved/avoided by baptizing the two BATs, and hence making them unique "individuals": rename(a,"BAT_a"); rename(b,"BAT_b"); print(bbpname(a)); [ "BAT_a" ] print(bbpname(b)); [ "BAT_b" ] c.insert(nil,bbpname(a)).insert(nil,bbpname(b)); print(c); #-------------------------# # h tmp_28 # name # void str # type #-------------------------# [ 10@0, "tmp_29" ] [ 11@0, "tmp_29" ] [ 12@0, "BAT_a" ] [ 13@0, "BAT_b" ] print(bat(fetch(c,0))); !ERROR: interpret_params: print(param 1): invalid BAT. print(bat(fetch(c,1))); !ERROR: interpret_params: print(param 1): invalid BAT. print(bat(fetch(c,2))); #-----------------# # h BAT_b # name # void int # type #-----------------# [ 0@0, 1 ] [ 1@0, 2 ] print(bat(fetch(c,3))); #-----------------# # t BAT_b # name # int void # type #-----------------# [ 1, 0@0 ] [ 2, 1@0 ] My question is now: - Is this the only solution, or am I just not aware of another command iso bbpname() that would return unique "default" name for non-renamed view? Of course, given the fact that only MonetDB itself has control over the default "tmp_*" names, it is always recommendable to assign names that you can control yourself, whenever you use a BAT's name as its only reference... 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 |

17 years, 7 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

developers-list December 2004