[Csdp-tickets] message "store_unpacked block type"

[angelika.wiegele at aau.at]

On Thu, 31 May 2012, Brian Borchers wrote:

> 
> 
> On Mon, May 21, 2012 at 6:34 AM, <angelika.wiegele at aau.at> wrote:
>
>       i'm using csdp 6.1.0 and i sometimes get the following message:
>
>       store_unpacked block type
>
>       after that message the program terminates. i think that the message should be "store_unpacked illegal block type", because i found this message only in the file packed.c (function
>       store_unpacked).
>
>       however, i never call the routine "store_unpacked". i call initsoln, easy_sdp and write_prob. i'm thankful for any hint on how to trace this error.
>       (maybe that has to do with this error: apart from default parameters, i use usexzgap=0, tweakgap=1, affine=1.)
>
>       thanks in advance for any comments or suggestions!
>       angelika
> 
> 
> Let me apologize for not responding to this sooner.  You're correct that the message should state that the block type is illegal.  This is a safety check in the code.  It tells me that some other bit of
> code wrote over an important data structure.  Unfortunately, it can be very tricky to determine exactly where this problem is.  
>  
> Here are some questions to start the debugging process.   
>  
> 1. First, can you consistently reproduce this problem with your code by repeating the same inputs, or does it occur entirely at random?  It will be much easier to debug this if you have a test case that
> repeatedly and consistently causes the crash.  
> 
> 2. You can simplify your code by having it write out the problem as a .dat-s file without calling easy_sdp() to solve the problem.  If you do this, do you still get a crash?  
> 
> 3. If not, then use csdp to solve the .dat-s problem and see whether you get a reasonable solution.  It may be that the .dat-s file isn't correct- this would indicate that you made a mistake in setting
> up the problem data structures.  
>  
> 4. Assuming that the .dat-s version of the problem looks good, I'd continue by looking at the output from the easy_sdp() call.  How many iterations are performed before the crash?  Does it crash on the
> first iteration or only later on?  
>  
> 5. It's quite likely that at some point you've either allocated an array of the wrong size (too small) or written beyond the end of an array that was of the correct size.  These kinds of bugs can often
> be tracked down quickly by using a specialized debugging version of the malloc (memory allocator) library.  There are many of these, including "electric-fence", dmalloc, and valgrind.  By linking your
> code with a debugging malloc library, you might be able to cause a crash at the moment when any part of the code writes past the end of an array.     
>  
> If you'd be willing to share your code and a test case that is known to provoke this bug, I'd be happy to run it under a debugging malloc to see if I can find the problem.  I can understand if you'd be
> uncomfortable with sharing your code
> 
> --
> Brian Borchers                          borchers at nmt.edu
> Department of Mathematics      http://www.nmt.edu/~borchers/
> New Mexico Tech                       Phone: (575) 322-2592
> Socorro, NM 87801                   FAX: (575) 835-5366
> 
>

dear brian,

thank you very much for your help! i realized now that the change of the 
parameter file causes this error message. that's what i did: i write the 
problem using write_prob() to a file (attached). then i solve it on the 
command line using csdp. if i use default parameters, then the problem can 
be solved. but with the parameter setting:
usexzgap=0
tweakgap=1
affine=1
the program terminates with the error message "store_unpacked block type" 
after 16 iterations. the reason for choosing this parameter setting is, 
that we want to avoid negative duality gaps. (we want to obtain a reliable 
upper bound from the sdp-relaxation, that's why we usually take the dual 
objectvie value. however, in this problem the dual is below the primal.) 
furthermore, since we use csdp within a branch-and-bound algorithm, there 
might be problems without interior (due to branching decisions) and thus 
i've chosen affine=1 (as suggested in the user's guide).

