2

I am working on an R package that contains a binary, compiled from C/C++ code. Something in that compiled code causes random crashes on Windows (7, 64bit), but not on Linux (various systems and configurations). My R version is 2.15.0.

I am not sure how to debug it, since I can't figure out the information given when R crashes:

Problem signature:
  Problem Event Name:   BEX64
  Application Name: Rterm.exe
  Application Version:  2.150.58871.0
  Application Timestamp:    4f75a75a
  Fault Module Name:    StackHash_2264
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp:   00000000
  Exception Offset: 0000000000000000
  Exception Code:   c0000005
  Exception Data:   0000000000000008
  OS Version:   6.1.7601.2.1.0.256.1
  Locale ID:    1037
  Additional Information 1: 2264
  Additional Information 2: 2264db07e74365624c50317d7b856ae9
  Additional Information 3: 875f
  Additional Information 4: 875fa2ef9d2bdca96466e8af55d1ae6e

Can I learn anything from the fact the issue is in the StackHash module?

Some additional information:

  1. As per the R documentation, I ran Valgrind on Linux, and it reported no issues. I tried the "gctorture" feature, but it did not appear to affect the behavior of the bug in any way.

  2. I use pthreads in my code to utilize multicore CPUs. When I disable the use of multithreading (using a preprocessor define that I have), the problem seems to go away, but I can't be sure if this really eliminates the problem, or simply makes it less likely to occur.

  3. I am not using that much memory that should create trouble on the machine I'm using. I also have some recursive calls, but again seems way too little that it would overflow the stack, unless threads get very limited stacks on Windows?

  4. Due to the multithreading randomness, and the low probability of the bug, I am having a very hard time isolating it using prints to the console or log files.

Any pointers would be much appreciated

skauf
  • 95
  • 4

1 Answers1

2

I would load up R in a debugger, and just run it until it crashes, and then see where it's at.

The error is clearly a null-pointer access (0000000000000008 is referencing a NULL) - I'm pretty sure it's not a stack problem.

You should be able to see where it crashes.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • I tried loading it in GDB, but it crashed without GDB capturing it (said something like "inferior process exited"). What is the procedure of properly getting GDB to work with R (+my package DLL) on Windows? (since on Linux the problem does not occur) – skauf Dec 22 '12 at 23:31
  • @skauf Does windbg catch the exception? – Matthew Lundberg Dec 22 '12 at 23:34
  • I would perhaps try using the Windows debugger, windbg - search for "MSDN windbg". This seems like a good description of how to make windbg catch "any crashing application". http://stackoverflow.com/questions/5638251/setup-windbg-as-default-debugger – Mats Petersson Dec 22 '12 at 23:34
  • Windbg does catch the exception as an access violation, but has no symbol information to tell me where it happened. What do I need to do in order to get this info? (at least for my own package's DLL). Does windbg handle multithreaded processes? – skauf Dec 23 '12 at 00:04
  • Windbag should handle mulitple threads, yes. As to symbols, did you build R yourself? If not, you're probably a bit stuck. If you can build your own version, then you should have symbols. It's also possible that you simply have to tell windbg where the symbols are! Not the best laid out site I've ever seen, but tells you how to set symbol path, if that's what's the problem - but if you don't have a ".pdb" file, then you need to build from sources or obtain a .pdb from the person(s) that bult your version [make sure it matches, or you'll be worse off than without symbols] – Mats Petersson Dec 23 '12 at 00:14
  • @MatsPetersson: R is built with the MinGW version of gcc. The Windows debugger will not help. – Dirk Eddelbuettel Dec 23 '12 at 00:47
  • @skauf: Use gcc and gdb from MinGW, make sure you build -d. There is a section in "Writing R Extensions" about debugging dynamic modules. – Dirk Eddelbuettel Dec 23 '12 at 00:48
  • Or even -g for "debug symbols"? – Mats Petersson Dec 23 '12 at 00:51
  • Sorry yes, typo. Meant to say '-g'. – Dirk Eddelbuettel Dec 23 '12 at 03:12
  • Post-mortem: I now believe debugging in GDB in my case was difficult because the problem was being caused by a very rare bug in the pthreads implementation that came with RTools/Win64, that appears at random somewhere during the creation and starting of a new thread (causing the starting function for the thread to be a null pointer even though the argument to pthread_create is a pointer to a static function). Thanks for the helpful suggestions. – skauf Dec 25 '12 at 11:23
  • Excellent news. Always good to knock a difficult bug on its head! And thanks for actually telling us. It happens far too often that you get no feedback on these things. – Mats Petersson Dec 25 '12 at 12:14