{"action":"created","issue":{"url":"https://api.github.com/repos/JuliaOpt/Ipopt.jl/issues/9","labels_url":"https://api.github.com/repos/JuliaOpt/Ipopt.jl/issues/9/labels{/name}","comments_url":"https://api.github.com/repos/JuliaOpt/Ipopt.jl/issues/9/comments","events_url":"https://api.github.com/repos/JuliaOpt/Ipopt.jl/issues/9/events","html_url":"https://github.com/JuliaOpt/Ipopt.jl/issues/9","id":35859172,"number":9,"title":"issues with exceptions thrown by Ipopt","user":{"login":"mlubin","id":1733683,"avatar_url":"https://avatars.githubusercontent.com/u/1733683?v=3","gravatar_id":"","url":"https://api.github.com/users/mlubin","html_url":"https://github.com/mlubin","followers_url":"https://api.github.com/users/mlubin/followers","following_url":"https://api.github.com/users/mlubin/following{/other_user}","gists_url":"https://api.github.com/users/mlubin/gists{/gist_id}","starred_url":"https://api.github.com/users/mlubin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mlubin/subscriptions","organizations_url":"https://api.github.com/users/mlubin/orgs","repos_url":"https://api.github.com/users/mlubin/repos","events_url":"https://api.github.com/users/mlubin/events{/privacy}","received_events_url":"https://api.github.com/users/mlubin/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":24,"created_at":"2014-06-17T05:25:58Z","updated_at":"2015-02-24T18:47:07Z","closed_at":null,"body":"This came out of debugging https://groups.google.com/forum/#!topic/julia-opt/J77CzzhNP4g, where JuMP was returning inf or NaN when evaluating a function for numerical reasons. Ipopt already has error handling for this case: https://projects.coin-or.org/Ipopt/browser/trunk/Ipopt/src/Algorithm/IpOrigIpoptNLP.cpp#L496 and throws an exception. (I confirmed that the macro is properly expanded and an exception is indeed thrown.) The C wrapper does seem to have code to catch and display exceptions, but it's never reached. Instead, I've seen two different behaviors:\r\n- On ``julianightlies`` PPA, a core dump occurs. Here's the backtrace:\r\n```\r\nProgram received signal SIGABRT, Aborted.\r\n0x00007ffff6892f79 in __GI_raise (sig=sig@entry=6)\r\n    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56\r\n56\t../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.\r\n(gdb) bt\r\n#0  0x00007ffff6892f79 in __GI_raise (sig=sig@entry=6)\r\n    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56\r\n#1  0x00007ffff6896388 in __GI_abort () at abort.c:89\r\n#2  0x00007ffff5a25521 in _Unwind_Resume () from /lib/x86_64-linux-gnu/libgcc_s.so.1\r\n#3  0x00007ffff1ec75b8 in Ipopt::OrigIpoptNLP::f (this=0x45c7dc0, x=...)\r\n    at IpOrigIpoptNLP.cpp:499\r\n#4  0x00007ffff1e7dbc8 in Ipopt::IpoptCalculatedQuantities::trial_f (this=0x53701e0)\r\n    at IpIpoptCalculatedQuantities.cpp:612\r\n#5  0x00007ffff1e7f153 in Ipopt::IpoptCalculatedQuantities::trial_barrier_obj (\r\n    this=0x53701e0) at IpIpoptCalculatedQuantities.cpp:811\r\n#6  0x00007ffff1e65274 in Ipopt::FilterLSAcceptor::CheckAcceptabilityOfTrialPoint (\r\n    this=0x5371990, alpha_primal_test=1) at IpFilterLSAcceptor.cpp:307\r\n#7  0x00007ffff1e51fb0 in Ipopt::BacktrackingLineSearch::DoBacktrackingLineSearch (\r\n    this=0x5371ac0, skip_first_trial_point=false, alpha_primal=@0x7fffffffc568: 1, \r\n    corr_taken=@0x7fffffffc333: false, soc_taken=@0x7fffffffc334: false, \r\n    n_steps=@0x7fffffffc33c: 0, evaluation_error=@0x7fffffffc550: false, \r\n    actual_delta=...) at IpBacktrackingLineSearch.cpp:726\r\n#8  0x00007ffff1e5074f in Ipopt::BacktrackingLineSearch::FindAcceptableTrialPoint (\r\n    this=0x5371ac0) at IpBacktrackingLineSearch.cpp:462\r\n#9  0x00007ffff1e72886 in Ipopt::IpoptAlgorithm::ComputeAcceptableTrialPoint (\r\n    this=0x5371cf0) at IpIpoptAlg.cpp:542\r\n#10 0x00007ffff1e71863 in Ipopt::IpoptAlgorithm::Optimize (this=0x5371cf0, \r\n    isResto=false) at IpIpoptAlg.cpp:346\r\n#11 0x00007ffff1ddf759 in Ipopt::IpoptApplication::call_optimize (this=0x6042030)\r\n    at IpIpoptApplication.cpp:882\r\n#12 0x00007ffff1dde893 in Ipopt::IpoptApplication::OptimizeNLP (this=0x6042030, \r\n    nlp=..., alg_builder=...) at IpIpoptApplication.cpp:769\r\n#13 0x00007ffff1dde591 in Ipopt::IpoptApplication::OptimizeNLP (this=0x6042030, \r\n    nlp=...) at IpIpoptApplication.cpp:732\r\n#14 0x00007ffff1dde178 in Ipopt::IpoptApplication::OptimizeTNLP (this=0x6042030, \r\n    tnlp=...) at IpIpoptApplication.cpp:711\r\n#15 0x00007ffff1de8cb8 in IpoptSolve (ipopt_problem=0x6041da0, x=0x4ece2d8, \r\n    g=0xc80b610, obj_val=0x53d3d00, mult_g=0x0, mult_x_L=0x0, mult_x_U=0x0, \r\n    user_data=0xb087df0) at IpStdCInterface.cpp:272\r\n#16 0x00007ffff7e379a0 in ?? ()\r\n#17 0x0000000000000000 in ?? ()\r\n```\r\n- On julia built from source on the same machine, the exception seems to be just ignored and Ipopt continues to iterate.\r\n\r\nNeither of these is the right behavior. \r\n@tkelman, have you seen this before?\r\n@keno @vtjnash, is there any reason why C++ exceptions thrown inside a C wrapper called from Julia wouldn't work correctly?"},"comment":{"url":"https://api.github.com/repos/JuliaOpt/Ipopt.jl/issues/comments/75819203","html_url":"https://github.com/JuliaOpt/Ipopt.jl/issues/9#issuecomment-75819203","issue_url":"https://api.github.com/repos/JuliaOpt/Ipopt.jl/issues/9","id":75819203,"user":{"login":"staticfloat","id":130920,"avatar_url":"https://avatars.githubusercontent.com/u/130920?v=3","gravatar_id":"","url":"https://api.github.com/users/staticfloat","html_url":"https://github.com/staticfloat","followers_url":"https://api.github.com/users/staticfloat/followers","following_url":"https://api.github.com/users/staticfloat/following{/other_user}","gists_url":"https://api.github.com/users/staticfloat/gists{/gist_id}","starred_url":"https://api.github.com/users/staticfloat/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/staticfloat/subscriptions","organizations_url":"https://api.github.com/users/staticfloat/orgs","repos_url":"https://api.github.com/users/staticfloat/repos","events_url":"https://api.github.com/users/staticfloat/events{/privacy}","received_events_url":"https://api.github.com/users/staticfloat/received_events","type":"User","site_admin":false},"created_at":"2015-02-24T18:47:07Z","updated_at":"2015-02-24T18:47:07Z","body":"Alright, I've narrowed this down to the fact that if you turn on `--enable-cxx-exceptions` and `--enable-shared` at the same time, and then link against the dynamic library, things go south.  Linking against the static library or setting `--disable-cxx-exceptions` fixes things.\r\n\r\nFor now, the solution I'll use is to link Julia against `libunwind` statically by building it on the `buildd` servers alongside Julia herself.  We should hopefully see a new PPA build in the next few days, right now I'm running into [an issue](https://github.com/JuliaLang/julia/commit/b554ad4b660d8c0e1114280b2c2616d84a354a71#commitcomment-9898746) in how the docs are being generated that's stopping the builds from publishing correctly."}}