Njoselson commented 9 years ago

Hello, I wrote this as a comment in a closed issue without knowing whether the developers could see it, so I thought I would create a new issue as well.

I am trying to debug an out of bounds error that keeps making R crash. The problem is, that when I use gdbsource("file") it only gives me an error: "Error in line:length(x) : argument of length 0 In addition: Warning message: running command 'R --vanilla < C:/Users/Nathaniel/Documents/MoultProb.R -d gdb --debugger-args="-x C:\Users\NATHAN~1\AppData\Local\Temp\RtmpE7k6FC\file163060ca5272 "' had status 255"

I have tried to run each line of the debugger separately, changed my User Path to include R and Rtools and Rstudio, and have tried to follow all the directions in the gdbsource document (having files of the same name; adding "-O0 -g" in the compilation step).

I have looked around this website but can't seem to find further documentation on debugging the debugger.

Thanks, Nathaniel

kaskr commented 9 years ago

Currently gdbsource does not work on the windows operating system. I will see if I can fix this. Otherwise it should be documented under ?gdbsource.

Njoselson commented 9 years ago

Thanks, No wonder. Will see what I can do without it.

Nathaniel

Njoselson commented 9 years ago

Do you know the equivalent system command in windows for R --vanilla < filepath.R -d gdb --debugger-args="-x tempfile "?

kaskr commented 9 years ago

gdbsource now also works on windows. One has to compile with compile(cppfile,"-O1 -g",DLLFLAGS="") I was unable to get the compilation working with lower optimization level on windows (required in order to print variables during a debug session).

Njoselson commented 9 years ago

This fix still hasn't worked for me. On the tmb example files, the same error still comes: "Error in line:length(x) : argument of length 0".

I am compiling according to your instructions, but for some reason, the function still doesn't work. Does it sound like there could be a problem with my gdb? I have the minGW gdb, Rstudio and a 64 bit windows.

kaskr commented 9 years ago

I forgot to say this is a fix on the master branch so you have to update your TMB installation:

remove.packages(TMB)
source("install_windows.R")

did you do that?

Also, make sure the .cpp file name match the .R file name.

If you cannot make it work in non-interactive mode

gdbsource("mymodel.R",FALSE) ## Non-interactive

what happens if you run it in interactive mode?

gdbsource("mymodel.R",TRUE)  ## Interactive

Njoselson commented 9 years ago

Yes, I did reinstall the package and yes the files are with the same name. When I compile it with interactive=FALSE, I get the length(x)=0 error, and when I use TRUE, it opens a command prompt where the gdb program opens, but then doesn't run with the error:

"Rterm: No such file or directory. No symbol table is loaded. Use the "file" command. Breakpoint 1 (abort) pending. Error in sources command file. No executable specified, use 'target exec'."

And then it goes to a blank gdb line (gdb) _

On Dec 29, 2014, at 4:18 PM, kaskr notifications@github.com wrote:

I forgot to say this is a fix on the master branch so you have to update your TMB installation:

remove.packages(TMB) source("install_windows.R") did you do that?

Also, make sure the .cpp file name match the .R file name.

If you cannot make it work in non-interactive mode

gdbsource("mymodel.R",FALSE) ## Non-interactive what happens if you run it in interactive mode?

gdbsource("mymodel.R",TRUE) ## Interactive — Reply to this email directly or view it on GitHub.

kaskr commented 9 years ago

Why is "Rterm" not found? Try this:

library(TMB)
dir(fileLocations()$rbin)  ## Should contain 'Rterm.exe'
shell("PATH")              ## Should contain fileLocations()$rbin
shell("start Rterm")       ## Should start Rterm in new window

Njoselson commented 9 years ago

Yes, this does start Rterm in a new window but gdbsource still doesn't work. Now it gives the message: "C:\Program Files\R\R-3.1.2\bin\x64/Rterm.exe": not in executable format: File format not recognized. No symbol table is loaded. Use the "file" command. Breakpoint 1 (abort) pending. Error in sources command file. No executable specified, use 'target exec'.

Njoselson commented 9 years ago

And running the gdbsource in the Rterm window gives the same error. Am I misunderstanding what you mean?

kaskr commented 9 years ago

This:

"C:\Program Files\R\R-3.1.2\bin\x64/Rterm.exe": not in executable format

is probably because of the space in the path. Do you have a space in

Sys.getenv("R_HOME")

If yes, does this get rid of the space:

shortPathName(Sys.getenv("R_HOME"))

If yes, could you try to modify 'install_windows.R' with an extra line:

fileLocations <- function(){
  rhome <- Sys.getenv("R_HOME")
  rbin <- paste0(rhome,"/bin/",.Platform$r_arch)
  rtools <- c("C:/Rtools",
              "~/Rtools",
              paste0(rhome,"/../../Rtools"),
              paste0(rhome,"/../Rtools") )
  gccbin <- paste0(rtools,"/gcc-4.6.3/bin")
  gdbbin <- paste0(rtools,"/gcc-4.6.3/bin64")
  ans <- list(rhome=rhome,rbin=rbin,rtools=rtools,gccbin=gccbin,gdbbin=gdbbin)
  ans <- lapply(ans,shortPathName)  ## <----- ADD THIS LINE
  lapply(ans,function(x)x[file.exists(x)][1])
}

Then reinstall TMB.

Njoselson commented 9 years ago

I don't have a space when I run Sys.getenv("R_HOME") The path there is: C:/PROGRA~1/R/R-31~1.2

I have also modified the system path for the bins in R as well from 'Program Files' to 'PROGRA~1', this didn't work either.

Should I still try to modify the 'install_windows.R'

Sorry to be so confused.

kaskr commented 9 years ago

No, my previous suggestion is not useful then. And I just discovered the R-documentation ?R.home says: " On Windows the values of ‘R.home()’ and ‘R_HOME’ are guaranteed not to contain spaces, switching to the 8.3 short form of path elements if required. " Could you instead post the output of

library(TMB)
shell("PATH")

I am still puzzled about the cause of the path spaces...

Njoselson commented 9 years ago

> library(TMB) > shell("PATH") PATH=C:\Program Files\R\R-3.1.2\bin\x64;c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;c:\Rtools\gcc-4.6.3\bin32;C:\ProgramData\Oracle\Java\javapath;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\12.0\DLLShared\;c:\Program Files (x86)\Roxio\OEM\AudioCore\;C:\Program Files\doxygen\bin;C:\PROGRA~1\R\R-3.1.2\bin;C:\PROGRA~1\R\R-3.1.2\bin\x64;C:\Program Files (x86)\Sophos\Sophos SSL VPN Client\bin;c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;c:\Rtools\gcc-4.6.3\bin32;C:\ProgramData\Oracle\Java\javapath;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\PROGRA~1\Intel\WiFi\bin\;C:\PROGRA~1\Common Files\Intel\WirelessCommon\;c:\PROGRA~2\Common Files\Roxio Shared\OEM\DLLShared\;c:\PROGRA~2\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\12.0\DLLShared\;c:\Program Files (x86)\Roxio\OEM\AudioCore\;C:\Program Files\doxygen\bin;C:\PROGRA~1\R\R-3.1.2\bin;C:\PROGRA~1\R\R-3.1.2\bin\x64;

kaskr commented 9 years ago

Well, that explains where the space comes from:

C:\Program Files\R\R-3.1.2\bin\x64;c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;c:\Rtools\gcc-4.6.3\bin32

It seems to me this path is not auto-generated by TMB? (because of the order). When TMB is loaded on windows the function setPath() is called. Maybe that part failed? Could you post the output of

library(TMB)
setPath()
shell("PATH")

(or just say if anything changed)

Njoselson commented 9 years ago

PATH=C:/Rtools/bin;C:/Rtools/gcc-4.6.3/bin;C:/PROGRA~1/R/R-31~1.2/bin;C:\Program Files\R\R-3.1.2\bin\x64;c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;c:\Rtools\gcc-4.6.3\bin32;C:\ProgramData\Oracle\Java\javapath;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\12.0\DLLShared\;c:\Program Files (x86)\Roxio\OEM\AudioCore\;C:\Program Files\doxygen\bin;C:\PROGRA~1\R\R-3.1.2\bin;C:\PROGRA~1\R\R-3.1.2\bin\x64;C:\Program Files (x86)\Sophos\Sophos SSL VPN Client\bin;c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;c:\Rtools\gcc-4.6.3\bin32;C:\ProgramData\Oracle\Java\javapath;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\PROGRA~1\Intel\WiFi\bin\;C:\PROGRA~1\Common Files\Intel\WirelessCommon\;c:\PROGRA~2\Common Files\Roxio Shared\OEM\DLLShared\;c:\PROGRA~2\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\12.0\DLLShared\;c:\Program Files (x86)\Roxio\OEM\AudioCore\;C:\Program Files\doxygen\bin;C:\PROGRA~1\R\R-3.1.2\bin;C:\PROGRA~1\R\R-3.1.2\bin\x64;

