[Symphony] configuration & installation
an ngo
ngothean1 at gmail.com
Mon May 30 02:50:17 EDT 2011
Hi Ted:
Thank you very much for your quick response.
BTW, I just find out another problem
When I have match linked to libSym, I got a result as described in the
manual
However, when I have match linked to libSymAppl, the system crashes,
(Segmentation fault)
So, I go on to debug the source code.
What I found out is there is a structure cut _data
which is sort of polymorphism data
where
char * coef; can be casted to any kind of data
and the interpretation (performed by void unpack_cuts_u in lp_wrapper.c)
will depend on the field type)
What I saw is that:
lines 1925-1927
nzcnt = ((int *) (cuts[i]->coef))[0];
matval = (double *) (cuts[i]->coef + DSIZE);
matind = (int *) (cuts[i]->coef + (nzcnt + 1)*DSIZE);
So, I supposed with cut type is EXPLICIT_ROW then the data pointed out by
coef should be
(ISIZE buyes = 4 in my computer) int number_of_non_zero;
(4 bytes = unused - this ise the difference between DSIZE = 8 and ISIZE=4)
... unused (or something else) => the difference between DSIZE (= 8 bytes in
)
(DSIZE*number of non zero) double non_zero_values
(ISIZE*number of non zero) double non_zero_indexes
However, when I examine the memory at address cuts[i]->coef, I saw
(4 bytes) integer number of non zero
(3*4 bytes) integer non zero indexes
(3*8 bytes) double non_zero_values
$ gdb --args ./match -F sample.mat
...
(gdb) l lp_wrapper.c:1925
1920 case EXPLICIT_ROW:
1921 real_nzcnt = 0;
1922 row_list[explicit_row_num] =
1923 (waiting_row *) malloc(sizeof(waiting_row));
1924 row_list[explicit_row_num]->cut = cuts[i];
1925 nzcnt = ((int *) (cuts[i]->coef))[0];
1926 matval = (double *) (cuts[i]->coef + DSIZE);
1927 matind = (int *) (cuts[i]->coef + (nzcnt + 1)*DSIZE);
1928 row_matval = row_list[explicit_row_num]->matval =
1929 (double *) malloc(nzcnt * DSIZE);
(gdb) b lp_wrapper.c:1925
Breakpoint 1 at 0x8093e96: file LP/lp_wrapper.c, line 1925.
gdb) run
Starting program: /home/an/SYMPHONY-5.3.3/SYMPHONY/Applications/MATCH/match
-F sample.mat
== Welcome to the SYMPHONY MILP Solver
== Copyright 2000-2010 Ted Ralphs and others
== All Rights Reserved.
== Distributed under the Common Public License 1.0
== Version: 5.3.3
== Build Date: May 29 2011
Solving...
solving root lp relaxation
The LP value is: 3.000 [0,6]
Breakpoint 1, unpack_cuts_u (p=0x83bd898, from=0, type=0, cut_num=2,
cuts=0x83db350, new_row_num=0xbfffef50, new_rows=0xbfffef34)
at LP/lp_wrapper.c:1925
1925 nzcnt = ((int *) (cuts[i]->coef))[0];
(gdb) x/40xb cuts[i]->coef
0x83c2988: 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x83c2990: 0x05 0x00 0x00 0x00 0x01 0x00 0x00 0x00
0x83c2998: 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x3f
0x83c29a0: 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x3f
0x83c29a8: 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x3f
Obviously, the program crashes just after it picks up these data
I couln't find any document describing each type of cut_data, so I could n't
really fix it.
However, in the file cg_func.c, I saw the two functions
create_explicit_cut & cg_add_explicit_cut
with the following code
((int *) cut->coef)[0] = nzcnt;
memcpy(cut->coef + ISIZE, (char *)indices, nzcnt*ISIZE);
memcpy(cut->coef + (nzcnt + 1) * ISIZE, (char *)values, nzcnt * DSIZE);
Therefore, I assume that these lines should be changed to
in function unpack_cuts_u
nzcnt = ((int *) (cuts[i]->coef))[0];
//matval = (double *) (cuts[i]->coef + DSIZE);
//matind = (int *) (cuts[i]->coef + (nzcnt + 1)*DSIZE);
// try to see what happens here
// this is OK with create_explicit_cut & cg_add_explicit_cut
matind = (int *) (cuts[i]->coef + ISIZE);
matval = (double *) (cuts[i]->coef + (nzcnt+1)*ISIZE);
// end
and try again, but the program crashes again, at another places (still
something to do with cuts)
As I really in need of this software, if you don't mind to share a little
bit of the design, I would like to contribute to fix some of the bugs
Thanks
An
On Sun, May 29, 2011 at 10:55 AM, Ted Ralphs <ted at lehigh.edu> wrote:
> Thanks for the report and my apologies for the trouble. I had actually
> already discovered this issue and fixed it in trunk. I'll port it the
> fix to stable create a new release as soon as I can.
>
> Cheers,
>
> Ted
>
> On Sat, May 28, 2011 at 7:52 PM, an ngo <ngothean1 at gmail.com> wrote:
> > Hi all:
> > Sorry, I don't know how to continue the same thread, so I send another
> email
> > to clarify the question I sent yesterday.
> > My problem is that while configure my installation by
> > ./configure --with-application
> > when I make the application MATCH the results look like
> USE_SYM_APPLICATION
> > is not defined as no call backs functions are called.
> > However, I did verify that the flag was set properly. Finally, this error
> is
> > caused by:
> > In the file
> > SYMPHONY-5.3.3/SYMPHONY/Applications/Makefile.Applications
> > as COIN_HAS_PKGCONFIG = true
> > match will be linked the library determined by
> > LIBS += `PKG_CONFIG_PATH=/home/thuy/SYMPHONY-5.3.3/lib/pkgconfig:
> > /usr/bin/pkg-config --libs symphony`
> > However, the package config file symphony.pc will lead to libSym instead
> of
> > libSymAppl
> >
> > As a quick fix, I duplicate the file symphony.pc to symphonyappl.pc and
> > change libSym to libSymAppl in the new config.
> > Then in Makefile.Applications, the config file will be symphonyappl
> instead
> > of symphony
> >
> > The issue with USE_GLPMPL is not fixed yet.
> > Thanks
> > A.
> >
> > _______________________________________________
> > Symphony mailing list
> > Symphony at list.coin-or.org
> > http://list.coin-or.org/mailman/listinfo/symphony
> >
> >
>
>
>
> --
> Dr. Ted Ralphs
> Associate Professor, Lehigh University
> (610) 628-1280
> ted 'at' lehigh 'dot' edu
> coral.ie.lehigh.edu/~ted <http://coral.ie.lehigh.edu/%7Eted>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/symphony/attachments/20110530/bfd1864f/attachment.html>
More information about the Symphony
mailing list