Debugging on mac

85 views
Skip to first unread message

Samuel Johnson

unread,
Sep 24, 2021, 11:55:52 AM9/24/21
to TMB Users

Hi friends,

What are other Mac users using to debug their TMB models?

I'm experiencing issues where all my TMB debugging tools on mac are no longer working. I previously used lldb via

R -d lldb

which gave me back line numbers and informative error messages. Since sometime in the last year, the line numbers have stopped being returned but the error messages were still somewhat informative. Now, just this morning, the debugger refuses to run an R instance, which I understand is common. I've turned off System Integrity Protection, so it's not that.

I am installing gdb now, but from the fora I've read this is possibly going to have a similar end result.

Any guidance on how mac users are debugging would be appreciated. I know I can comment lines of code to find the issue, but I really hate that approach and it's quite cumbersome for models of higher complexity that take a long time to compile.

Thanks
Sam

======

Output from sessionInfo():

R version 4.0.2 (2020-06-22)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Catalina 10.15.7

Matrix products: default
BLAS:   /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib

locale:
[1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] devtools_2.4.2 usethis_2.0.1

loaded via a namespace (and not attached):
 [1] magrittr_2.0.1    pkgload_1.2.1     R6_2.5.1          rlang_0.4.11     
 [5] fastmap_1.1.0     tools_4.0.2       pkgbuild_1.2.0    sessioninfo_1.1.1
 [9] cli_3.0.1         withr_2.4.2       ellipsis_0.3.2    remotes_2.4.0    
[13] rprojroot_2.0.2   lifecycle_1.0.0   crayon_1.4.1      processx_3.5.2   
[17] purrr_0.3.4       callr_3.7.0       fs_1.5.0          ps_1.6.0         
[21] testthat_3.0.4    memoise_2.0.0     glue_1.4.2        cachem_1.0.6     
[25] compiler_4.0.2    desc_1.3.0        prettyunits_1.1.1

Samuel Johnson

unread,
Sep 24, 2021, 1:26:23 PM9/24/21
to TMB Users
Just a small update.

I re-installed R using a tarball binary following instructions here:


It has allowed me to run lldb, but now I am back to getting error messages, but no lines in the source code cpp. Instead, it just points me to the compiled .so object. See example output below.

I think maybe I should compile with some flags for easier debugging, as in another post here, but the "g" and "g1" flags don't work. My system uses clang as a compiler, perhaps I need to change the makevars?

Thanks
Sam

=====
Example bt output:
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff6ac3633a libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff6acf2e60 libsystem_pthread.dylib`pthread_kill + 430
    frame #2: 0x00007fff6abbd808 libsystem_c.dylib`abort + 120
    frame #3: 0x000000014bc076c5 SISCAL.so`Eigen::DenseCoeffsBase<Eigen::Array<double, -1, 1, 0, -1, 1>, 1>::operator()(long) + 133

Samuel Johnson

unread,
Sep 24, 2021, 1:30:15 PM9/24/21
to TMB Users
I found my problem. I should be putting the "-" in the flag, i.e.

compile("SISCAL.cpp", flags = "-g")

This has given me the desired output with source code lines, copied below.

For those who find this later, and are having issues debugging with lldb on a mac, if you can't piece it together from this thread then feel free to reach out. I will attempt to use gdbsource() another day.

Sam

=====
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff6ac3633a libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff6acf2e60 libsystem_pthread.dylib`pthread_kill + 430
    frame #2: 0x00007fff6abbd808 libsystem_c.dylib`abort + 120
    frame #3: 0x000000014c2bf6c5 SISCAL.so`Eigen::DenseCoeffsBase<Eigen::Array<double, -1, 1, 0, -1, 1>, 1>::operator(this=0x00007ffeefbf8058, index=3)(long) at DenseCoeffsBase.h:425:7
    frame #4: 0x000000014c17c7d5 SISCAL.so`objective_function<double>::operator(this=0x00007ffeefbfa2a8)() at SISCAL.cpp:1526:52
Reply all
Reply to author
Forward
0 new messages