Basically, only the first couple of lines have changed, and I still get the same error from gdb when I run gdbsource( ... , interactive=TRUE)

kaskr commented 9 years ago

setPath() correctly added

C:/Rtools/bin;C:/Rtools/gcc-4.6.3/bin;C:/PROGRA~1/R/R-31~1.2/bin;

but it did not add the 64bit gdb. Instead the 32 bit gdb from your (old?) Rtools installation is used to debug 64 bit Rterm.exe, which explains the error. Does

fileLocations()

have NA in the component gdbbin? If yes, it means that your current Rtools installation does not have the 64 bit gdb. Then the solution should be to remove your old Rtools installation and run the install_windows.R script again (this will install the correct version of Rtools).

Njoselson commented 9 years ago

The output is as follows:

fileLocations() $rhome [1] "C:/PROGRA~1/R/R-31~1.2"

$rbin [1] "C:/PROGRA~1/R/R-31~1.2/bin"

$rtools [1] "C:/Rtools"

$gccbin [1] "C:/Rtools/gcc-4.6.3/bin"

There is no component gdbbin.

kaskr commented 9 years ago

If your current source code of the install_windows.R script does not contain 'gdbbin', then the adcomp folder have not been correctly updated, and you need to download again and reinstall.

Njoselson commented 9 years ago

Perhaps I have been installing it wrong, because I downloaded it again and it still hasn't worked.

I first uninstall the package TMB, then run the following: devtools::install_github("kaskr/adcomp", subdir = "TMB")

kaskr commented 9 years ago

This approach only updates the subfolder 'TMB'. Please follow the install instructions stated in the README.

Njoselson commented 9 years ago

Using source("install_windows.R") with the newly cloned adcomp master folder, there is no change in the functionality of gdbsource. It still opens, gives the R.exe not an executable file message, and then opens a blank gdb line which doesn't take R documents as an input for the file command.

The only effect has been that the fileLocations() function now returns: $gdbbin [1] "C:/Rtools/gcc-4.6.3/bin64"

kaskr commented 9 years ago

Check that

shell("where gdb")
shell("where Rterm")

gives the matching (both 64 bit) versions. If not, fix the PATH.

Otherwise, remove your Rtools folder and repeat install_windows.R step (to make sure you get the right Rtools).

Njoselson commented 9 years ago

The problem is solved!

I uninstalled R, and then reinstalled it, making the location C:\PROGRA~1... Then, I reinstalled Rtools and manually added the bins C:\Rtools\gcc-4.6.3\i686-w64-mingw32\bin and C:\Rtools\gcc-4.6.3\bin64 to the path, during the install. Then I reinstalled TMB from source("install_windows.R") and the gdbsource() works perfectly.

Thanks so much for your patience through this! Great program!

James-Thorson commented 8 years ago

Hi all,

During a TMB training workshop, we built a function that can replace MakeADFun on the windows operating system, which calls the debugger and if it passes just compiles the original model, and if it fails gives the output from the debugger:

MakeADFun_windows_debug = function( cpp_name, data, parameters, random=NULL, dir=getwd(), overwrite=FALSE, recompile=TRUE, ... ){

  # Set local working directory
  orig_dir = getwd()
  setwd( dir )
  on.exit( setwd(orig_dir) )

  # Recompile
  if( recompile==TRUE ){
    unlink( dynlib(cpp_name) )
    compile( paste0(cpp_name,".cpp"), "-O1 -g", DLLFLAGS="")
    dyn.load( dynlib(cpp_name) )
  }

  # Get and save inputs
  Other_inputs = list(...)
  All_inputs = list( "data"=data, "parameters"=parameters, "random"=random, "Other_inputs"=Other_inputs )
  save( All_inputs, file="All_inputs.RData")

  # Write file to source
  if( (paste0(cpp_name,".R") %in% list.files()) & overwrite==FALSE ){
    message( "By default, we don't overwrite existing file ",cpp_name,".R")
    Return = "Didn't attempt running"
  }else{
    sink( paste0(cpp_name,".R") )
    cat("
      library( TMB )
      dyn.load( dynlib('",cpp_name,"') )
      setwd('",dir,"')
      load( 'All_inputs.RData' )
      Obj = MakeADFun(data=All_inputs[['data']], parameters=All_inputs[['parameters']], random=All_inputs[['random']], All_inputs[['Other_inputs']])
      save( Obj, file='Obj.RData')
    ",fill=FALSE,sep="")
    sink()

    # Try running
    Bdg_output = gdbsource(paste0(cpp_name,".R"))

    # Sort out outcomes
    if( length(grep("#0",Bdg_output))==0 ){
      Return = MakeADFun(data=All_inputs[['data']], parameters=All_inputs[['parameters']], random=All_inputs[['random']], All_inputs[['Other_inputs']])
      message("Compiled fine, and returning output from MakeADFun")
    }else{
      Return = Bdg_output
      message("Did not compile, and returning output from bdbsource")
      #print( Bdg_output )
    }
  }

  # Return
  return( Return )
}

We imagine that this function is probably not suitable for the TMB library (because its a bit gimmicky, and because it probably wouldn't pass CRAN standards). But perhaps we could put it in a new user-contributed library of helper functions, say, TMBtools, which could be downloaded from GitHub.

Kasper and others -- any thoughts or preferences for how to proceed?

cheers, jim

kaskr commented 8 years ago

This idea could easily be transformed into a useful package (purpose: make debugging easier and guarantee that the main R session never crashes).

Some comments to the code:

Widen the scope to not being Windows specific.
Don't save/load Obj. There is no time saving because the external pointers are recomputed in the main session anyway. Debugging must be robust and should not rely on saving/loading ADFun objects.
Rather than renaming MakeADFun and calling compile I suggest you simply overload the two functions. Something like:

compile <- function(...){
    args <- list(...)
    if (.Platform$OS.type == "windows") {
        args$flags <- "-O1 -g"
        args$DLLFLAGS <- ""
    } else {
        args$flags <- "-O0 -g"
    }
    do.call(TMB::compile, args)
}
MakeADFun <- function(..., DLL = TMB:::getUserDLL()){
    ## Set local working directory
    orig_dir <- getwd()
    setwd( tempdir() )
    on.exit( setwd(orig_dir) )
    ## Save inputs
    All_inputs <- list(..., DLL=DLL)
    save( All_inputs, file="All_inputs.RData")
    ## Copy DLL to tempdir
    DLL <- All_inputs$DLL
    DLLfull <- paste0(orig_dir,"/",DLL)
    ## Write file to source
    txt <- c("library( TMB )",
             paste0("dyn.load(dynlib('",DLLfull,"'))"),
             "load( 'All_inputs.RData' )",
             "Obj <- do.call(TMB::MakeADFun, All_inputs)"
             )
    writeLines(txt, paste0(DLL,".R"))
    ## Try running
    Bdg_output <- gdbsource(paste0(DLL, ".R"))
    # Sort out outcomes
    if( length(grep("#0",Bdg_output)) > 0 ){
        message("Model has errors")
        print(Bdg_output)
        stop()
    }
    ## OK ==> Safe to run in main session:
    TMB::MakeADFun(...,DLL=DLL)
}

You could name the package 'TMB-debug'. Now debugging becomes as simple as changing "library(TMB)" to "library(TMB-debug)".

ghost commented 8 years ago

Hello, I'm having about exactly the same problem as the topic starter (although more than a year later....) when running this in R:

compile( "model.cpp", "-O1 -g", DLLFLAGS="")
gdbsource( "model.R" )
"Error in line:length(x) : argument of length 0

So I read the whole conversation, did what kaskr suggested (obtaining basically the same results as njoselson), changed the path and completely uninstalled and reinstalled R, Rtools and TMB several times now, with different options and versions (TMB was installed used either adcomp or Rstudio install packages). I also deinstalled everything that might potentially interfere (ADMB, old Rtools packages). For the moment, I'm running 3.1.3 with Rtools32 to be sure to have a froozen Rtools, and to be closer to the version of the topic starter (but I also tried R3.2.3 with Rtools33). Could anyone please indicate what I'm doing wrong or what I might still try? I launched myself into learning TMB only recently, and it seems highly promissing. But without a debugger I stumble to get my own code running. Here are the outputs of what was previsously already asked:

> fileLocations()
$rhome
[1] "C:\\PROGRA~1\\R\\R-31~1.3"

$rbin
[1] "C:\\PROGRA~1\\R\\R-31~1.3\\bin\\x64"

$rtools
[1] "C:\\Rtools"

$gccbin
[1] "C:\\Rtools\\GCC-46~1.3\\bin"

$gdbbin
[1] "C:\\Rtools\\GCC-46~1.3\\bin64"

shell("PATH") PATH=C:\Program Files\R\R-3.1.3\bin\x64;c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;C:\Rtools\gcc-4.6.3\i686-w64-mingw32\bin;C:\Rtools\gcc-4.6.3\bin64;C:\Program Files (x86)\git\bin;C:\Program Files (x86)\Windows Live\Shared; C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;

> shell("where gdb")
C:\Rtools\gcc-4.6.3\bin64\gdb.exe
> shell("where Rterm")
C:\Program Files\R\R-3.1.3\bin\x64\Rterm.exe

gdbsource("model.R",TRUE) runs gdb, but without output, and Rterm can be found. It might also be of interest to know that in the beginning (when I had the newest R and Rtools installed), I had the error straight away, whereas with the somewhat older version of R and Rtools (well, I think this is the reason) it now takes a long time to get the error, and also forces me to restart Rstudio, and even internet. I hope I provided enough information, and that someone knows what to do! Thank you!

kaskr commented 8 years ago

@Wave9 Your locations of gdb and Rterm look correct - this should work.

Did you remember to re-build model.dll after the installation changes? (You must update the time stamp of model.cpp to re-compile...)
Are you sure your model.cpp has out-of-bounds errors? The output argument of length 0 indicates there is no interesting output from gdb.

ghost commented 8 years ago

Thank you very much for your answer. I rebuild it, but I suppose it is possible that there are out-of-bounds errors (sorry that the answer might be this simple). I was hoping/expecting that this debugger might give more detailed information than what I get from MakeADFun. Thanks again, now I know that the problem is really the model, rather than the installation!

James-Thorson commented 8 years ago

@kaskr I finally got around to following your suggestion above, and have added an R package that overloads compile and MakeADFun:

https://github.com/James-Thorson/TMB-debug

where I imagine it has to be loaded after TMB for it to take precedence in the namespace. I invite people to test it on windows machines. If it seems like its working, we could then transfer it to a "TMB_helper_functions" package maintained on some public site (rather than housing it in my personal repository).

Njoselson commented 8 years ago

Hi All,

Having just switched to a Mac computer running OS X El Capitan, there is only compilation with Clang. This has messed up my debugger which is based on gdb, right? Is there an easy way to change the debugger to use lldb instead?

I tried to change the gdbsource function by replacing gdb with lldb, but this didn't work.

gdbsource <- function(file,interactive=FALSE){
  if(!file.exists(file))stop("File '",file,"' not found")
  if(.Platform$OS.type=="windows"){
    return(.gdbsource.win(file,interactive))
  }
  gdbscript <- tempfile()
  if(interactive){
    gdbcmd <- c(paste("run --vanilla <",file),
                "bt")
    gdbcmd <- paste(gdbcmd,"\n",collapse="")
    cat(gdbcmd,file=gdbscript)
    cmd <- paste("R -d lldb --debugger-args=\"-x",gdbscript,"\"")
    system(cmd,intern=FALSE,ignore.stdout=FALSE,ignore.stderr=TRUE)
    return(NULL)
  } else {
    cat("run\nbt\nquit\n",file=gdbscript)
    cmd <- paste("R --vanilla < ",file," -d lldb --debugger-args=\"-x",
                 gdbscript,"\"")
    txt <- system(cmd,intern=TRUE,ignore.stdout=FALSE,ignore.stderr=TRUE)
    attr(txt,"file") <- file
    class(txt) <- "backtrace"
    return(txt)
  }
}

Running gdbsource with interactive=TRUE, I get the output:

> gdbsource("hake2016.cpp",TRUE)
(lldb) target create "/var/folders/04/0d03dkbn4t759xwjvk3j9rsh0000gn/T//Rtmp3Cg3kO/file5ef1ba7fee4"

But this just freezes my R session and I need to restart it.

If I run it with interactive=FALSE then I get:

> gdbsource("hake2016.cpp")
Error in system(cmd, intern = TRUE, ignore.stdout = FALSE, ignore.stderr = TRUE) : 
  error in running command

Is there any way to make the debugger work on Mac?

Thanks!

Nathaniel

kaskr commented 8 years ago

You probably can't expect the gdb script to work unchanged with lldb. Rather, try to run it from command line (forget about gdbsource):

R -d lldb
run
source("hake1016.R")
bt

Njoselson commented 8 years ago

Perfect solution! Problem solved! Thanks so much.

skaug commented 8 years ago

Hi,

I have come across the "Error in line:length(x) : argument of length 0" when using gdb under windows. I am not able to figure out from this thread if someone has found a fix. If not solved, I have made an observation that may give a clue about where to look.

When I use obj <- MakeADFun(data=list(n=1),parameters=list(x=1)),DLL="tt.dll") I get Error in line:length(x) : argument of length 0 but when I leave out the DLL argument: obj <- MakeADFun(data=list(n=1),parameters=list(x=1))) I get `#0 0x0000000068c9ca38 in abort () from D:\github\adcomp\tmb_examples\tt.dll

2 objective_function::operator() (this=0x440d060) at tt.cpp:11

from D:\github\adcomp\tmb_examples\tt.dll`

