On Wed, Apr 03, 2013 at 12:38:09AM +0200, Axel Beckert wrote: > Hi again, > > Dominic Hargreaves wrote: > > On Sun, Mar 31, 2013 at 04:00:24PM +0600, Andrey Rahmatullin wrote: > > > On Sat, Mar 30, 2013 at 05:37:27PM +0000, Dominic Hargreaves wrote: > > > > In a clean wheezy chroot: > > > > > > > > ok 51 - code > > > > not ok 52 - errstr > > > > > > > > # Failed test 'errstr' > > > > # at t/050-async-client.t line 268. > > > > # 'Lua error: stack overflow (call: out of stack)' > > > > # doesn't match '(?^:Partial key in)' > > > FWIW it didn't fail here in a sid am64 chroot. > > FWIW I could _not_ reproduce that FTBFS when building the (0.15-1) > package with pbuilder in a Wheezy chroot on Squeeze (all amd64), but I > could reproduce this issue on a Wheezy i386 box (without chroot). > > Dominic, did you experience the build failure on i386? If so, this > looks very similar to https://bugs.launchpad.net/tarantool/+bug/1021177
Yes indeed. Sorry I missed this detail off before. > Citing from there: > | After gcc-4.7 patches tarantool began returning different errors on > | different architectures: > | > | if you call 'box.select()' (without arguments): > | on amd64 You receive an error: "Partial key in an exact match (key > | field count: ..." > | but on i386 You receive an error: "Lua error: stack overflow (call: > | out of stack)" > | > | both architectures returned the same errors until gcc4.7 patches > > The above LP bug report has been marked invalid with the following > explanation: > > | I guess that you use different types of indexes on your hosts (HASH on > | amd64 and TREE on i386) > | > | TREE index supports both box.select(0) and > | box.space[x]:index[y]:iterator(box.index.ALL) without a key. > | box.select() in this case returns all tuples from a space. The number > | of returned tuples is limited only by Lua stack size. > | If a result set is too large then Lua raises "Lua error: stack > | overflow (call: out of stack)" error. > | See https://bugs.launchpad.net/tarantool/+bug/1018775 > > This is again a (confirmed) bug report against tarantool and there is > explained: > > | Currently select_range() can only return 8000 tuples, because it > | puts these tuples into a Lua table, and then calls unpack() on the > | table. > > So for me this currently looks like an issue in tarantool and not in > libdr-tarantool-perl. I'm though not sure what's the best way to solve > that. For wheezy patching the testsuite to accept both types of error > messages is possibly an option to solve this issue. Sounds reasonable. > > True; in sid, the failure (with 0.15-1) seems to come at > > > > # Failed test 'errstr' > > # at t/020-low_level_client.t line 125. > > # 'Duplicate key exists in unique index 0' > > # doesn't match '(?^:already exists)' > > Indeed. > > That test seems to check for an error message which likely comes from > some of the packages built from the tarantool source package and not > from libdr-tarantool-perl itself. And since tarantool in Wheezy has > 1.4.6+20120629+2158-1 while Sid has 1.4.8+20130306.1415-1 I suspect > that this error message has changed in tarantool between those two > versions. That test probably should be more fault tolerant to multiple > upstream versions. > > For the latter issue, patching the testsuite to match the current > error message is sufficient. But since libdr-tarantool-perl has > already 0.35-1 in Sid, it's no more necessary. > > (Oh, and my 0.35-1 FTBFS from my previous mail ended up in > http://bugs.debian.org/704551) Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
