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

[Carlo Baldassi]

I further bisected the issue and found that the problem appears
between GLPK versions 4.50 and 4.51:

$ gcc -I /home/carlo/tmp/glpk-4.50/src/ -L
/home/carlo/tmp/glpk-4.50/src/.libs/ -o glpktst glpktst.c -l glpk
$ export LD_LIBRARY_PATH="/home/carlo/tmp/glpk-4.50/src/.libs"
$ ./glpktst
Reading problem data from `greenbea.gz'...
Problem: GREENBEA
Objective: FAT0..J.
2393 rows, 5405 columns, 31499 non-zeros
19226 records were read
$ gcc -I /home/carlo/tmp/glpk-4.51/src/ -L
/home/carlo/tmp/glpk-4.51/src/.libs/ -o glpktst glpktst.c -l glpk
$ export LD_LIBRARY_PATH="/home/carlo/tmp/glpk-4.51/src/.libs"
$ ./glpktst
Reading problem data from `greenbea.gz'...
Segmentation fault (core dumped)



On Thu, Nov 28, 2013 at 1:25 PM, Carlo Baldassi <address@hidden> wrote:
> 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
>>
>>
>>