Oscar_Huang

@Philipp A Hartmann, is there any update on this? Thanks.

@Philipp A Hartmann, For workaround, removing/skipping the asert in sc_cor_qt.cpp is sufficient. Changes made in sc_simcontext.cpp is for debugging the issue. In my simple example for reproducing the issue, the makefile explicitly used the the static library. So it doesn't matter if --enable-shared=no is used or not. To reproduce the issue with the examples coming with the systemc package, you have to use --enable-shared=no to reproduce the issue because otherwise the shared library will be used. The errno is 13 (EACCES 13 Permission denied) I had tried posix

No problem. And thanks for following up this issue. Pls let me know once a fix is available.

The issue is with only the static library libsystem.a. If you use the shared library, there is no problem. My example used libsystem.a If you configure it with option -enable-shared=no, and rebuild, then "make check" will fail with exactly the same assert error as seen with my example. Here is my test log file: 1 ================================================= 2 SystemC 2.3.3: examples/sysc/test-suite.log 3 ================================================= 4 5 # TOTAL: 22 6 # PASS: 21 7 # SKIP: 0 8 # XFAIL: 0 9 # FAIL: 1 10 # XPASS: 0 11 # ERROR: 0 12 1

My steps to build SystemcC library: 1. Downloaded the systemc package 2. untar it to systemc-2.3.3 3. cd to systemc-2.3.3 4. mkdir objs 5. mkdir target_dir 6. cd to objs 7. run ../configure --enable-debug --disable-optimize --with-unix-layout --prefix=../target_dir 8. make -j16 9. make install I ran make check, and all tests passed.

I checked the /proc/<pid/maps file of my example program. Most of the memory segments have "x" flag: 1 00400000-0045f000 r-xp 00000000 fd:02 557832807 /home/ohuang/data/software/mpfail/systemc-2.3.3/SystemC/examples/mini/mini_fail.x 2 0065f000-00661000 r-xp 0005f000 fd:02 557832807 /home/ohuang/data/software/mpfail/systemc-2.3.3/SystemC/examples/mini/mini_fail.x 3 00661000-00665000 rwxp 00061000 fd:02 557832807 /home/ohuang/data/software/mpfail/systemc-2.3.3/SystemC/examples/mini/mini_fail.x 4 00665000-00

Once correction to my first post: to toggle the failure, in addition to commenting out the SC_REPORT_FATAL call in the macro definition of SC_API_PERFORM_CHECK_ in sysc/kernel/sc_ver.cpp, the exception handling code in sc_elab_and_sim() function also needs to be commented out. I did it like this: 80 try 81 { 82 pln(); 83 84 // Perform initialization here 85 sc_in_action = true; 86 87 // copy array of pointers to keep allocated pointers for later release 88 std::vector<char*> argv_call = argv_copy; 89 status = sc_main(

I did one more experiment. If you examine the p values: Customer sc_main called mprotect check done at 50: ret: 0, errno: 0, p: 0x7f404a099010, redzone: 0x7f404a09a000 @@@@ mprotect check pass at Line 50 mprotect check done at 51: ret: -2, errno: 13, p: 0x214cbe0, redzone: 0x214d000 It looks like if p was allocated at the upper end of the address space (where p is 0x7f404a099010) , the test can pass. If p was allocated at the lower end (where p is 0x214cbe0), the test fails. To confirm this, I changed the sz variable to a smaller value: 4096*2. Then I found the first CHECK_MPROTE

Hi, Roman, Yes, if I comment-out assert in stack_protect function in SystemC kernel, my application works fine. I printed values of p, but not sure how to tell if they are overlapped with BSS area.

Thanks for trying my example, Roman. The original issue was the assert failure at Line 109 in file sysc/kernel/sc_cor_qt.cpp: int ret; // Enable the red zone at the end of the stack so that references within // it will cause an interrupt. if( enable ) { ret = mprotect( redzone, pagesize - 1, PROT_NONE ); } // Revert the red zone to normal memory usage. Try to make it read - write - // execute. If that does not work then settle for read - write else { ret = mprotect( redzone, pagesize - 1, PROT_READ|PROT_WRITE|PROT_EXEC);

Hello, Roman, Sorry for the confusion. Yes, I had modified the kernel (sc_main.cpp) by adding two lines of CHECK_MPROTECT function call in the main function, just to confirm if the failure could happen even earlier. And of course, this is a SystemC by Accellera. The reason of using extern "C" for the sc_main function is, I didn't include header systemc in my c++ source file. Actually sc_main is declared as extern "C" in sysc/kernel/sc_externs.h. I reproduced the issue on Centos 8 as well. If I copy the same built binary to Ubuntu 18, it run through without any problem.

Anybody used SystemC on Centos 7?

First of all, how to report a bug to Accellera? Recently I ported one of our old model to Centos 7. The building was fine. When running it, I got this error during initialization stage: ../../../../src/sysc/kernel/sc_main.cpp:55: int Check_mprotect(void*, size_t, int): Assertion `ret == 0' failed. Aborted (core dumped) After days of debugging, I managed to narrow down the problem to SystemC itself. And I can reproduce the failure with a very simple program as below: #include <sys/mman.h> #include <sys/types.h> #include <errno.h> #include <stdio.h>