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]
