I am getting a segmentation fault when I try running gtest by mocking a method that accepts pointer to a object as the argument. I identified the mock method that is creating the trouble.
class NvmControllerMockApp : NvmController_API
{
public:
MOCK_METHOD1(registerAccessor, bool(NVM_Accessor *accessor));
MOCK_METHOD0(update, void());
}
This is the o/p produced by gtest:
Running main() from gmock_main.cc
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from MeterTamperAppTest
[ RUN ] MeterTamperAppTest.NeutralDisturbanceCheck
Segmentation fault (core dumped)
The MOCK_METHOD1 is what is creating the segmentation fault. If that method is excluded from the file that is to be tested then things seem to work fine. As a word of caution the NVM_Accessor class deals with some pointers. I have tried debugging the error using GDB and the following is the backtrace message at the point of segmentation fault :
Program received signal SIGSEGV, Segmentation fault.
0x00000000004168d3 in testing::internal::UntypedFunctionMockerBase::UntypedInvokeWith (this=0x67f188, untyped_args=0x7fffffffdca0)
at ../src/gmock-spec-builders.cc:363
363 this->UntypedDescribeUninterestingCall(untyped_args, &ss);
(gdb) backtrace
#0 0x00000000004168d3 in testing::internal::UntypedFunctionMockerBase::UntypedInvokeWith (this=0x67f188, untyped_args=0x7fffffffdca0)
at ../src/gmock-spec-builders.cc:363
#1 0x0000000000410fc9 in testing::internal::FunctionMockerBase<bool (NVM_Accessor*)>::InvokeWith(std::tr1::tuple<NVM_Accessor*> const&) (
this=0x67f188, args=...) at /home/sudeep/GramPower/gmock-1.7.0/include/gmock/gmock-spec-builders.h:1530
#2 0x0000000000410c56 in testing::internal::FunctionMocker<bool (NVM_Accessor*)>::Invoke(NVM_Accessor*) (this=0x67f188, a1=0x67f148)
at /home/sudeep/GramPower/gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h:97
#3 0x000000000041076f in NvmControllerMockApp::registerAccessor (this=0x67f180, gmock_a1=0x67f148)
at /home/sudeep/GramPower/gpos_fw/gpos/apps/nvm_controller/mocks/nvm_controller_mock_app.h:26
#4 0x0000000000413470 in MeterTamperApp::MeterTamperApp (this=0x67f128, env_=0x67ee90) at apps/meter_tamper/meter_tamper_app.cpp:31
#5 0x0000000000410989 in MeterTamperAppMockEnvironment::MeterTamperAppMockEnvironment (this=0x67ee90)
at apps/meter_tamper/tests/../mocks/meter_tamper_app_mock_environment.h:23
#6 0x0000000000410a3e in MeterTamperAppTest::MeterTamperAppTest (this=0x67ee80) at apps/meter_tamper/tests/meter_tamper_app_dtest.cpp:30
#7 0x0000000000410b10 in MeterTamperAppTest_NeutralDisturbanceCheck_Test::MeterTamperAppTest_NeutralDisturbanceCheck_Test (this=0x67ee80)
at apps/meter_tamper/tests/meter_tamper_app_dtest.cpp:36
I had a similar issue - segmentation fault on instantiation of mock classes. I build gmock and gtest as static libraries.
The problem has been solved by passing the -Dgtest_disable_pthreads=OFF option to cmake.
Hope this will help someone else.
The solution is quite easy: Use the current git version.
Related comments and what was wrong with the 1.7.0 version of gmock can be found here:
gcc 6.1.0 segmentation fault - gcc bug?
and the bug report for google test can be found here:
https://github.com/google/googletest/issues/705
The last link also provides a fix which can be merged into 1.7.0 without checking out the current git repo.
Probably your object files were generated wrong. Remove all object files and compile from scratch.
I faced the same issue.
In my case this happened because "EXPECT_EQ" is not interrupted test execution:
std::vector<int> ret = some_call(); //here the empty vector intializing "ret"
EXPECT_EQ(ret.size(), 1); //here is failure
EXPECT_EQ(ret[0], expectedResult); //here is segmentation. Author expected test termination one line above
.. I'm going to dive deep into gtest docs..
Related
The program(C++) I am working on is for Service proxy. It is using AsyncGenericService of grpc in its implementation. The program is crashing(segmentation fault) just after calling the RequestCall() method.
Some pieces of code lines are follows:
::grpc::AsyncGenericService service_; // a member variable
auto req = std::make_shared<Request>(); // Request is a struct with context and stream members
service_.RequestCall(&req->getContext(), &req->getStream(), cqueue_.get(), cqueue_.get(), tag); // the program is giving seg fault at this line
Attempt:
I eliminated the possibility that a buggy service to be proxied is causing this.
I am wondering how to proceed debugging after that. As the RequestCall() is inside GRPC, so I want to ask what would be the next step of getting closer to the bug.
Update:
The stacktrace is aligned with the observed crash. As you can see in the frame-1 it is calling the RequestCall(). Below the frame 1, it is program internal functions.
(gdb) bt
#0 0x00007ffff37c61c6 in grpc::ServerInterface::GenericAsyncRequest::GenericAsyncRequest(grpc::ServerInterface*, grpc::GenericServerContext*, grpc::internal::ServerAsyncStreamingInterface*, grpc_impl::CompletionQueue*, grpc_impl::ServerCompletionQueue*, void*, bool) () from /opt/third/grpc/1.28.1/lib/libgrpc++.so.1
#1 0x00007ffff37b58c5 in grpc::AsyncGenericService::RequestCall(grpc::GenericServerContext*, grpc_impl::ServerAsyncReaderWriter<grpc::ByteBuffer, grpc::ByteBuffer>*, grpc_impl::CompletionQueue*, grpc_impl::ServerCompletionQueue*, void*) ()
from /opt/third/grpc/1.28.1/lib/libgrpc++.so.1
Having a callstack for the crash would be helpful to see what's going wrong.
I have a program with a large codebase, so I can't share a minimal example. What I've done is removed everything from main so that it looks like this:
int main()
{
std::cout << "here" << std::endl;
return 0;
}
But I'm still including all of the header that I was including before. When I run the debugger (GDB 9.2) it breaks before hitting main (I've a breakpoint set on the std::cout) with the following:
Starting debugger: C:\GameDev\Tools\MSYS2-32\mingw32\bin\gdb.exe -nx -fullname -quiet -args C:/GameDev/Colony/bin/Colony.exe
done
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 9.2
Child process PID: 6840
In ?? () ()
Which I understand means something has happened during initialisation? I looked at this question Debug error before main() using GDB and did as suggested, printed the info file info file and set a breakpoint manually on the entry point and running it again. That doesn't seem to give me any additional info (same as above); or maybe I don't know what I'm looking for and how to retrieve it.
I've tried running the program through Dr Memory but it seems to execute okay in there, up until shutdown at which point after leaving Dr Memory gives me no errors but 2 suspected false positives. Both of these look like they're pointing to MingW hashtable code, which I believe is from my use of std::unordered_map in a few places (the only place where that hashtable code would come in). But none of that code is invoked because main is effectively empty.
None of that code is statically initialised either.
So, what sort of things can cause this error? I can try and track down the offending code if I know what can do it.
So I`m writing an application for an embeded system (Linux on ARM) and everything works fine, until I decide to add one more class at the start of a main function. It looks like this (can not post the actual code here):
int main ()
{
Someclass class1;
....
}
And after that application just return code 1 (generic error) right from the start. If I remove it - everything is fine again. To me it looks like I ran out of stack space - but in that case system should throw a SIGSEV or SIGSTKFLT. But there was nothing just error code 1. I tried to get stderr like that:
./app 2> error.log
But there was also nothing.
Tried to debug using remote gdb:
Client:
Cannot access memory at address 0x3030204
Cannot access memory at address 0x3030200
Server:
Remote debugging from host xxxxxx
readchar: Got EOF
Remote side has terminated connection.
Details:
I`m wirting on C++11 (TR1) (project-specific), compile with GCC 4.4.6 (also project-specific), debug with GDB 7.4
Solved
Big thanks to everyone who responded, I have managed to solve this, and it was my fault - I did not initialized device`s libraries correctly before calling a wrapper class (later they were initialized and thus it worked). Thank you all again.
The most obvious place to look would be in the class' constructor which is being called on invocation of main.
I will below describe the error that I get when calling the function sscanf.
Some of my code:
#include <cstdio>
(..)
int device_num = 0;
int frameTime = sscanf(currentStringVector[2].c_str(), "%d", &device_num);
It is part of a module of OmNet++, so I compile it using OmNet++ .
I get the following error message in GDB:
"Program received signal SIGSEGV, Segmentation fault.
__rawmemchr_sse2 () at ../sysdeps/x86_64/multiarch/../rawmemchr.S:31
31 ../sysdeps/x86_64/multiarch/../rawmemchr.S: Filen eller katalogen finns inte.
in ../sysdeps/x86_64/multiarch/../rawmemchr.S"
The problem started to incur when I called sscanf.
I am running the program in Ubuntu on a 64-bits system.
How do I resolve the above problem?
Thanks!
With OMNeT++, you can use a debugger like gdb when running your program from the command line. The IDE also lets you debug your code.
My guess is that currentStringVector[2].c_str() is not valid. Maybe the vector is smaller than that.
I´m new to C++ programing. I am compiling a Windows Application which compiles ok with just a few warnings, but when I launch it, it doesn´t even seem to start and returns an Access Violation 3 seconds into the run. When I try to debug it doesn´t even seem to get into the code, so I don´t know where to start looking for the problem.
Here is the info I have been able to retrieve from the debugger:
Building to ensure sources are up-to-date
Build succeeded
Selecting target:
Debug
Adding source dir: C:\Documents and Settings\Christian Ekiza\Mis documentos\My Dropbox\Private Files\coding\juego_pruebas_01\juego_pruebas_01\
Adding source dir: C:\Documents and Settings\Christian Ekiza\Mis documentos\My Dropbox\Private Files\coding\juego_pruebas_01\juego_pruebas_01\
Adding file: bin\Debug\juego_pruebas_01.exe
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.8
Child process PID: 3328
Program received signal SIGSEGV, Segmentation fault.
In ?? () ()
and this is from the Call Stack
#0 00000000 0x000154e4 in ??() (??:??)
#1 00409198 __cmshared_create_or_grab() (../../../../gcc-4.4.1/libgcc/../gcc/config/i386/cygming-shared-data.c:140)
#2 00000000 0x0040131b in __gcc_register_frame() (??:??)
#3 00000000 0x0040a09b in register_frame_ctor() (??:??)
#4 00000000 0x00408f42 in __do_global_ctors() (??:??)
#5 00000000 0x00401095 in __mingw_CRTStartup() (??:??)
#6 00000000 0x00401148 in mainCRTStartup() (??:??)
And the CPU Registers end with a
'gs' register with a hex value '0x0'
I don't really know where to start looking for the problem. Anyone can help me out or point me in the right direction?
Note: I am using Code::Blocks
As you say it is a Windows application. Then, any issues with startup, I have found ADPlus very useful.
EDIT 2:
You may also check User Mode Process Dumper if ADPlus does not apply
See, if you have some global instance(s) of class with constructor - if error is raised in constructor and class is declared globally (bad thing to do btw) - you'll get sigsegv even before main().
If you have such classes - try to refactor your code to have them inside main (or other function) - it will be easier to debug.
Try the following free MS tools - both are great for debugging this kind of problem.
Application Verifier http://www.microsoft.com/downloads/en/details.aspx?familyid=c4a25ab9-649d-4a1b-b4a7-c9d8b095df18&displaylang=en
Gflags from Debugging Tools for Windows http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6b6c21d2-2006-4afa-9702-529fa782d63b&displaylang=en
Sounds to me like one of your DLL dependencies can't be loaded or instantiated correctly.
Did you you compile with debug mode (-g) enabled?
Also seriously consider actually fixing the warnings. Most of the time they are actual problems in the code that should be resolved.
You should also try to see if this happens with a nearly empty main (comment out most/all of your code in main).