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-18 17:38
Message:
Stefan, what is the situation now?
----------------------------------------------------------------------
Comment By: Sjoerd Mullender (sjoerd)
Date: 2009-09-08 11:21
Message:
I added more checks against overflow. Can you check again?
----------------------------------------------------------------------
Comment By: Stefan de Konink (skinkie)
Date: 2009-09-08 01:08
Message:
(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 0x00007ffff7686a79 in BATnew (ht=7, tt=7, cap=2699054870)
at ../../../src/gdk/gdk_bat.mx:291
#4 0x00007ffff76aac18 in mergejoin (l=0x12b2d58, r=0x7fffd40010d0,
bn=0x0,
nil_on_miss=0x0, estimate=2147483647, limit=0x0)
at ../../../src/gdk/gdk_relop.mx:140
#5 0x00007ffff76bc4dd in batmergejoin (l=0x7fffd40010a8, r=0x12b2d80,
estimate=2147483647, swap=1 '\001', limit=0x0)
at ../../../src/gdk/gdk_relop.mx:396
#6 0x00007ffff76f899f in batjoin (l=0x7fffd40010a8, r=0x12b2d80,
estimate=2147483647, swap=1 '\001') at
../../../src/gdk/gdk_relop.mx:1207
#7 0x00007ffff76f8aa9 in BATjoin (l=0x7fffd40010a8, r=0x12b2d80,
estimate=2147483647) at ../../../src/gdk/gdk_relop.mx:1227
#8 0x00007fffebc1b2c1 in CMDjoin (result=0x7fffe197ba68,
left=0x7fffd40010a8,
right=0x12b2d80, estimate=0x7fffe197bab8)
at ../../../../src/modules/kernel/algebra.mx:1552
#9 0x00007fffebc27014 in ALGjoinestimate (result=0x12e23a0,
lid=0x12e2390,
rid=0x12e2380, estimate=0x7fffe197bab8)
at ../../../../src/modules/kernel/algebra.mx:2999
#10 0x00007fffebc2713e in ALGjoin (result=0x12e23a0, lid=0x12e2390,
rid=0x12e2380) at ../../../../src/modules/kernel/algebra.mx:3017
---Type <return> to continue, or q <return> to quit---
#11 0x00007ffff7d08f60 in DFLOWstep (t=0x12b7c58, fs=0x7fffe2982fe8)
at ../../../src/mal/mal_interpreter.mx:1650
#12 0x00007ffff7d0dac0 in runDFLOWworker (t=0x12b7c58)
at ../../../src/mal/mal_interpreter.mx:845
#13 0x00007ffff7793383 in wrapper_routine (data=0x7fffe2983160)
at ../../../src/gdk/gdk_posix.mx:983
#14 0x0000003c1a4073da in start_thread () from /lib64/libpthread.so.0
#15 0x0000003c19ce62bd in clone () from /lib64/libc.so.6
hope that helps.
----------------------------------------------------------------------
Comment By: Sjoerd Mullender (sjoerd)
Date: 2009-09-07 17:24
Message:
By the way, it would be useful to know where BATnew is called from in your
latest assertion failed.
----------------------------------------------------------------------
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
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
