Bugs item #1914463, was opened at 2008-03-14 19:04 Message generated for change (Comment added) made by rustamabd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1914463&group_id=56967
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: (zombie: MonetDB4 4.22) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard Eckart (wyldfire) Assigned to: Nobody/Anonymous (nobody) Summary: Client hangs unless somebody presses enter at server prompt Initial Comment: ====== System ====== OS: OS X Tiger 10.4.11 gcc: powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250) MonetDB was compiled from the Feb 2008 Superball. ====== Problem ====== I start up MServer: $ ./Mserver --dbinit="module(pathfinder);" # MonetDB Server v4.22.0 # based on GDK v1.22.0 # Copyright (c) 1993-2008, CWI. All rights reserved. # Compiled for powerpc-apple-darwin8.11.0/32bit with 32bit OIDs; dynamically linked. # Visit http://monetdb.cwi.nl/ for further information. # PF/Tijah module v0.5.0 loaded. http://dbappl.cs.utwente.nl/pftijah # MonetDB/XQuery module v0.22.0 loaded # XRPC administrative console at http://127.0.0.1:50001/admin MonetDB> On another terminal I run a simple test: $ cat > test.xq (1, 42.0, "Hello World", <node attr="value">test</node>) $ ./mclient -lx test.xq _ (blink blink blink ...) and there it hangs. So I go back to the server to see what's up. I tried the "threads()" and "clients()" commands. Well, to me all looks fine except that the "monetdb" client does not seem to have actually sent any command (""). Funnily when I got back to the first terminal, the mclient command had completed. So I tried again. It seems that the mclient command will complete as soon as I hit "return" a couple of times on the MonetDB> prompt. The same goes for the mjclient command. ---------------------------------------------------------------------- Comment By: Rustam Abdullaev (rustamabd) Date: 2008-11-02 17:00 Message: With MonetDB 4.25.0 build from CVS on 2008-11-02 the problem seems to be fixed. $ Mserver --dbinit="module(pathfinder);" # MonetDB Server v4.25.0 # based on GDK v1.25.0 # Copyright (c) 1993-July 2008, CWI. All rights reserved. # Copyright (c) August 2008-, MonetDB B.V.. All rights reserved. # Compiled for i386-unknown-freebsd7.0/32bit with 32bit OIDs; dynamically linked. # Visit http://monetdb.cwi.nl/ for further information. # PF/Tijah module v0.9.0 loaded. http://dbappl.cs.utwente.nl/pftijah # MonetDB/XQuery module v0.25.0 loaded (default back-end is 'algebra') # XRPC administrative console at http://127.0.0.1:50001/admin MonetDB> $ cat > test.xq (1, 42.0, "Hello World", <node attr="value">test</node>) $ mclient -lx test.xq 1, 42.000000, "Hello World", <node attr="value">test</node> $ ---------------------------------------------------------------------- Comment By: Jan Rittinger (tsheyar) Date: 2008-10-31 14:00 Message: I attached a trace with a simplified example. Perhaps it helps to solve the bug. File Added: Mserver-OSX-analysis ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2008-10-02 23:58 Message: (Mainly for the MonetDB developers:) The problems seems to occur only with "Mserver", i.e., MonetDB/4 (with all back-end: MIL, SQL, XQuery), but not with "mserver5", i.e., MonetDB/5 (both MAL & SQL seems to work fine) ... ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2008-10-02 23:50 Message: This appear to be a MacOS X (Darwin) and (free)BSD inherent problem. It seems that a read for input in one thread (here: Mserver's console prompt) block the whole program/process, as opposed to only blocking htis very thread; hence, also the thread that listens for client connections is unexpectedly (incorrectly?) blocked. While it seems to be beyond our control to fix this problem, a work-around is to start Mserver in daemon mode, to omit the Mserver (MIL-) console: Mserver --dbinit='module(pathfinder);' --set monet_daemon=yes ---------------------------------------------------------------------- Comment By: Richard Eckart (wyldfire) Date: 2008-05-06 21:17 Message: Logged In: YES user_id=398457 Originator: YES I started the server: $ ./Mserver --dbinit="module(pathfinder);" Started the client to run the query: $ ./MonetDB/bin/mclient -lx test.xq Client hangs. Firing up GDB and showing the stack traces. (gdb) thread apply all bt Thread 6 (process 20279 thread 0x2403): #0 0x9002c3c8 in semaphore_wait_signal_trap () #1 0x90001c10 in pthread_mutex_lock () #2 0x9002dc04 in flockfile () #3 0x90002094 in fileno () #4 0x00473300 in yy_init_buffer (b=0x1100550, file=0xa0001b9c) at monet_parse.yy.c:1927 #5 0x00473ab0 in yyrestart (input_file=0xa0001b9c) at monet_parse.yy.c:1804 #6 0x00473ce4 in yy_get_next_buffer () at monet_parse.yy.c:1599 #7 0x00477174 in yylex () at monet_parse.yy.c:1430 #8 0x004715f0 in yyparse () at monet_parse.tab.c:1638 #9 0x00447678 in parseClient (c=0x48601c, reschedule=5379) at monet_client.c:583 #10 0x094065b0 in xquery_mil2tree (ctx=0x1403, buf=0x1503 "") at pathfinder.c:281 #11 0x09406630 in xquery_mil_exec (ctx=0xa7b95c8, buf=0x10cd000 "time_shred := 0LL;\ntime_start := usec();\nvar err;\n{\n {\n var ws ;\n err := CATCH({\n ws := ws_create(0); # get full picture on var_usage (and sort it)\n var usage ;\n {\n int_values.append(1LL);\n"...) at pathfinder.c:302 #12 0x09407db4 in xquery_compile_exec (ctx=0xa7b95c8, url=0x0, is_url=0, prologue=0xf1403e4c, query=0xf1403e50, epilogue=0xf1403e54, nsurl=0x1 <Address 0x1 out of bounds>) at pathfinder.c:443 #13 0x0940a270 in xquery_prepare (ctx=0xa7b95c8, usec=0, query=0x10c4009 "(1, 42.0, \"Hello World\", <node attr=\"value\">test</node>)\n") at pathfinder.c:2028 #14 0x0940a648 in xquery_client_engine (mc=0x100e7ac) at pathfinder.c:2167 #15 0x0100a568 in mapi_client_engine (FC=0x1403) at mapi.c:316 #16 0x9002bd08 in _pthread_body () Thread 5 (process 20279 thread 0x2303): #0 0x900411f8 in mach_wait_until () #1 0x90040fc4 in nanosleep () #2 0x0251d504 in MT_sleep_ms (ms=0) at gdk_posix.c:1770 #3 0x007b924c in CMDsleep (secs=0x0) at alarm.c:145 #4 0x007b88f0 in CMDsleep_unpack522853172 (argc=0, argv=0xf1002d08) at alarm.glue.c:43 #5 0x00432524 in interpret (stk=545, lt=0xb80e8a8, res=0xf1003da8) at monet_interpreter.c:1070 #6 0x00440e18 in interpret_seqblock (stk=545, lt=0xb80dbc8, res=0xf1003da8, scope=175838360) at monet_interpreter.c:2194 #7 0x00430f18 in interpret (stk=548, lt=0xb80dbc8, res=0xf1003da8) at monet_interpreter.c:652 #8 0x00441b04 in interpret_while (stk=548, lt=0xb80db50, res=0xf1003da8) at monet_interpreter.c:1187 #9 0x00431120 in interpret (stk=548, lt=0xb80db50, res=0xf1003da8) at monet_interpreter.c:719 #10 0x00440e18 in interpret_seqblock (stk=548, lt=0xb80d988, res=0xf1003da8, scope=175838360) at monet_interpreter.c:2194 #11 0x00430f18 in interpret (stk=4, lt=0xb80d988, res=0xf1003da8) at monet_interpreter.c:652 #12 0x004321bc in interpret (stk=4, lt=0xb80d7a8, res=0xf1003da8) at monet_interpreter.c:1044 #13 0x004433c8 in handleRequest (t=0x27389cc, q=0xb80d8d8, res=0xf1003da8) at monet_queue.c:342 #14 0x00443bfc in doRequest (t=0x27389cc, preference=0x0) at monet_queue.c:368 #15 0x00478070 in monetInterpreter (status=0x25c3090) at monet_process.c:45 #16 0x9002bd08 in _pthread_body () Thread 4 (process 20279 thread 0x2203): #0 0x9001f88c in select () #1 0x09d640e4 in shttpd_poll (ctx=0xf0c028b8, milliseconds=200) at shttpd.c:2962 #2 0x09d65594 in CMDrpcd_start (port=0x0, open=0xf0c02ab8 "\001", option=0x68 <Address 0x68 out of bounds>) at xrpc_server.c:1183 #3 0x09d64978 in CMDrpcd_start_unpack1996251672 (argc=0, argv=0xf0c02a98) at xrpc_server.glue.c:43 #4 0x00432524 in interpret (stk=3, lt=0xb80bde8, res=0xf0c02da8) at monet_interpreter.c:1070 #5 0x004433c8 in handleRequest (t=0x2738978, q=0xb80c008, res=0xf0c02da8) at monet_queue.c:342 #6 0x00443bfc in doRequest (t=0x2738978, preference=0x0) at monet_queue.c:368 #7 0x00478070 in monetInterpreter (status=0x25c3090) at monet_process.c:45 #8 0x9002bd08 in _pthread_body () Thread 3 (process 20279 thread 0x1003): #0 0x9001f88c in select () #1 0x0100b0e4 in MAPIlisten (stk=2, lt=0x3044401, res=0xffffffff) at mapi.c:729 #2 0x00431594 in interpret (stk=2, lt=0xabc2b78, res=0xf0801da8) at monet_interpreter.c:806 #3 0x004433c8 in handleRequest (t=0x2738924, q=0xabc2d98, res=0xf0801da8) at monet_queue.c:342 #4 0x00443bfc in doRequest (t=0x2738924, preference=0x0) at monet_queue.c:368 #5 0x00478070 in monetInterpreter (status=0x25c3090) at monet_process.c:45 #6 0x9002bd08 in _pthread_body () Thread 2 (process 20279 thread 0xf03): #0 0x900411f8 in mach_wait_until () #1 0x90040fc4 in nanosleep () #2 0x0251d504 in MT_sleep_ms (ms=0) at gdk_posix.c:1770 #3 0x023da720 in GDKvmtrim (limit=0x25c30bc) at gdk_utils.c:1350 #4 0x9002bd08 in _pthread_body () Thread 1 (process 20279 thread 0xd03): #0 0x900148a4 in read () #1 0x9001b0e8 in _sread () #2 0x9001b05c in __srefill () #3 0x9001ae44 in fread () #4 0x0051333c in file_read (s=0x11079b0, buf=0x303ee08, elmsize=1, cnt=1) at stream.c:447 #5 0x004470f0 in readClient (c=0x485fa8) at monet_client.c:428 #6 0x004477cc in serveClient (stk=0, lt=0x1778000, res=0x485fa8) at monet_client.c:622 #7 0x00431594 in interpret (stk=0, lt=0x1167a48, res=0xbffff3a8) at monet_interpreter.c:806 #8 0x004433c8 in handleRequest (t=0x27388d0, q=0xb808268, res=0xbffff3a8) at monet_queue.c:342 #9 0x00443bfc in doRequest (t=0x27388d0, preference=0x0) at monet_queue.c:368 #10 0x00478070 in monetInterpreter (status=0x25c3090) at monet_process.c:45 #11 0x00002f38 in main (argc=2, av=0xbffff570) at Mserver.c:234 (gdb) ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2008-04-22 14:48 Message: Logged In: YES user_id=43607 Originator: NO We do this kind of thing all the time without any problems. The difference seems to be that we use different O/S's and distributions. I'm inclined to call this an O/S bug (or bug in the thread implementation). I guess what would help is to attach a debugger while the Mserver is hanging and to look at what all the threads are doing. Then we know for sure. So can you do gdb -p <Mserver-pid> and then at the gd prompt thread apply all bt ---------------------------------------------------------------------- Comment By: Wouter Alink (vzzzbx) Date: 2008-03-16 11:48 Message: Logged In: YES user_id=621590 Originator: NO (i posted this first at the users-mailinglist, but i guess it belongs here) I witnessed a similar problem yesterday on freebsd (with the Feb2008 release). It was not my computer, and I do not really have more details. somehow (when running Mserver in a shell) setting "deamon=yes" in the MonetDB.conf seemed to help. it doesn't solve the actual problem, but perhaps it might help finding it...? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1914463&group_id=56967 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Monetdb-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
