[Coin-discuss] Mac OS X Runtime issue...

Mon Oct 6 21:10:06 EDT 2014

Thanks for the follow-up Ted,

I thought it might be of general interest if there was something going on with OSX 10.9 or something like that.
In general the error means " you touched something you already let go"...

I'm getting it randomly so that tells me it's unlikely the solver directly.  I will say that I get it every time I unload a problem.... but I even get it if I do NOT unload the problem.  The only time I get it from my C driver is when I unload the 
model.  If I comment out the unload of the model then the C driver completes without exception.  I think this indicates that there is definitely something going on with the unload and possibly something else going on with the environment in general.  

>From Java I always get the error... even if the unload is commented out... which is what lead me to believe it's some whacky environment thing.  What's "really fun" is that it happens at random times after the runtime returns control back to Java... which makes me think it must have something to do with how stdout is treated.  

I have registered Log Message, LP Iteration, and 

In terms of version for CoinMP, it's "the latest" (following the instructions for installation pulling through svn and build.

I can't (read this as it's not practical for me to) update GCC via homebrew.   Although I could do that just for my laptop, it won't work for deployment where I _should_ be version agnostic...or I would have to babysit it.

I may have to create a different style interface regardless of what is going on here.  The JVM i'd like to run this from needs to be stable for days at a time...not just for the duration of the solver ... and a JNI error will bring the JVM down... which would not be good at all (think of it as a "career limiting move").

Regardless, I think it might be useful to have a Java binding for using CoinMP in a generic way.  

Here is a little more information ... running from code with unload turned on....

I added the following lines to my bash profile.  It enables runtime testing of the heap (which appears to be pretty sweet how they did it)...

export MallocStackLogging=1
export MallocStackLoggingNoCompact=1

Then I ran the driver C program through lldb and add a specific break point:
(lldb) break set --name malloc_error_break 
... then it will stop at a breakpoint when it thinks you're reading free'd ram. So here is what lldb shows me...

"...

unitTest(60785,0x7fff7db5d310) malloc: *** error for object 0x100801a28: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Process 60785 stopped
* thread #1: tid = 0x5aa45, 0x00007fff90763bc0 libsystem_malloc.dylib`malloc_error_break, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00007fff90763bc0 libsystem_malloc.dylib`malloc_error_break
libsystem_malloc.dylib`malloc_error_break:
-> 0x7fff90763bc0:  pushq  %rbp
   0x7fff90763bc1:  movq   %rsp, %rbp
   0x7fff90763bc4:  nop    
   0x7fff90763bc5:  nopl   (%rax)
(lldb) list
(lldb) 
..."
The "list" command was nearly useless, I'm going to switch to a -g build (rather than -O3) to see if that improves the info any.  I doubt it will.  There is no meaningful stack....and this is the only thread...so it's AFTER the return statement ...:

(lldb) thread list
Process 60785 stopped
* thread #1: tid = 0x5aa45, 0x00007fff90763bc0 libsystem_malloc.dylib`malloc_error_break, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
(lldb) 

So lldb isn't so helpful... but if you LEAVE IT HUNG AT THE BREAKPOINT... and run the command below in a different terminal:
malloc_history process_id address_in_question
in my case...
malloc_history 60785 0x100801a28

...then you get a puke of every use of that memory during the lifetime of the runtime...(before the error is thrown)... 

You can see below the details of every use of that RAM....The BOLD one at the end might be worth looking into why that would happen.  It looks like something is being deleted then referenced... any chance it could be something related to stdout or something like that?  I'm fairly certain that is under the problem unload.

Here is the partial malloc_history dump for me with the worriesome bit in bold:

ALLOC 0x1008019c0-0x100801a37 [size=120]: thread_7fff7db5d310 |start | main | Java_com_workday_MathModeling_CoinMP_CoinLoadProblem | CbcOptimizeProblem | CbcLoadAllSolverObjects(void*, PROBLEMINFO*) | CbcCopyNamesList(void*, PROBLEMINFO*) | ClpModel::copyNames(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) | std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::reserve(unsigned long) | operator new(unsigned
 long) | malloc | malloc_zone_malloc
----
FREE  0x1008019c0-0x100801a37 [size=120]: thread_7fff7db5d310 |start | main | Java_com_workday_MathModeling_CoinMP_CoinLoadProblem | CbcOptimizeProblem | CbcClearSolverObject(void*) | free

On Monday, October 6, 2014 2:18 PM, Ted Ralphs <ted at Lehigh.EDU> wrote:

Hi Philip,

I never got the original message for some reason, but looked back in the archives to see what it said. I work regularly with COIN in OS X and can probably help. If you could say what version of CoinMP you are trying to build that would help. I have not seen any failures like you are describing recently, but OS X is a bit of a complicated platform.

A couple of things to look at:

1. On OS X, the "gcc" compiler command is really calling clang underneath. If you just need to get something building, installing gcc from homebrew and using it instead may get you better results. I believe the libraries should be compatible with anything built by clang.

2. For that matter, there is a homebrew recipe for CoinMP itself. 

brew install coinmp

I'll be happy to help get you up and running if you reply with a little more information. I also transferred the thread to the CoinMP mailing list, although this discussion may be of general interest.

Cheers,

Ted

On Sun, Oct 5, 2014 at 8:02 PM, Matthew Saltzman <mjs at clemson.edu> wrote:

On Sat, 2014-10-04 at 16:02 -0700, Philip Walton wrote:
>> Any suggestion on where to post the information I have to try to get
>> someone to take a look?  I can run tests/build/configure/whatever to
>> try to make it work if someone has some advice.  I won't be able to
>> back-version the compiler as that version is driven by our IT guys...
>> so I can't use the fix above.
>
>I'd post on the CoinMP list
>(http://list.coin-or.org/mailman/listinfo/CoinMP) and if there's no help
>there, contact the project manager directly.
>
>> Side note:
>> When here...
>> http://www.coin-or.org/projects/BuildTools.xml
>>
>> Clicking on the project page link.. it adds a %20 to the URL using
>> chrome (https://projects.coin-or.org/BuildTools%20)..which then fails
>> to navigate.
>>
>
>I'm convinced this is a Chrome bug, but there's a workaround and I've
>applied it to the XML page.  It should be OK now.
>--
>Matthew Saltzman
>Clemson University Math Sciences
>mjs AT clemson DOT edu
>
>_______________________________________________
>Coin-discuss mailing list
>Coin-discuss at list.coin-or.org
>http://list.coin-or.org/mailman/listinfo/coin-discuss
>

-- 
Dr. Ted Ralphs
Associate Professor, Lehigh University
(610) 628-1280
ted 'at' lehigh 'dot' edu
coral.ie.lehigh.edu/~ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/coin-discuss/attachments/20141006/a681eebd/attachment-0001.html>