
Oscar_Huang
Members-
Content Count
13 -
Joined
-
Last visited
About Oscar_Huang
-
Rank
Member
-
@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?
-
Oscar_Huang joined the community
-
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>