Brady Hunsaker <[EMAIL PROTECTED]> writes: > To be clear, I'll restate the issue as I understand it: > > - GLPK is not "data-size neutral". Some code assumes 32-bit memory > addresses.
Not quite. Some code assumes the size of an object in memory can be stored in an "int". > - A previous upstream bug report on this issue resulted in Andrew > (upstream author) putting in a workaround, but the workaround also > removes at least one feature (specifying a memory limit) > > So, the correct long-term solution is to submit upstream patches to make > GLPK data-size neutral. I found some online resources to guide this and > am willing to put some time into it. Ah, nice :) > For the short term, we need to decide what to do. I see three > possibilities: > > 1. Status quo: wait for our upstream corrections to work their way down. > In the meantime, 64-bit architectures may not work correctly. > > 2. Apply upstream patches as soon as we have them. Put debian-only > patches in the current version as soon as we have them, but also submit > them upstream. > > 3. Apply Andrew's workaround for 64-bit architectures. This could be > done immediately, but it removes the memory limit feature. (I guess > there's some way to tell the architectures to build with the > preprocessor variable set?) > > We should do 2 or 3, depending on how much work it will take to identify > all the patches. Falk, do you have any sense on how much effort this > will be? Not really. It might be as easy as fixing umalloc and changing a few "int" to "size_t". It also depends on the thoroughness, for example umalloc should take size_t, but it probably doesn't matter in practise since no single >2G objects are ever allocated. For starters, we need this (completely untested): --- include/glplib.h 2006-04-30 19:43:45.000000000 +0200 +++ include/glplib.h.new 2006-04-30 19:43:37.000000000 +0200 @@ -26,6 +26,8 @@ #ifndef _GLPLIB_H #define _GLPLIB_H +#include <stddef.h> + #define lib_set_ptr glp_lib_set_ptr #define lib_get_ptr glp_lib_get_ptr #define lib_get_time glp_lib_get_time @@ -73,17 +75,17 @@ struct LIBENV /* dynamic memory registration */ LIBMEM *mem_ptr; /* pointer to the linked list of allocated memory blocks */ - int mem_limit; + size_t mem_limit; /* maximal amount of memory (in bytes) available for dynamic allocation */ - int mem_total; + size_t mem_total; /* total amount of currently allocated memory (in bytes; is the sum of the size fields over all memory block descriptors) */ - int mem_tpeak; + size_t mem_tpeak; /* peak value of mem_total */ - int mem_count; + size_t mem_count; /* total number of currently allocated memory blocks */ - int mem_cpeak; + size_t mem_cpeak; /* peak value of mem_count */ /*--------------------------------------------------------------*/ /* input/output streams registration */ @@ -100,7 +102,7 @@ struct LIBENV struct LIBMEM { /* memory block descriptor */ - int size; + size_t size; /* size of block (in bytes, including descriptor) */ int flag; /* descriptor flag */ --- src/glplib2.c 2006-04-30 19:48:46.000000000 +0200 +++ src/glplib2.c.new 2006-04-30 19:48:40.000000000 +0200 @@ -74,7 +74,7 @@ int lib_init_env(void) env->fault_info = NULL; env->fault_hook = NULL; env->mem_ptr = NULL; - env->mem_limit = INT_MAX; + env->mem_limit = SIZE_MAX; env->mem_total = 0; env->mem_tpeak = 0; env->mem_count = 0; @@ -399,10 +399,10 @@ void _insist(char *expr, char *file, int void *umalloc(int size) { LIBENV *env = lib_env_ptr(); LIBMEM *desc; - int size_of_desc = align_datasize(sizeof(LIBMEM)); + size_t size_of_desc = align_datasize(sizeof(LIBMEM)); if (size < 1) fault("umalloc: size = %d; invalid parameter", size); - if (size > INT_MAX - size_of_desc) + if (size > SIZE_MAX - size_of_desc) fault("umalloc: size = %d; size too big", size); size += size_of_desc; if (size > env->mem_limit - env->mem_total) This would have to be tested, which might be some work. Do you have an idea how to generate test instances that use such a huge amount of memory? > If we can get it done with a few hours work, then we should do 2. > If we think it will be more than that, then we should do 3 > immediately. Well, I wouldn't really like to break memory limiting, since IMHO avoiding regressions is more important than new features. But hopefully this can be resolved properly... -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]