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 <[email protected]> wrote: > On Thu, Nov 28, 2013 at 12:51 PM, Andrew Makhorin <[email protected]> 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: >> >> mao@corvax:~/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: >> >> mao@corvax:~/Desktop/glpk-4.52/examples$ gcc -I../src >> bug.c ../src/.libs/libglpk.a -lm >> mao@corvax:~/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 >> >> >> _______________________________________________ Bug-glpk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-glpk
