Bugs item #2850513, was opened at 2009-09-04 01:17 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2850513&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: MonetDB Common CVS Head Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan de Konink (skinkie) Assigned to: Niels Nes (nielsnes) Summary: BUNlast: Assertion `b->U->count <= (((BUN) 2147483647) - 1)' Initial Comment: The following query: insert into namefinder select lower(name), lat, long, v from (select min(way_nds.way) as way, name, bit_and(zcurve, 0xfffffffee0000000) as smooth from (select ways.id as way, v as name from ways, way_tags where ways.id = way_tags.way and way_tags.k = 'name') as x, way_nds, nodes_legacy where x.way = way_nds.way and to_node = id group by name, smooth) as z, way_nds, nodes_legacy LEFT JOIN way_tags ON way = way_tags.way where z.way = way_nds.way and way_tags.k = 'is_in' and to_node = nodes_legacy.id and idx = 1; results in: mserver5: gdk.h:778: BUNlast: Assertion `b->U->count <= (((BUN) 2147483647) - 1)' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe13d7950 (LWP 28546)] 0x0000003c19c32f05 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.5-3.fc10.x86_64 cyrus-sasl-lib-2.1.22-19.fc10.x86_64 e2fsprogs-libs-1.41.4-6.fc10.x86_64 glibc-2.9-3.x86_64 keyutils-libs-1.2-3.fc9.x86_64 krb5-libs-1.6.3-18.fc10.x86_64 libcurl-7.19.6-1.fc10.x86_64 libidn-0.6.14-8.x86_64 libselinux-2.0.78-1.fc10.x86_64 libssh2-0.18-7.fc9.x86_64 libxml2-2.7.3-2.fc10.x86_64 libxslt-1.1.24-2.fc10.x86_64 ncurses-libs-5.6-20.20080927.fc10.x86_64 nspr-4.7.4-1.fc10.x86_64 nss-3.12.3.99.3-2.10.4.fc10.x86_64 openldap-2.4.12-1.fc10.x86_64 openssl-0.9.8g-14.fc10.x86_64 pcre-7.8-1.fc10.x86_64 raptor-1.4.18-1.fc10.x86_64 readline-5.2-13.fc9.x86_64 zlib-1.2.3-18.fc9.x86_64 (gdb) bt #0 0x0000003c19c32f05 in raise () from /lib64/libc.so.6 #1 0x0000003c19c34a73 in abort () from /lib64/libc.so.6 #2 0x0000003c19c2bef9 in __assert_fail () from /lib64/libc.so.6 #3 0x00007ffff76bd334 in BUNlast (b=0x13a2188) at gdk.h:778 #4 0x00007ffff76b11c7 in mergejoin (l=0x139ef58, r=0x7fffd4000ae0, bn=0x13a2188, nil_on_miss=0x0, estimate=2147483647, limit=0x0) at ../../../src/gdk/gdk_relop.mx:232 #5 0x00007ffff76abbc6 in mergejoin (l=0x139ef58, r=0x7fffd4000ae0, bn=0x0, nil_on_miss=0x0, estimate=2147483647, limit=0x0) at ../../../src/gdk/gdk_relop.mx:94 #6 0x00007ffff76bd798 in batmergejoin (l=0x7fffd4000ab8, r=0x13a64f0, estimate=2147483647, swap=1 '\001', limit=0x0) at ../../../src/gdk/gdk_relop.mx:394 #7 0x00007ffff76f9c5a in batjoin (l=0x7fffd4000ab8, r=0x13a64f0, estimate=2147483647, swap=1 '\001') at ../../../src/gdk/gdk_relop.mx:1205 #8 0x00007ffff76f9d64 in BATjoin (l=0x7fffd4000ab8, r=0x13a64f0, estimate=2147483647) at ../../../src/gdk/gdk_relop.mx:1225 #9 0x00007fffebc1c2c1 in CMDjoin (result=0x7fffe13d4a68, left=0x7fffd4000ab8, right=0x13a64f0, estimate=0x7fffe13d4ab8) at ../../../../src/modules/kernel/algebra.mx:1552 #10 0x00007fffebc28014 in ALGjoinestimate (result=0x13cb638, lid=0x13cb628, rid=0x13cb618, estimate=0x7fffe13d4ab8) at ../../../../src/modules/kernel/algebra.mx:2999 #11 0x00007fffebc2813e in ALGjoin (result=0x13cb638, lid=0x13cb628, rid=0x13cb618) at ../../../../src/modules/kernel/algebra.mx:3017 #12 0x00007ffff7d09de2 in DFLOWstep (t=0x138de38, fs=0x7fffe23dbfe8) at ../../../src/mal/mal_interpreter.mx:1644 #13 0x00007ffff7d0e926 in runDFLOWworker (t=0x138de38) at ../../../src/mal/mal_interpreter.mx:839 #14 0x00007ffff779463b in wrapper_routine (data=0x7fffe23dc160) at ../../../src/gdk/gdk_posix.mx:983 #15 0x0000003c1a4073da in start_thread () from /lib64/libpthread.so.0 #16 0x0000003c19ce62bd in clone () from /lib64/libc.so.6 Which basically got into such behavior after I added the left join. The following query just works: insert into namefinder select lower(name), lat, long from (select min(way_nds.way) as way, name, bit_and(zcurve, 0xfffffffee0000000) as smooth from (select ways.id as way, v as name from ways, way_tags where ways.id = way_tags.way and way_tags.k = 'name') as x, way_nds, nodes_legacy where x.way = way_nds.way and to_node = id group by name, smooth) as z, way_nds, nodes_legacy where z.way = way_nds.way and to_node = nodes_legacy.id and idx = 1; ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2009-09-07 16:06 Message: That's a different assertion. I.e. my fix does seem to work but there are more places like that. ---------------------------------------------------------------------- Comment By: Stefan de Konink (skinkie) Date: 2009-09-07 14:12 Message: >mserver5: ../../../src/gdk/gdk_bat.mx:291: BATnew: Assertion `cap <= (((BUN) 2147483647) - 1)' failed. Aborted ...if it should be already in current, then it does not work. ---------------------------------------------------------------------- Comment By: Stefan de Konink (skinkie) Date: 2009-09-07 12:18 Message: I see a load of about 100% now, but it doesn't seem to crash like it did before. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2009-09-07 11:24 Message: I added a test in gdk_relop.mx to prevent a BAT from growing beyond BUN_MAX so that the assertion should now be prevented and the query should be aborted one iteration before you would otherwise have gotten the crash. Can you test whether this works? I'll propagate the fix to the development branch shortly. ---------------------------------------------------------------------- Comment By: Stefan de Konink (skinkie) Date: 2009-09-04 16:13 Message: I am using oid32 on Capella; would it be possible to get a more eighter: - a more user friendly message - stopping the execution and gracefully continue - pursue another plan that uses a smaller intermediate result - split the task(?) ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2009-09-04 09:40 Message: apparently at least one intermediate result of your first query (with the left join) exceeds the count that MonetDB can handle on your (not specified) system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2850513&group_id=56967 ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Monetdb-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
