Bugs item #1035450, was opened at 2004-09-27 06:11 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1035450&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: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Peter Boncz (boncz) Assigned to: Peter Boncz (boncz) Summary: MonetDB crash: 3>GB addresses on 32-bits systems Initial Comment: MonetDB has a structure MT_alloc_map that holds for each 64KB tille of the address space *until* 3GB a status char (total size is 49600). Each memory allocation (typically GDKmmap) and free administers its region by calling MT_alloc_register() that marks the allocated region (with 'M' characters, in case of GDKmmap). This array is used to administer which regions are used; basically to monitor address space fragmentation. The mechanism is disabled on 64-bits systems (where this is not an issue) Problem: the new fedora-2 core Linux actually assign VM addresses between 1GB and 4GB. Now we have to contend with addresses beyond 3GB. If the base address is before the 3GB limit, but the end of the region extends beyond, then MT_alloc_register() can beyond the 49600 allocated characters for MT_alloc[]. One of the static data structures just beyond that is bbptrim[], which then gets overrun, leading to a crash in BBPtrim. The fix is to extend MT_allco simply to 65536 slots. Then it will work on any 32-bits system no matter how the OS implements the VM address space. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-11-29 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 365 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2006-11-29 01:04 Message: Logged In: YES user_id=572415 Originator: NO over-ruling "sf-robot": re-set to "Pending" since adding a proper test has neither been done nor finally been discarded, yet. User (submitter) & developer (assignee), please check, again. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-11-09 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 365 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2005-11-09 02:20 Message: Logged In: YES user_id=572415 BugDay_2005-11-09, Stefan: NO TEST memory/address space restriction tests *might* be added later ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2004-09-30 02:38 Message: Logged In: YES user_id=572415 According to Peter and Jan, this bug has been fixed, and the fix has been tested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1035450&group_id=56967 ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Monetdb-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
