Thread: [Sablevm-developer] SableVM hangs during database connection
Brought to you by:
egagnon
From: Roman K. <ro...@on...> - 2004-06-15 18:18:48
|
Hi list, I found another issue, this time related to a database connection with MySQL. During sending an update, the hole connection seems to hang infinitely. I waited >10minutes, which should me more than enough. As far as I worked this out, the issue seems to be in some native code. Here is the stacktrace from CTRL+\: (PlainSocketImpl.java:-1) gnu/java/net/PlainSocketImpl.read n (PlainSocketImpl.java:431) gnu/java/net/PlainSocketImpl$SocketInputStream.read (FilterInputStream.java:189) java/io/FilterInputStream.read (BufferedInputStream.java:370) java/io/BufferedInputStream.refill (BufferedInputStream.java:231) java/io/BufferedInputStream.read (MysqlIO.java:1399) com/mysql/jdbc/MysqlIO.reuseAndReadPacket (MysqlIO.java:1775) com/mysql/jdbc/MysqlIO.checkErrorPacket (MysqlIO.java:1020) com/mysql/jdbc/MysqlIO.sendCommand (MysqlIO.java:1109) com/mysql/jdbc/MysqlIO.sqlQueryDirect (Connection.java:2030) com/mysql/jdbc/Connection.execSQL (PreparedStatement.java:1750) com/mysql/jdbc/PreparedStatement.executeUpdate (PreparedStatement.java:1596) com/mysql/jdbc/PreparedStatement.executeUpdate (JDBCStorage.java:138) com/knowledgetracking/JDBCStorage.storeXML (NBEngine.java:78) com/knowledgetracking/nb/NBEngine.learn (NBEngine.java:37) com/knowledgetracking/nb/NBEngine.learn (learn.java:29) com/knowledgetracking/cli/learn.invoke (learn.java:45) com/knowledgetracking/cli/learn.invoke (Method.java:-1) java/lang/reflect/Method.invokeNative n (Method.java:556) java/lang/reflect/Method.invoke ((null):-1) bsh/Reflect.invokeOnMethod ((null):-1) bsh/Reflect.invokeStaticMethod ((null):-1) bsh/Reflect.invokeCompiledCommand ((null):-1) bsh/Name.invokeLocalMethod ((null):-1) bsh/Name.invokeMethod ((null):-1) bsh/BSHMethodInvocation.eval ((null):-1) bsh/BSHPrimaryExpression.eval ((null):-1) bsh/BSHPrimaryExpression.eval ((null):-1) bsh/Interpreter.eval ((null):-1) bsh/Interpreter.source ((null):-1) bsh/Interpreter.main (VirtualMachine.java:-1) java/lang/VirtualMachine.invokeMain n (VirtualMachine.java:92) java/lang/VirtualMachine.main I'm trying to put together a simple test case to make this reproducible. Is there any more information I can send (like a stacktrace of the native code-> I don't know how to get this)? Cheers, Roman |
From: Grzegorz B. P. <ga...@de...> - 2004-06-16 00:35:40
|
W liście z wto, 15-06-2004, godz. 14:18, Roman Kennke pisze: > Hi list, > > I found another issue, this time related to a database connection with > MySQL. During sending an update, the hole connection seems to hang > infinitely. I waited >10minutes, which should me more than enough. As > far as I worked this out, the issue seems to be in some native code. > Here is the stacktrace from CTRL+\: [...] > I'm trying to put together a simple test case to make this reproducible. > Is there any more information I can send (like a stacktrace of the > native code-> I don't know how to get this)? You need to get PID of the sablevm process, then you do: $ gdb /path/to/bin/sablevm $PID at gdb command prompt you simply do 'bt' If your app is multithreaded, you might want to attach to each thread and get backtrace it. HTH Grzegorz B. Prokopski -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPL'ed Java VM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/Features |
From: Roman K. <ro...@on...> - 2004-06-16 22:21:02
|
Am Di, den 15.06.2004 schrieb Roman Kennke um 20:18: > Hi list, >=20 > I found another issue, this time related to a database connection with > MySQL. During sending an update, the hole connection seems to hang > infinitely. Update: I've done a lot of tests, during which I got it running on Linux. I used a new MySQL driver for this. Unfortunately my testprog does still not run under FreeBSD. I will attach my testprog. The result under FreeBSD is, that I can transmit a byte array of size <21488 bytes, not 1 byte more (in this case the whole thing hangs). The gdb backtrace is surprisingly short: (gdb) bt #0 0x2817f2af in poll () from /lib/libc.so.5 #1 0x28123a51 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5 #2 0x28123445 in _thread_kern_scheduler () from /usr/lib/libc_r.so.5 (gdb) I have not yet solved this, and have no idea. But I have solved another small problem, which I will write in another email. :-) Cheers, Roman |
From: Chris P. <chr...@ma...> - 2004-06-17 16:51:18
|
Roman Kennke wrote: > Am Di, den 15.06.2004 schrieb Roman Kennke um 20:18: > >>Hi list, >> >>I found another issue, this time related to a database connection with >>MySQL. During sending an update, the hole connection seems to hang >>infinitely. > > > Update: I've done a lot of tests, during which I got it running on > Linux. I used a new MySQL driver for this. Unfortunately my testprog > does still not run under FreeBSD. I will attach my testprog. Hi Roman, I think you forgot to attach the test case. Does anyone in our group have an account on a FreeBSD machine? Cheers, Chris The result > under FreeBSD is, that I can transmit a byte array of size <21488 bytes, > not 1 byte more (in this case the whole thing hangs). The gdb backtrace > is surprisingly short: > (gdb) bt > #0 0x2817f2af in poll () from /lib/libc.so.5 > #1 0x28123a51 in _thread_kern_sched_state_unlock () from > /usr/lib/libc_r.so.5 > #2 0x28123445 in _thread_kern_scheduler () from /usr/lib/libc_r.so.5 > (gdb) > > I have not yet solved this, and have no idea. > > But I have solved another small problem, which I will write in another > email. :-) > > Cheers, Roman > |
From: Roman K. <ro...@on...> - 2004-06-17 19:12:24
Attachments:
TestMySQL.java
|
Hi, > >>I found another issue, this time related to a database connection with > >>MySQL. During sending an update, the hole connection seems to hang > >>infinitely. > > > > > > Update: I've done a lot of tests, during which I got it running on > > Linux. I used a new MySQL driver for this. Unfortunately my testprog > > does still not run under FreeBSD. I will attach my testprog. > > Hi Roman, > > I think you forgot to attach the test case. Oh, sorry. As always, I forgot the attachment ;-) In order to run the test, you need a MySQL database set up this way: CREATE DATABASE test; GRANT ALL PRIVILEGES ON test.* TO test IDENTIFIED BY 'test'; GRANT ALL PRIVILEGES ON test.* TO test@localhost IDENTIFIED BY 'test'; USE test; CREATE TABLE ( test LONGBLOB ); and of course you need the MySQL JDBC driver (I used version 3.0.14). I hope, someone is willing and able to run this. Cheers, Roman |
From: Chris P. <chr...@ma...> - 2004-06-17 22:54:06
|
Roman Kennke wrote: > Hi, > > >>>>I found another issue, this time related to a database connection with >>>>MySQL. During sending an update, the hole connection seems to hang >>>>infinitely. >>> >>> >>>Update: I've done a lot of tests, during which I got it running on >>>Linux. I used a new MySQL driver for this. Unfortunately my testprog >>>does still not run under FreeBSD. I will attach my testprog. >> >>Hi Roman, >> >>I think you forgot to attach the test case. > > > Oh, sorry. As always, I forgot the attachment ;-) > > In order to run the test, you need a MySQL database set up this way: > > CREATE DATABASE test; > GRANT ALL PRIVILEGES ON test.* TO test IDENTIFIED BY 'test'; > GRANT ALL PRIVILEGES ON test.* TO test@localhost IDENTIFIED BY 'test'; > USE test; > CREATE TABLE ( > test LONGBLOB > ); > > and of course you need the MySQL JDBC driver (I used version 3.0.14). > > I hope, someone is willing and able to run this. Eventually someone will get to it. I don't know if we have a FreeBSD machine. If you were able to provide shell access to somebody it might be faster. Anyway, can you try ./configure --enable-debugging-features --with-threading=switch ? I have no idea either, but it's apparently another threading bug. If you have linuxthreads available for FreeBSD and it's not a pain to use them, that would be worth trying out. Cheers, Chris |
From: Roman K. <ro...@on...> - 2004-06-17 23:26:50
Attachments:
TestClient.java
TestServer.java
|
Hi, > >>>>I found another issue, this time related to a database connection with > >>>>MySQL. During sending an update, the hole connection seems to hang > >>>>infinitely. > >>> > >>> > >>>Update: I've done a lot of tests, during which I got it running on > >>>Linux. I used a new MySQL driver for this. Unfortunately my testprog > >>>does still not run under FreeBSD. I will attach my testprog. > >> > I have no idea either, but it's apparently another threading bug. If > you have linuxthreads available for FreeBSD and it's not a pain to use > them, that would be worth trying out. Grzegorz Prokopski has helped me to narrow the bug. It seems to be an issue in Classpaths network handling. I'll send a new test-case: a simple server and a simple client. When trying to send big arrays >22k, the network layer hangs. At least in FreeBSD. Running sablevm through strace gives the following: (last few lines only) write(2, "sending 220000 bytes...\n", 24) = 24 break(0x9408000) = 0 sendto(6, "\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"..., 220000, 0, NULL, 0) = 220000 break(0x93d2000) = 0 write(2, "receiving status bytes...\n", 26) = 26 recvfrom(6, 0x91b2070, 1, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=6, events=POLLRDNORM}], 1, 0) = 0 poll( Grzegorz Prokopski assumed, that Classpath does not handle EAGAIN correcly, and doesn't try to recvfrom again, as it should. I hope this is helpful. /Roman |