i appreciate any suggestions on how to find the appropriate parameter 
setting for our purposes or on how to avoid the error message.
angelika
-------------- next part --------------
11 
1 
10 
1.000000000000000000e+00 1.000000000000000000e+00 1.000000000000000000e+00 1.000000000000000000e+00 1.000000000000000000e+00 1.000000000000000000e+00 1.000000000000000000e+00 1.000000000000000000e+00 1.000000000000000000e+00 1.000000000000000000e+00 1.000000000000000000e+00 
0 1 1 1 1.960000000000000142e+01 
0 1 1 2 -1.600000000000000089e+00 
0 1 1 3 -8.000000000000000444e-01 
0 1 1 4 -3.600000000000000089e+00 
0 1 1 5 -2.799999999999999822e+00 
0 1 1 6 -3.200000000000000178e+00 
0 1 1 7 -8.000000000000000444e-01 
0 1 1 8 -1.199999999999999956e+00 
0 1 1 9 -2.000000000000000000e+00 
0 1 1 10 -3.600000000000000089e+00 
0 1 2 2 2.640000000000000568e+01 
0 1 2 3 -3.600000000000000089e+00 
0 1 2 4 -3.200000000000000178e+00 
0 1 2 5 -3.200000000000000178e+00 
0 1 2 6 -2.000000000000000000e+00 
0 1 2 7 -2.000000000000000000e+00 
0 1 2 8 -3.600000000000000089e+00 
0 1 2 9 -3.600000000000000089e+00 
0 1 2 10 -3.600000000000000089e+00 
0 1 3 3 1.600000000000000000e+01 
0 1 3 4 -4.000000000000000222e-01 
0 1 3 5 -2.000000000000000000e+00 
0 1 3 6 -8.000000000000000444e-01 
0 1 3 7 -4.000000000000000222e-01 
0 1 3 8 -2.000000000000000000e+00 
0 1 3 9 -3.200000000000000178e+00 
0 1 3 10 -2.799999999999999822e+00 
0 1 4 4 1.920000000000000284e+01 
0 1 4 5 -2.799999999999999822e+00 
0 1 4 6 -8.000000000000000444e-01 
0 1 4 7 -3.600000000000000089e+00 
0 1 4 8 -8.000000000000000444e-01 
0 1 4 9 -1.199999999999999956e+00 
0 1 4 10 -2.799999999999999822e+00 
0 1 5 5 1.760000000000000142e+01 
0 1 5 6 -2.000000000000000000e+00 
0 1 5 7 -8.000000000000000444e-01 
0 1 5 8 -8.000000000000000444e-01 
0 1 5 9 -2.799999999999999822e+00 
0 1 5 10 -4.000000000000000222e-01 
0 1 6 6 1.840000000000000213e+01 
0 1 6 7 -2.399999999999999911e+00 
0 1 6 8 -2.399999999999999911e+00 
0 1 6 9 -3.200000000000000178e+00 
0 1 6 10 -1.600000000000000089e+00 
0 1 7 7 1.519999999999999929e+01 
0 1 7 8 -2.399999999999999911e+00 
0 1 7 9 -1.600000000000000089e+00 
0 1 7 10 -1.199999999999999956e+00 
0 1 8 8 1.800000000000000000e+01 
0 1 8 9 -1.600000000000000089e+00 
0 1 8 10 -3.200000000000000178e+00 
0 1 9 9 1.960000000000000142e+01 
0 1 9 10 -4.000000000000000222e-01 
0 1 10 10 1.959999999999999787e+01 
1 1 1 1 1.000000000000000000e+00 
2 1 2 2 1.000000000000000000e+00 
3 1 3 3 1.000000000000000000e+00 
4 1 4 4 1.000000000000000000e+00 
5 1 5 5 1.000000000000000000e+00 
6 1 6 6 1.000000000000000000e+00 
7 1 7 7 1.000000000000000000e+00 
8 1 8 8 1.000000000000000000e+00 
9 1 9 9 1.000000000000000000e+00 
10 1 10 10 1.000000000000000000e+00 
11 1 1 7 5.000000000000000000e-01