Skip to content

Segmentation fault not catched #2

Description

@FabrizioSandri

I was trying to run RcppDeepState on the test package provided in the /inst/testSAN on a different machine.

First of all I ran the test harness compilation procedure deepstate_harness_compile_run and it succesfully generated the compiled test harness. After that I ran the deepstate_harness_analyze_pkg function and no matter how many times I ran the function, no bug was reported for the testSAN package.

After some investigation, I discovered that no output file was generated for each Test Harness. For example: the output folder for rcpp_use_after_deallocate function located at testSAN/inst/testfiles/rcpp_use_after_deallocate/rcpp_use_after_deallocate_output was empty. So I attempted to run the Test Harness execution manually. What I discovered is that before the output file is generated, the Test Harness gives me a segmentation failure error.

./rcpp_use_after_deallocate_DeepState_TestHarness --seed=5 --timeout=2 --fuzz --fuzz_save_passing --output_test_dir rcpp_use_after_deallocate_output 

[1]    167004 segmentation fault (core dumped)  ./rcpp_use_after_deallocate_DeepState_TestHarness --seed=5 --timeout=2 --fuzz -fuzz_save_passing --output_test_dir rcpp_use_after_deallocate_output 

Is there something I'm overlooking? The program appears to crash in the try-catch block, without actually catching the error.

TEST(,){
  RInside R;
  std::cout << "input starts" << std::endl;
  IntegerVector array_size(1);
  array_size[0]  = RcppDeepState_int();
  qs::c_qsave(array_size,"/home/fabri/test/testHarness/RcppDeepState/inst/testpkgs/testSAN/inst/testfiles/rcpp_use_after_deallocate/inputs/array_size.qs",
		"high", "zstd", 1, 15, true, 1);
  std::cout << "array_size values: "<< array_size << std::endl;
  std::cout << "input ends" << std::endl;
  try{
    rcpp_use_after_deallocate(array_size[0]);
  }
  catch(Rcpp::exception& e){
    std::cout<<"Exception Handled"<<std::endl;
  }
}

Executing the test on a different machine works perfectly: it catches the errors and saves the test case in the output directory.
@Anirban166 have you ever dealt a situation like this with DeepState?

Activity

  1. Anirban166 commented on Jun 4, 2022

    @Anirban166

    I haven't, but then I have never dealt with RcppDeepState in the past as well. I know of a few common situations with DeepState where you aren't properly compiling the Test Harness (like simply appending the option to explicitly link the library using -ldeepstate) or executing the binary produced thereafter, but those appear to not be the case here.

    From what I can grasp of the situation, I'd suggest to check the configurations of the machines you are running on (assuming this worked liked you said in one machine, otherwise if it didn't I'd run Valgrind and debug for accesses. And if it is segfaulting, there would be no output file yes). And from what you mentioned, I can't tell what system this is being run on or what's the other 'different machine' that it worked on, but there could be noticeable inconsistencies across platforms.

  2. FabrizioSandri commented on Jun 4, 2022

    @FabrizioSandri
    OwnerAuthor

    Finally, I came up with something interesting: the output files are now created, and Valgrind produces an xml output file. However, the references (line number) to the original C++ code are missing from this file. It appears that the tested function's shared object file has been stripped: Valgrind only prints that the error problem arises from the shared obejct, without actually printing the source of the error in the shared object. The RcppDeepState XML parser then is'nt able to understand the output. This appears to be the reason for RcppDeepState reporting an empty table.

    I'm going to explore a little more into this. Thanks @Anirban166 !

  3. Anirban166 commented on Jun 4, 2022

    @Anirban166

    Anytime, good to see you exploring!

  4. FabrizioSandri commented on Jun 6, 2022

    @FabrizioSandri
    OwnerAuthor

    I've finally figured out the answer! The issue was that the library's shared object was built without the -g option.
    The shared object required this even if the test harness was compiled with debugging symbols.

    Solved in #3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions