[Ipopt] unusual crash in scaling

[Damien]

I found it.  It was me.  It was an uninitialised type conversion on the 
index style.  So sometimes it worked, and sometimes it didn't...

On 2015-06-18 9:38 AM, Jonathan Hogg wrote:
> Not really an expert on Ipopt in particular, but behavior sounds
> suspiciously like a memory corruption or uninitialized variable issue.
>
> Assuming you can't find the problem with others' advice from the stack
> trace, try some form of memory checker if you haven't already. If you're
> on linux look at address sanitizer (fast, requires gcc/llvm based
> compilation with special flags) or valgrind (slow, works with any
> executable).
>
> Jonathan.
>
> On 18/06/15 16:15, Damien wrote:
>> Hi,
>>
>> I've had an intermittent crash that only happens in release builds
>> (yay...) for the last couple of months.  I just managed to catch it in
>> the debugger.  I'm posting this looking for guidance because I don't
>> want to lose my stack trace.  Sorry this is a little specific.
>>
>> In GradientScaling::DetermineScalingParametersImpl, there's eventually a
>> call that ends up in GenTMatrix::ComputeRowAMaxImpl. The crash is
>> because irows[0] = 67108865 (irows[1] = 67108865 as well) and it's off
>> the end of the vec_vals array pointer.  There's about 5.2 million
>> nonzeroes in the Jacobian, so an index of 67 million is a tad high.  The
>> rest of the irows array looks right (1, 1, 2, 2, 3, 3, etc).
>>
>> This is really hard to reproduce and is intermittent.  Can any of the
>> experts in the code point me to where to look?
>>
>> Damien
>> _______________________________________________
>> Ipopt mailing list
>> Ipopt at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/ipopt
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt