[Ipopt-tickets] [Ipopt] #91: Ipopt in R under Linux - a bug or complilation error?

[Ipopt]

#91: Ipopt in R under Linux - a bug or complilation error?
--------------------------------+-------------------------------------------
  Reporter:  anton              |       Owner:  andreasw                          
      Type:  defect             |      Status:  assigned                          
  Priority:  normal             |   Component:  Ipopt                             
   Version:  3.5 (C++ Version)  |    Severity:  normal                            
Resolution:                     |    Keywords:  R, interface, Ipopt, Linux, x86-64
--------------------------------+-------------------------------------------
Changes (by andreasw):

  * owner:  ipopt-team => andreasw
  * status:  new => assigned

Old description:

> I have written an interface to Ipopt, which enables its use in the R
> environment (http://cran.r-project.org/). This helps me in solving
> nonlinear regression problems. This R-ipopt interface is written in C++,
> and it is built under Linux as a shared object libRipopt.so, which
> depends on libraries libipopt.so and libR.so, and is explicitly loaded by
> the R executable. I have built it also under Windows, with a similar
> design. The bundle R-Ripopt-ipopt worked fine with Windows, but under
> Linux it sometimes works, and sometimes it crashes with a “caught
> segfault” message. The Valgrind Memcheck tool has revealed that the crash
> happens inside the ipopt part of the code. Here is an exapmle of the
> Valgrind report:
>
> ==11082== Invalid write of size 4
> ==11082==    at 0xAD47D36:
> Ipopt::Journal::SetPrintLevel(Ipopt::EJournalCategory,
> Ipopt::EJournalLevel) (in
> /home/anton/CoinIpopt/build/lib/libipopt.so.0.0.0)
> ==11082==    by 0xAC0A1E2:
> Ipopt::IpoptApplication::OpenOutputFile(std::string,
> Ipopt::EJournalLevel) (in
> /home/anton/CoinIpopt/build/lib/libipopt.so.0.0.0)
> ==11082==    by 0xAC11BFC:
> Ipopt::IpoptApplication::Initialize(std::istream&) (in
> /home/anton/CoinIpopt/build/lib/libipopt.so.0.0.0)
> ==11082==    by 0xAC1621D:
> Ipopt::IpoptApplication::Initialize(std::string) (in
> /home/anton/CoinIpopt/build/lib/libipopt.so.0.0.0)
> ==11082==    by 0xA9A4DE8: do_Ripopt (Ripopt.cpp:71)
> ==11082==    by 0x4ED6316: (within /usr/lib/R/lib/libR.so)
> ==11082==    by 0x4EFE2AD: Rf_eval (in /usr/lib/R/lib/libR.so)
> ==11082==    by 0x4EFF67F: (within /usr/lib/R/lib/libR.so)
> ==11082==    by 0x4FDCF86: (within /usr/lib/R/lib/libR.so)
> ==11082==    by 0x4EFE063: Rf_eval (in /usr/lib/R/lib/libR.so)
> ==11082==    by 0x4F00277: (within /usr/lib/R/lib/libR.so)
> ==11082==    by 0x4EFE063: Rf_eval (in /usr/lib/R/lib/libR.so)
> ==11082==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
>
> Could you please help to resolve this problem? I should add that this
> happens under Debian GNU/Linux x86_64. Maybe, the problem is actually
> hidden inside R (and hardly in Ripopt, as I first thought), but I really
> don’t know. I can send you a copy of my source code together with the g++
> options I used, if required. Unfortunately, I cannot send the statistical
> data that I processed.
>
> I hope that this report will be useful for the further development of
> ipopt, which I personally find a great product.
>
> Best regards,
> Anton Tyutin

New description:

 I have written an interface to Ipopt, which enables its use in the R
 environment (http://cran.r-project.org/). This helps me in solving
 nonlinear regression problems. This R-ipopt interface is written in C++,
 and it is built under Linux as a shared object libRipopt.so, which depends
 on libraries libipopt.so and libR.so, and is explicitly loaded by the R
 executable. I have built it also under Windows, with a similar design. The
 bundle R-Ripopt-ipopt worked fine with Windows, but under Linux it
 sometimes works, and sometimes it crashes with a “caught segfault”
 message. The Valgrind Memcheck tool has revealed that the crash happens
 inside the ipopt part of the code. Here is an exapmle of the Valgrind
 report:

 {{{
 ==11082== Invalid write of size 4
 ==11082==    at 0xAD47D36:
 Ipopt::Journal::SetPrintLevel(Ipopt::EJournalCategory,
 Ipopt::EJournalLevel) (in
 /home/anton/CoinIpopt/build/lib/libipopt.so.0.0.0)
 ==11082==    by 0xAC0A1E2:
 Ipopt::IpoptApplication::OpenOutputFile(std::string, Ipopt::EJournalLevel)
 (in /home/anton/CoinIpopt/build/lib/libipopt.so.0.0.0)
 ==11082==    by 0xAC11BFC:
 Ipopt::IpoptApplication::Initialize(std::istream&) (in
 /home/anton/CoinIpopt/build/lib/libipopt.so.0.0.0)
 ==11082==    by 0xAC1621D:
 Ipopt::IpoptApplication::Initialize(std::string) (in
 /home/anton/CoinIpopt/build/lib/libipopt.so.0.0.0)
 ==11082==    by 0xA9A4DE8: do_Ripopt (Ripopt.cpp:71)
 ==11082==    by 0x4ED6316: (within /usr/lib/R/lib/libR.so)
 ==11082==    by 0x4EFE2AD: Rf_eval (in /usr/lib/R/lib/libR.so)
 ==11082==    by 0x4EFF67F: (within /usr/lib/R/lib/libR.so)
 ==11082==    by 0x4FDCF86: (within /usr/lib/R/lib/libR.so)
 ==11082==    by 0x4EFE063: Rf_eval (in /usr/lib/R/lib/libR.so)
 ==11082==    by 0x4F00277: (within /usr/lib/R/lib/libR.so)
 ==11082==    by 0x4EFE063: Rf_eval (in /usr/lib/R/lib/libR.so)
 ==11082==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
 }}}

 Could you please help to resolve this problem? I should add that this
 happens under Debian GNU/Linux x86_64. Maybe, the problem is actually
 hidden inside R (and hardly in Ripopt, as I first thought), but I really
 don’t know. I can send you a copy of my source code together with the g++
 options I used, if required. Unfortunately, I cannot send the statistical
 data that I processed.

 I hope that this report will be useful for the further development of
 ipopt, which I personally find a great product.

 Best regards,
 Anton Tyutin

Comment:

 Hi Anton,

 First of all, I'm very happy to hear that you are using Ipopt with R and
 are developing an interface to R.  I have actually never used R, but it is
 quite popular among some colleagues.

 As for the segmentation fault that you are reporting, I don't see from the
 valgrind output what the problem could be.  We have done many valgrind
 runs with Ipopt in different settings, and this didn't show up.  In some
 circumstances (like in matlab or the modeling environment GAMS) one has to
 be careful with the output, since the standard output or writing into
 files is somehow overloaded in those settings and one has to create extra
 "Journalists" that use program dependent (e.g., matlab specific) output
 functions.  Maybe this is also the case with what you see?

 Well, I noticed in the stack that you report that the error happens in a
 method !OpenOutputFile which seems to be only called if you are asking
 Ipopt to write an output file (using the output_file option).  Do you
 still get the error if you don't ask Ipopt to generate this output file?

 Also, do you want to post the few lines of do_Ripopt that setup the
 !IpoptApplication object and initialize it?

 Andreas

-- 
Ticket URL: <https://projects.coin-or.org/Ipopt/ticket/91#comment:1>
Ipopt <http://projects.coin-or.org/Ipopt>
Interior-point optimizer for nonlinear programs.