your bug report.
To fix the bug please replace file glpk-4.52.1/src/glpenv07.c with a
patched version (see attachment) and then recompile the package as
usual.
Andrew Makhorin
glpenv07.c.gz
Description: GNU Zip compressed data
other routine (which provides solution
of current lp relaxation and which should be replaced by a more robust
version). I hope to resolve the issue in 4.31.
Andrew Makhorin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
0; 69)
INTEGER OPTIMAL SOLUTION FOUND
Time used: 0.1 secs
Memory used: 0.1 Mb (151279 bytes)
Thank you for your interest in glpk.
Best regards,
Andrew Makhorin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Saturday, July 12, 2008, 5:56:31 PM, you wrote:
> * Andrew Makhorin <[EMAIL PROTECTED]> [2008-07-12 16:06]:
>> The failure appears due to insufficient robustness of the glpk mip
>> solver. It is mainly caused by unbounded integer variables (x1 and x2
>> have no upp
- - -
1 x1 * 4096 1 1
2 x2 * 4095 1 1
Integer feasibility conditions:
INT.PE: max.abs.err. = 0.00e+00 on row 0
max.rel.err. = 0.00e+00 on row 0
High qualit
>> > All glpk routines always free all allocated memory, so if the
>> > application program has deleted all problem objects, only one memory
>> > block not longer than 1K remains unallocated.
>>
>> This is probably the problem meant by the bug reporter.
> It is. I thought the solution was to call l
ink that that could jeopardize the system, only the application.
> I think that I will patch your sources for the Debian package along the
> vsnprintf lines suggested by Peter. I would encourage you to fix the
> problem in the GLPK source.
Okay. I will make necessary changes to use vs
> Actually, there is a way to circumvent the problem. It is quite ugly
> and I am not sure you would like to implement it. Here is it: make
> the functions xprintf and xprint1 both static, and move them,
> together with xvprintf, into a header file (.h) which will be
> included by all other files c
>> _glp_lib_xprintf is *not* api routine and formally being not declared
>> in glpk.h it is not available to the user.
> Unfortunately, this is not the case. The following works here with GLPK
> 4.21:
> $ cat test.c
> main () { _glp_lib_xprintf ("Ouch!\n"); }
> $ gcc test.c -o test -
Friday, September 14, 2007, 12:21:09 PM, you wrote:
> * Andrew Makhorin <[EMAIL PROTECTED]> [2007-09-11 10:32]:
>> > static void
>> > xvprintf (const char *fmt, va_list arg)
>> > {
>> > charbuf[4000 + 1];
>> > vsp
function, which does not
>> return. :)
> It would likely segfault before calling abort, as strlen would run
> beyond the buffer end.
Yes, in any case the result would be unpredictable.
>>
>> > 3) The correct way to do this is to use vsnprintf. One wants
>>
&
Hi Rafael,
> The bug report below was filed against the GLPK package in Debian.
> Although the reported version is 4.20, the problem would also exist
> in 4.21. Could you please check this?
As I remember the previous bug report concerned one informational
message (from glp_simplex) not masked by
propose a patch to be applied to the Debian package
> such that the bug report can be closed?
Rafael,
I released the version 4.21 to-day, where the bug reported has been
fixed. Please see the announce attached.
(Making a patch would be problematic, because the source code was
c
> Please, confirm to us that the origin of the problem is indeed in
> the source files of the library.
Confirmed. Please see my previous message how to avoid that.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
The message level option passed to either the lp
solver glp_simplex or mip solver glp_intopt does not affect the output
from other glpk routines. In glpk 4.20 one can use the routine
glp_term_hook to redirect (or disable) terminal output. However, in
4.21 for convenience sake I added another api routine, glp_term_out,
to enable/disable terminal output performed by all glpk routines.
Andrew Makhorin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
.
This is no longer needed in 4.14 and 4.15. Starting from the version
4.14 GLPK conforms to ILP32, LLP64, and LP64 programming models assuming
that sizeof(int) = 4 and sizeof(void *) = 4 or 8.
Andrew Makhorin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
situation, I agree that
> switching the types to size_t is the correct solution, and I think it is
> all that is required. That will match the normal malloc prototype.
>
> However, Andrew Makhorin (upstream author) noticed the bug report and
> emailed me about why he prefers not to do t
17 matches
Mail list logo
