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).

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)

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.

On Thu, Nov 28, 2013 at 1:48 AM, Heinrich Schuchardt <[email protected]>wrote:

> Hello Carlo,
>
> your mail had to be forwarded manually because you were not subscribed to
> the list, see
> https://lists.gnu.org/mailman/listinfo/bug-glpk
>
> I was not able to reproduce the issue with GLPK 4.52 on Debian Jessie.
>
> Please, run the program with valgrind to identify where the segmentation
> fault occurs.
>
> Best regards
>
> Heinrich Schuchardt
>
> http://www.xypron.de
>
>
> > Gesendet: Mittwoch, 27. November 2013 um 08:18 Uhr
> > Von: "Andrew Makhorin" <[email protected]>
> > An: [email protected]
> > Betreff: [Bug-glpk] [Fwd: segfault reading a compressed mps file in 4.52]
> >
> > -------- Forwarded Message --------
> > To: [email protected]
> > Subject: segfault reading a compressed mps file in 4.52
> > Date: Tue, 26 Nov 2013 19:08:35 +0100
> >
> > Using GLPK 4.52, glp_read_mps fails with a segfault on this file:
> >
> >
> https://github.com/mlubin/SimplexBenchmarks/raw/master/GenerateData/greenbea.gz
> >
> >
> > uncompressing it works fine. Also, GLPK 4.48 works fine on the
> > compressed file, so the bug was introduced between these versions.
> >
> >
> > I'm testing on 64bit Linux (Ubuntu 13.04). zlib version is 1.2.7.
> >
> >
> > Here is a sample C file which reproduces the problem:
> >
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <glpk.h>
> >
> > int main()
> > {
> >    glp_prob * lp;
> >    lp = glp_create_prob();
> >    glp_read_mps(lp, GLP_MPS_DECK, NULL, "greenbea.gz");
> >    glp_delete_prob(lp);
> >    return 0;
> > }
> >
> >
> >
> > Here is the output:
> >
> > $ glpktst
> > Reading problem data from `greenbea.gz'...
> > Segmentation fault (core dumped)
> >
> >
> > Best regards
> >
> > Carlo Baldassi
>
> --
> Diese E-Mail wurde aus dem Sicherheitsverbund E-Mail made in
> Germany versendet: http://www.gmx.net/e-mail-made-in-germany
>
_______________________________________________
Bug-glpk mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-glpk

Reply via email to