search

openlink / virtuoso-opensource

Virtuoso is a high-performance and scalable Multi-Model RDBMS, Data Integration Middleware, Linked Data Deployment, and HTTP Application Server Platform
https://vos.openlinksw.com
Other
866 stars 210 forks source link

Jena crashes Virtuoso server: SR491: Too many open statements #213

Closed kgardas closed 2 years ago

kgardas commented 10 years ago

Hello, got Version 7.1.1-dev.3211-pthreads as of Jul 4 2014 here, which is exactly cb01f54019795bca13119ab58a768d131883d480 When I compile with on Debian 7.5 and use it with Jena/Virtuoso provider, my Java code after some time throws following exception:

com.hp.hpl.jena.shared.JenaException: virtuoso.jdbc4.VirtuosoException: SR491: Too many open statements
        at virtuoso.jena.driver.VirtGraph.graphBaseFind(VirtGraph.java:716)
        at virtuoso.jena.driver.VirtGraph.graphBaseFind(VirtGraph.java:675)
        at com.hp.hpl.jena.graph.impl.GraphBase.find(GraphBase.java:268)
        at com.hp.hpl.jena.graph.impl.GraphBase.graphBaseFind(GraphBase.java:290)
        at com.hp.hpl.jena.graph.impl.GraphBase.find(GraphBase.java:287)
        at com.hp.hpl.jena.rdf.model.impl.ModelCom.listStatements(ModelCom.java:477)
        at com.hp.hpl.jena.rdf.model.impl.ModelCom.listStatements(ModelCom.java:483)
        at com.hp.hpl.jena.rdf.model.impl.ModelCom.getProperty(ModelCom.java:1249)
        at com.hp.hpl.jena.rdf.model.impl.ResourceImpl.getProperty(ResourceImpl.java:174)

and the server crashes with following backtrace:

(gdb) where
#0  0x0000000000627782 in ?? ()
#1  0x0000000000627a69 in sf_sql_free_stmt_w ()
#2  0x0000000000925c30 in ?? ()
#3  0x000000000092994f in ?? ()
#4  0x00007f4e324c6b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#5  0x00007f4e31d8b0ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#6  0x0000000000000000 in ?? ()

That's on Debian 7.5. On Solaris 11.1 I'm able to get the same crash too which looks then:

(dbx) where
current thread: t@8
=>[1] _lwp_kill(0x8, 0xb, 0xffffc100337753e0, 0x0, 0x36, 0x6c616e67), at 0xffff80ffbf4daaaa 
  [2] thr_kill(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffff80ffbf4cf2a1 
  [3] raise(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffff80ffbf47feb9 
  [4] __sighndlr(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffff80ffbf4d18b6 
  [5] call_user_handler(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffff80ffbf4c503a 
  [6] sigacthandler(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffff80ffbf4c525b 
  ---- called from signal handler with signal 11 (SIGSEGV) ------
  [7] sf_sql_free_stmt(0x13233bba, 0x7ffffffc1d30, 0x31, 0x2710, 0x0, 0x0, 0x0, 0x15924b0, 0x1319ff90, 0x11fc1720, 0x7ffffffc1f90, 0xbd1814, 0x0, 0x0, 0x0, 0x100000014442da0, 0x7ffffffc1e40, 0x11fc1720, 0x124acb8, 0x12effc8), at 0x7a9fa5 
  [8] sf_sql_free_stmt_w(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x7aa23a 
  [9] future_wrapper(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xbd1814 
  [10] _thread_boot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xbd8848 
  [11] _thrp_setup(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffff80ffbf4d1545 
  [12] _lwp_start(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffff80ffbf4d17f0

Please note that actual crash on Solaris is on stack frame 7 due to signal handling of SIGSEGV. So in both cases sf_sql_free_stmt looks buggy. Seeing this I would call it a bug which may be used for a nice DoS attack.

My Jena provider is:

$ java -jar ../webapps/xwiki/WEB-INF/lib/virt_jena2.jar 
OpenLink Virtuoso(TM) Provider for Jena(TM) Version 2.10.1 [Build 1.10]

and as a JDBC driver I've tested those two:

$ java -jar ../webapps/xwiki/WEB-INF/lib/virtjdbc4.jar 
OpenLink Virtuoso(TM) Driver for JDBC(TM) Version 4.x [Build 3.66]
$ java -jar ../webapps/xwiki/WEB-INF/lib/virtuoso-backup/virtjdbc4_1.jar 
OpenLink Virtuoso(TM) Driver for JDBC(TM) Version 4.1 [Build 3.70]

All java jars used here are downloaded from openlinksw.com site or obtained from virtuoso-opensource tree where they are precompiled. I don't compile this piece of code here.

Otherwise I'm running JDK 1.7 here together with Jena 2.11.1

Googling for the same issue I've found following thread http://boards.openlinksw.com/phpBB3/viewtopic.php?f=12&t=2244 where symptoms looks very similar to mines. i.e. ~10k statements etc. Thanks! Karel

openlink commented 10 years ago

On 4 July 2014 16:42, kgardas notifications@github.com wrote:

Please note that actual crash on Solaris is on stack frame 7 due to signal handling of SIGSEGV. So in both cases sf_sql_free_stmt looks buggy. Seeing this I would call it a bug which may be used for a nice DoS attack.

My Jena provider is:

$ java -jar ../webapps/xwiki/WEB-INF/lib/virt_jena2.jar OpenLink Virtuoso(TM) Provider for Jena(TM) Version 2.10.1 [Build 1.10]

and as a JDBC driver I've tested those two:

$ java -jar ../webapps/xwiki/WEB-INF/lib/virtjdbc4.jar OpenLink Virtuoso(TM) Driver for JDBC(TM) Version 4.x [Build 3.66] $ java -jar ../webapps/xwiki/WEB-INF/lib/virtuoso-backup/virtjdbc4_1.jar OpenLink Virtuoso(TM) Driver for JDBC(TM) Version 4.1 [Build 3.70]

Otherwise I'm running JDK 1.7 here together with Jena 2.11.1

Googling for the same issue I've found following thread http://boards.openlinksw.com/phpBB3/viewtopic.php?f=12&t=2244 where symptoms looks very similar to mines. i.e. ~10k statements etc.

Hi Karel,

Please could you send a sample of your application code that's causing this?

It's pretty obvious where the error's coming from within Virtuoso, but I need to check if the client is exhibiting aberrant behaviour to provoke it.

Thanks,

~Tim

Tim Haynes Product Development Consultant OpenLink Software http://www.openlinksw.com/ http://twitter.com/openlink

kgardas commented 10 years ago

Hi Tim, of course, but is source code enough or do you need some simplified example to run? If code, then please have a look at https://github.com/kgardas/semxwiki/blob/master/semanticXWiki/src/main/java/com/objectsecurity/jena/Context.java -- this is a semantic XWiki extension. As you can see in the code this is basically a wrapper around Jena to support XWiki macros which are in xwiki package. The issue is caused by my semantic xwiki benchmark tool which basically speaking upload N pages with M properties (this results in N*M triplets to be loaded into tripletstore). Seeing numbers I think it's really about 10k limit for some statements as described in the cited forum link. If you'd like to form a duplicating issue example, then basically you need to make an example which will obtain Context and then invoke setProperty for certain resource on it and also query for props on this resource (getPropertyTableForResource). By several thousands of those methods invocation you shall get to the issue. Of course, you will need to have Virtuoso running and also JENA_BACKEND env. var set to `virtuoso' Let me know if I may help you anyhow with this, I would love to see this beast running with Virtuoso! Thanks! Karel

kgardas commented 10 years ago

Hi Tim, is there anything how can I help you with issue duplication and fix? I'm asking since I've tried to use Virtuoso using its SPARQL/HTTP interface, but this fails too. Already reported here: #215 Perhaps this fix to Jena adapter is not that complex? Thanks! Karel

smalinin commented 10 years ago

Issue with "Jena crashes Virtuoso server: SR491: Too many open statements" was fixed in last versions of Jena provider and Virtuoso JDBC driver.

openlink commented 10 years ago

Please try to use the latest jena2 and Virtuoso JDBC drivers from the develop/7 branch which contain a number of fixes that should resolve the statements leak issue.

HughWilliams commented 9 years ago

Hi Can you confirm if this problem is still an issue for you particularly with the latest Virtuoso 7.2 release ?

kgardas commented 9 years ago

Hi, sorry for delay, will test early next week. Thanks for your patience. Karel

ssklavos-ed commented 2 years ago

Hello. was this issue finally resolved? Could you please provide your latest findings if any?

kgardas commented 2 years ago

Hi, sorry, the related project is already over and I do not have any reason not to believe @smalinin claim the issue is fixed.