which is the way it is supposed to work.

Details about what I have done: compile("tt.cpp","-O1 -g",DLLFLAGS="") gdbsource("tt.R")

tt.cpp:

Type objective_function<Type>::operator() ()
{
  DATA_INTEGER(n);
  PARAMETER(x);
  Type g=0;
  vector<Type> y(10);
  y(-1); // Error!!!!
  return g;
}

tt.R:

library(TMB)
dyn.load(dynlib("tt"))
obj <- MakeADFun(data=list(n=1),parameters=list(x=1)),DLL="tt.dll")

I run under R studio with R version:

platform       x86_64-w64-mingw32                         
arch           x86_64                                     
os             mingw32                                    
system         x86_64, mingw32                            
status         Revised                                    
major          3                                          
minor          2.4                                        
year           2016                                       
month          03                                         
day            16                                         
svn rev        70336                                      
language       R                                          
version.string R version 3.2.4 Revised (2016-03-16 r70336)
nickname       Very Secure Dishes

kaskr commented 8 years ago

?MakeADFun says

DLL: Name of shared object file compiled by user.

The name of the shared object file is in this case 'tt' not 'tt.dll'. (perhaps we need to make the documentation more clear?)

skaug commented 8 years ago

Thanks. Yes maybe it would be good to add: (without the .so or .dll extension)

jlaake commented 8 years ago

For those looking for TMB-debug described above, it is at

`https://github.com/kaskr/TMB_contrib_R/tree/master/TMBdebug

jlaake commented 8 years ago

Oops. A ' got thrown it so clicking on above won't work. Use https://github.com/kaskr/TMB_contrib_R/tree/master/TMBdebug

vtrijoulet commented 7 years ago

Hi,

Sorry for posting on this subject again but I cannot get the debugger to work on my windows machines. I have tried everything on the previous posts with no progress. I also tried the TMBdebug package which, in my case, doesn't prevent the R session from crashing.

Below are some commands and outputs: gdbsource("name.R") Error in line:length(x) : argument of length 0

gdbsource("name.R",TRUE) "C:/PROGRA~1/R/R-33~1.2/bin/x64/Rterm.exe": not in executable format: File format not recognized No symbol table is loaded. Use the "file" command. Breakpoint 1 (abort) pending. C:\Users\VANESS~1.TRI\AppData\Local\Temp\2\RtmpYPNXIN\file217423442d:3: Error in sourced command file: No executable specified, use 'target.exec'.

shell("PATH") PATH=C:/Rtools/bin;C:/Rtools/gcc-4.6.3/bin64;C:/Rtools/gcc-4.6.3/bin;C:/PROGRA~1/R/R-33~1.2/bin/x64;C:\Program Files\R\R-3.3.2\bin\x64;C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;c:\Program Files\ActivIdentity\ActivClient\;c:\Program Files (x86)\ActivIdentity\ActivClient\;C:\Program Files (x86)\Tumbleweed\Desktop Validator\;C:\Program Files (x86)\Google\Chrome\Application;C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Int...

shell("where gdb") C:\Rtools\bin\gdb.exe C:\Rtools\gcc-4.6.3\bin64\gdb.exe

shell("where Rterm") C:\Program Files\R\R-3.3.2\bin\x64\Rterm.exe

Any idea on what could be the problem?

Thanks

kaskr / adcomp

gdbsource Errors #67

2 objective_function::operator() (this=0x440d060) at tt.cpp:11