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
