Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash on ck_assert_int_eq when false #75

Closed
hqbrice opened this issue Nov 10, 2016 · 8 comments
Closed

Crash on ck_assert_int_eq when false #75

hqbrice opened this issue Nov 10, 2016 · 8 comments

Comments

@hqbrice
Copy link

hqbrice commented Nov 10, 2016

Hello,
I'm writting a simple test with ck_assert_int_eq and this crashes when tests is failed :
START_TEST (test_int_assert) {
fprintf(stdout, "test_int_assert starting...\n");fflush(stdout);
int exp = 0;
int actual = 1;

fprintf(stdout, "Before assert 1...\n");fflush(stdout);
ck_assert_int_eq(actual-1, exp);
fprintf(stdout, "Before assert 2...\n");fflush(stdout);
ck_assert_int_eq(actual, exp);

fprintf(stdout, "test_int_assert finnish !\n");fflush(stdout);

}
END_TEST

When I run .exe test, I see on console the first three fprintf and Windows display error message "programm stopped working"...

I compiled the Framework with gcc 64bits on the same Windows.

Thanks

@brarcher
Copy link
Contributor

I have a few questions to help me understand your setup.

I compiled the Framework with gcc 64bits on the same Windows.

Can you give further details on your build setup? Are you using MinGW to get gcc for Windows, or something else?

Are you able to compile and run Check's own unit tests using your toolchain and see if they can run successfully?

Are you able to run the unit testing program you are developing in a debugger to see where the failure occurs?

@hqbrice
Copy link
Author

hqbrice commented Nov 15, 2016

Can you give further details on your build setup? Are you using MinGW to get gcc for Windows, or something else?

I use a gcc produced by makeinfo version 4.11 and the Code::blocks program.
This is the console log after build :
x86_64-pc-mingw32-g++.exe -shared -Wl,--output-def=..\..\project\bin\libCheck.def -Wl,--out-implib=..\..\project\bin\libCheck.a -Wl,--dll obj\Release\check.o obj\Release\check_error.o obj\Release\check_list.o obj\Release\check_log.o obj\Release\check_msg.o obj\Release\check_pack.o obj\Release\check_print.o obj\Release\check_run.o obj\Release\check_str.o -o ..\..\project\bin\libCheck.dll -s Creating library file: ..\..\project\bin\libCheck.a Output file is ..\..\project\bin\libCheck.dll with size 29.00 KB

Are you able to compile and run Check's own unit tests using your toolchain and see if they can run successfully?

Not directly. I have to modify files to make it works. And I have to take a time for this. For example clockid_t doesn't exist on our compiler...

I do not use any debugger. I can join my test.exe and check compiled as a library

@brarcher
Copy link
Contributor

I've not used Code::blocks before. Check currently is tested to work against MinGW and Visual Studios, and is known to work also against Cygwin. Getting Check to build for those platforms goes through CMake or Autotools. My understanding from looking online is that CMake can generate Makefiles for Code::blocks:

https://cmake.org/cmake/help/v3.0/generator/CodeBlocks.html

CMake performs some checks on the platform and will enable/disable certain features based on what it finds. You may find that the Makefiles generated by CMake can build Check without any additional modification. If that is not the case, contributions to the CMake setup in Check are welcome if you are up for getting CMake to work with Code::blocks.

@hqbrice
Copy link
Author

hqbrice commented Nov 17, 2016

I asked for help from a colleague to ask you.
So it seems there is a bug into the Framework for test doens't crash thanks to him. Here its modifications :
in check.c line 302, crash on vsnprintf.

Incheck-0.10.0/CMakeLists.txt, comment :
#check_function_exists(snprintf HAVE_SNPRINTF)
#check_function_exists(vsnprintf HAVE_VSNPRINTF)
#check_function_exists(vasnprintf HAVE_VASNPRINTF)
#check_function_exists(asprintf HAVE_ASPRINTF)
#check_function_exists(vasprintf HAVE_VASPRINTF)

In check-0.10.0/src/ CMakeLists.txt
Modify location by absolute path

set(LIBCOMPAT C:/Transfert/check-0.10.0/lib/libcompat.a)
and add ${LIBCOMPAT} after :
target_link_libraries(check ${LIBM} ${LIBRT} ${SUBUNIT} )

I hope this can help you to improve your good Framework

Is there provision for add some assertions ?
For Strings, I use char* whithout the '\0' end of string and, tests crashes too because of memory overrun. I bypassing this by modify the string before. But use a assertion by giving the lenth of the string would be a better solution.

@brarcher
Copy link
Contributor

For Strings, I use char* whithout the '\0' end of string and, tests crashes too because of memory overrun.

There will be several new macros which will allow one to check memory contents, for example ck_assert_mem_eq(X, Y, L) will check that two memory regions X and Y are equal to a length L. It sounds like these macros will help. As there has not yet been a release with these macros, you are welcome to take the master branch on git and try it out and give feedback.

As for your crash, are you able to generate Makefiles using CMake for Code::blocks? If so, is CMake not able to detect the platform correctly and thus configures Check incorrectly, leading to a crash (SIGSEGV?) in vsnprintf?

Not all platforms have a suitable implementation of the *printf functions, so on these platforms a version of these functions packaged with Check is used. Can you provide the output of CMake, as well as the CMakeCache.txt file generated by CMake if it exists. That may help in determining what CMake decided for your platform.

@hqbrice
Copy link
Author

hqbrice commented Nov 19, 2016

Use Code::Blocks was a way for me to compile the Framework because C language is not my specialty. My colleague generated a Makefile for make for me. I can provide you CMakeCache.txt file generated by CMake.

@brarcher
Copy link
Contributor

brarcher commented Jan 5, 2017

Someone reported a similar issue, that may be the same issue, in #107. They observed that the issue is resolved in Check 0.11.0. Might you check if the crash is no longer reproducible in Check 0.11.0?

@brarcher
Copy link
Contributor

This issue is believed to be solved in release 0.11.0. If it is not, please re-open the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants