Bugs item #1914463, was opened at 2008-03-14 19:04 Message generated for change (Settings changed) made by stmane 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: MonetDB4 CVS Head Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Richard Eckart (wyldfire) Assigned to: Sjoerd Mullender (sjoerd) 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: Stefan Manegold (stmane) Date: 2009-02-16 13:42 Message: standard mclient tests on Darwin used to fail before this was fixed; hence, it is tested --- at least when ever we happen to have access to Darwin machines during testing ... ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2008-12-08 16:35 Message: Closing. We don't have a way to test this automatically. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2008-11-03 22:34 Message: For some reason flex wants to know whether it is running interactively. It does that by checking whether `yyin' points to a tty (isatty(fileno(yyin))). We don't use `yyin', but flex doesn't care. It initializes yyin to stdin and does the above mentioned check. On Linux and Windows this seems to work fine, however, on Darwin this check hangs because while one thread is trying to call fileno(yyin) (i.e. fileno(stdin)) another thread is actually reading from stdin (or rather, hanging in a read system call). This read is protected with a semaphore and fileno has to wait for this semaphore. Hence the fileno will only succeed once the read in the other thread returns. All of this can be solved by circumventing the use of fileno (and isatty). We don't need it, so get rid of it! This should fix this bug. The patch was only applied to the development (HEAD) branch. Thanks to JanR for running the debugger and testing the solution. ---------------------------------------------------------------------- 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 ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Monetdb-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
