Bugs item #2606020, was opened at 2009-02-16 16:59 Message generated for change (Comment added) made by mlkersten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2606020&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: SQL/Core Group: SQL "stable" Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan de Konink (skinkie) Assigned to: Niels Nes (nielsnes) Summary: BenchmarkSQL fails loading due to sudden transaction abort Initial Comment: In order to let BenchmarkSQL to work, I had to modify the test from Decimal(4,4) to Float in the create table statements. When running the loadSQL.sh code with the following configuration: monetdb-jdbc.properties: driver=nl.cwi.monetdb.jdbc.MonetDriver conn=jdbc:monetdb://localhost/demo?user=monetdb&password=monetdb&debug=true user=monetdb password=monetdb At a certain moment when executing EXEC with its PREPARE statement, ROLLBACK warnings occur. PREPARE INSERT INTO item (i_id, i_name, i_price, i_data, i_im_id) VALUES (?, ?, ?, ?, ?); TX 1234798982371: sexec 2(22001, 'jvrRZibeQvUYlNcsAZ', 50.689998626708984, 'pYeGnMiVfmWoUBbVjgoPiPueMBVTxnImYXHbBNkyVBmI', 8936); .... RD 1234798982597: read final block: 3950 bytes RX 1234798982597: !current transaction is aborted (please ROLLBACK) I have ran valgrind on the mserver5 process which resulted in: >==16992== Thread 5: ==16992== Syscall param write(buf) points to uninitialised byte(s) ==16992== at 0x6AF37FB: (within /lib64/libpthread-2.9.so) ==16992== by 0x5DA716E: GDKsave (gdk_storage.mx:284) ==16992== by 0x5B55694: HEAPsave (gdk_heap.mx:383) ==16992== by 0x5DA93D9: BATsave (gdk_storage.mx:559) ==16992== by 0x5B52DBD: BBPsync (gdk_bbp.mx:3133) ==16992== by 0x5B3C78F: TMsubcommit (gdk_tm.mx:189) ==16992== by 0x5EC467D: bm_subcommit (gdk_logger.mx:1011) ==16992== by 0x5EC772B: bm_commit (gdk_logger.mx:1735) ==16992== by 0x5EC3A24: logger_commit (gdk_logger.mx:949) ==16992== by 0x5EC5405: logger_exit (gdk_logger.mx:1226) ==16992== by 0x5EC551A: logger_restart (gdk_logger.mx:1253) ==16992== by 0x18C1F193: bl_restart (bat_logger.mx:64) ==16992== Address 0x1c1e4441 is 8,353 bytes inside a block of size 20,504 alloc'd ==16992== at 0x4C2467E: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==16992== by 0x5C1710D: GDKmallocmax (gdk_utils.mx:1062) ==16992== by 0x5C172AA: GDKmalloc (gdk_utils.mx:1085) ==16992== by 0x5DA73EE: GDKload (gdk_storage.mx:330) ==16992== by 0x5B5550B: HEAPload (gdk_heap.mx:341) ==16992== by 0x5DA9AE0: BATload_intern (gdk_storage.mx:643) ==16992== by 0x5B4B849: BBPdescriptor (gdk_bbp.mx:1864) ==16992== by 0x18C1F812: BATdescriptor (gdk.h:1324) ==16992== by 0x18C1F786: temp_descriptor (bat_utils.mx:123) ==16992== by 0x18C1EC76: tr_snapshot_bat (bat_storage.mx:1405) ==16992== by 0x18C1EDB8: snapshot_table (bat_storage.mx:1434) ==16992== by 0x18C11EE5: rollforward_update_table (store.mx:2289) ---------------------------------------------------------------------- >Comment By: Martin Kersten (mlkersten) Date: 2009-02-16 19:34 Message: Valgrind only reports about accessing non-initialized information here. And this access to non-initialized buffer space is known and safe. To detect and claim memory leaks in GDK you have to run valgrind --leak-check=full --show-reachable=yes --num-callers=20 mserver5 --dbfarm=$DBFARM --dbname=$DBNAME ---------------------------------------------------------------------- Comment By: Fabian (mr-meltdown) Date: 2009-02-16 19:31 Message: I think someone else will still be in the neighbourhood of clueless with your given instructions on how to reproduce your problem. ---------------------------------------------------------------------- Comment By: Stefan de Konink (skinkie) Date: 2009-02-16 19:28 Message: Who) Me What) BenchmarkSQL on Java 1.5 fails When) When running loadSQL code Where) AMD64 Why) Because there is a memory problem in GDK How) Running the loadSQL.sh program I think all these questions were answered in the report. Because your summery does not describe the section where the issue is present. Thus your summary related to the actual knowledge that was gathered is incomplete. ---------------------------------------------------------------------- Comment By: Fabian (mr-meltdown) Date: 2009-02-16 17:55 Message: Please post enough information such that others can reproduce your problem. What makes you think this is a GDK issue? Why not just "When batch executing prepared statements, the server reports current transaction is aborted after a random amount of statements with no previous error message"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2606020&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
