Bugs item #2687040, was opened at 2009-03-14 17:17 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2687040&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: Tests Group: MonetDB4 "stable" >Status: Closed >Resolution: Fixed Priority: 9 Private: No Submitted By: Stefan Manegold (stmane) >Assigned to: Sjoerd Mullender (sjoerd) Summary: M4: test src/modules/plain/Tests/bat.py fails Initial Comment: checkins between Tue Mar 10 2009 & Fri Mar 13 2009 (there was no reliable testing in between due to SF CVS problems) cause test MonetDB4/src/modules/plain/Tests/bat.py to fail; cf., http://monetdb.cwi.nl/testing/projects/monetdb/Stable/MonetDB4/.mTests103/GNU.64.64.d.1-Fedora8/src_modules_plain/bat.out.00.html ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2009-03-16 23:23 Message: I checked in a change to the test, thus fixing the bug. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2009-03-16 23:15 Message: Make that n-256LL (BATTINY=256, not 128). Then the test works, modulo the MIL trace which differs of course. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2009-03-16 23:06 Message: I figured it out: The test code creates a bat with bat(void,chr,n-1LL) where n=lng(100*REMAP_PAGE_SIZE). In other words, bat(void,chr,6553599LL) and then calls mmap(theBat,1) on it. In the old situation, the capacity of the new bat would be 6553599, but since the bat is iteratively filled to size n, i.e. one larger than the asked for size, the bat is extended. This will get into HEAPextend and because of the call to mmap, HEAPextend will extend the bat using a memory-mapped file. In the new situation, because of a change I made for the bat cache, bat capacities are always rounded up to the next multiple of BATTINY (128), which in this case is exactly the aforementioned n. This means that the bat is never extended since the capacity is large enough, and so the heap never becomes memory-mapped. The question is, is this something we should fix in the test (use n-128LL instead of n-1LL) or in the C code (only round up if the capacity is smaller than some threshold)? ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2009-03-16 21:48 Message: You only need to execute the code starting at the comment "create large bats bc (chr) and bl (lng)" to reproduce this. When I do both (with of course --set gdk_mem_pagebits=16) in the Feb2009 release and today's stable, I see this difference: Feb2009: MonetDB>bc.info().find("tail.storage").print(); [ "memory mapped" ] MonetDB>mc.info().find("tail.storage").print(); [ "private map" ] Stable: MonetDB>bc.info().find("tail.storage").print(); [ "malloced" ] MonetDB>mc.info().find("tail.storage").print(); [ "malloced" ] So for some reason the bat is no longer mmap'ed in the Stable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2687040&group_id=56967 ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Monetdb-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
