bug-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-glpk] [Fwd: segfault reading a compressed mps file in 4.52]


From: Carlo Baldassi
Subject: Re: [Bug-glpk] [Fwd: segfault reading a compressed mps file in 4.52]
Date: Thu, 28 Nov 2013 13:25:38 +0100

On Thu, Nov 28, 2013 at 12:51 PM, Andrew Makhorin <address@hidden> wrote:
> Thank you for your bug report.
>
>> Hello and sorry for the misunderstanding with the bug-glpk list, I
>> have now subscribed (but, as a suggestion for improvement, I'll add
>> that it's not clear that subscription is required to submit bugs from
>> reading the GLPK homepage at http://www.gnu.org/software/glpk/#bug).
>
> Most of GNU mailing lists require subscription because of a lot of spam.
>

That's understandable, I was merely suggesting to add an explicit note
in the GLPK homepage for people unfamiliar with the process (such as
myself). Not high priority, of course.

>>
>>
>> Thanks for looking into this; here is the trace from running the code
>> through valgrind; I'm not sure if this suggests a bug in my zlib
>> version:
>>
>> ==28394== Memcheck, a memory error detector
>> ==28394== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et
>> al.
>> ==28394== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright
>> info
>> ==28394== Command: glpktst
>> ==28394==
>> Reading problem data from `greenbea.gz'...
>> ==28394== Invalid read of size 8
>> ==28394==    at 0x4EE393C: zlib_crc32 (crc32.c:259)
>> ==28394==    by 0x4EEA819: zlib_inflate (inflate.c:1232)
>> ==28394==    by 0x4EE791F: gz_decomp (gzread.c:189)
>> ==28394==    by 0x4EE7AE5: gz_fetch (gzread.c:245)
>> ==28394==    by 0x4EE7CB7: zlib_gzread (gzread.c:339)
>> ==28394==    by 0x4EE7DD2: zlib_gzgetc (gzread.c:398)
>> ==28394==    by 0x4E61494: _glp_lib_xfgetc (glpenv07.c:580)
>> ==28394==    by 0x4E9F70E: read_char (glpmps.c:167)
>> ==28394==    by 0x4E9FCC2: indicator (glpmps.c:214)
>> ==28394==    by 0x4EA0170: glp_read_mps (glpmps.c:395)
>> ==28394==    by 0x400767: main (in /home/carlo/tmp/glpktst)
>> ==28394==  Address 0x6aeb39f4b68 is not stack'd, malloc'd or
>> (recently) free'd
>> ==28394==
>> ==28394==
>> ==28394== Process terminating with default action of signal 11
>> (SIGSEGV)
>> ==28394==  Access not within mapped region at address 0x6AEB39F4B68
>> ==28394==    at 0x4EE393C: zlib_crc32 (crc32.c:259)
>> ==28394==    by 0x4EEA819: zlib_inflate (inflate.c:1232)
>> ==28394==    by 0x4EE791F: gz_decomp (gzread.c:189)
>> ==28394==    by 0x4EE7AE5: gz_fetch (gzread.c:245)
>> ==28394==    by 0x4EE7CB7: zlib_gzread (gzread.c:339)
>> ==28394==    by 0x4EE7DD2: zlib_gzgetc (gzread.c:398)
>> ==28394==    by 0x4E61494: _glp_lib_xfgetc (glpenv07.c:580)
>> ==28394==    by 0x4E9F70E: read_char (glpmps.c:167)
>> ==28394==    by 0x4E9FCC2: indicator (glpmps.c:214)
>> ==28394==    by 0x4EA0170: glp_read_mps (glpmps.c:395)
>> ==28394==    by 0x400767: main (in /home/carlo/tmp/glpktst)
>> ==28394==  If you believe this happened as a result of a stack
>> ==28394==  overflow in your program's main thread (unlikely but
>> ==28394==  possible), you can try to increase the size of the
>> ==28394==  main thread stack using the --main-stacksize= flag.
>> ==28394==  The main thread stack size used in this run was 8388608.
>> ==28394==
>> ==28394== HEAP SUMMARY:
>> ==28394==     in use at exit: 73,880 bytes in 20 blocks
>> ==28394==   total heap usage: 24 allocs, 4 frees, 77,108 bytes
>> allocated
>> ==28394==
>> ==28394== LEAK SUMMARY:
>> ==28394==    definitely lost: 0 bytes in 0 blocks
>> ==28394==    indirectly lost: 0 bytes in 0 blocks
>> ==28394==      possibly lost: 0 bytes in 0 blocks
>> ==28394==    still reachable: 73,880 bytes in 20 blocks
>> ==28394==         suppressed: 0 bytes in 0 blocks
>> ==28394== Rerun with --leak-check=full to see details of leaked memory
>> ==28394==
>> ==28394== For counts of detected and suppressed errors, rerun with: -v
>> ==28394== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from
>> 2)
>> Segmentation fault (core dumped)
>
> Glpsol 4.52 correctly reads your version of greenbea.gz on my 32-bit
> Linux machine:
>
> address@hidden:~/Desktop/glpk-4.52/examples$ ./glpsol greenbea.gz
> GLPSOL: GLPK LP/MIP Solver, v4.52
> Parameter(s) specified in the command line:
>  greenbea.gz
> Reading problem data from `greenbea.gz'...
> Problem: GREENBEA
> Objective: FAT0..J.
> 2393 rows, 5405 columns, 31499 non-zeros
> 19226 records were read
>
> Your test program also works correctly:
>
> address@hidden:~/Desktop/glpk-4.52/examples$ gcc -I../src
> bug.c ../src/.libs/libglpk.a -lm
> address@hidden:~/Desktop/glpk-4.52/examples$ ./a.out
> Reading problem data from `greenbea.gz'...
> Problem: GREENBEA
> Objective: FAT0..J.
> 2393 rows, 5405 columns, 31499 non-zeros
> 19226 records were read
>
> So I think there is something wrong with building of glpk. How did you
> build it (i.e. which flags did you specify for configure and make)? And
> how did you compile your test program? Please note that glpk has its own
> version of zlib, which is included in libglpk.


Here you can find my config.log file:

https://gist.github.com/carlobaldassi/7690816

I haven't passed any flags to configure or make. Compilation was
smooth, without errors or warnings of any kind. I have not modified
the downloaded source code in any way.
Here are the commands I used for compiling and testing:


$ gcc -I /home/carlo/tmp/glpk-4.52/src/ -L
/home/carlo/tmp/glpk-4.52/src/.libs/ -o glpktst glpktst.c -l glpk
$ export LD_LIBRARY_PATH="/home/carlo/tmp/glpk-4.52/src/.libs"
$ ./glpktst
Reading problem data from `greenbea.gz'...
Segmentation fault (core dumped)


When performing exactly the same steps with glpk-4.48 (download
tarball, extract, configure, make, compile test file, set
LD_LIBRARY_PATH, run) it works fine (and valgrind sees no problem).

Maybe it's a 64 bit issue, since your tests are on 32 bit?

>>
>> As an additional (even though probably irrelevant) detail, I'll add
>> that the file type flag (GLP_MPS_DECK vs GLP_MPS_FILE) does not make
>> any difference.
>>
>
> GLP_MPS_DECK is a fixed-column format, and if no field names are
> omitted, it is a subset of GLP_MPS_FILE which is a free format. Please
> see the glpk reference manual for difference between these two formats.
>

Again, sorry about the confusion. I understand they are different
formats, I was just saying that it makes no difference for the current
bug report (i.e. in the test program I can set the flag to both
values, and it succeeds with glpk-4.48 or glpk-4.52 uncompressed, but
it segfaults with glpk-4.52 compressed).

>
> Andrew Makhorin
>
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]