And a correction, I ran it again on Ubuntu 18.04, and I reproduce without Ruby as well.
So it is not a Ruby bug. We need to trace it with --debug-flags ExecAll,SyscallBase and try to understand what is going on. ________________________________ From: Rafael Pintar Alevato <rpa.alev...@gmail.com> Sent: Wednesday, November 13, 2019 5:38 PM To: Ciro Santilli <ciro.santi...@arm.com> Cc: gem5-users@gem5.org <gem5-users@gem5.org> Subject: Re: [gem5-users] Bug when using mutex in ARM SE Hi Santilli, thanks for the response! I'm on commit 70bfe7aa57c3fac79433bfdfb1c6732996bfc727 and I have the error with both std::mutex and pthread mutex. The patch you mentioned is already applied on my version, so it does not solve the issue. Programs that doesn't use mutex don't present any problems. Does anyone have an idea of what could be done to solve the problem with Ruby? Em ter, 12 de nov de 2019 às 20:40, Ciro Santilli <ciro.santi...@arm.com<mailto:ciro.santi...@arm.com>> escreveu: Oi Rafael, Thanks for the detailed report. I don't think there is any advantage of using the pthread library currently, at least on ARM. I reproduce on e96ccec8159f91d60bed8342184fb969b06eaf4f Ubuntu 19.04, but only with Ruby. Without Ruby and everything else the same, it works. What makes you think that this is a syscall deadlock bug rather than a Ruby bug, considering that the error message "panic: Page table fault when accessing virtual address 0" suggests a memory error? Worth noting that there was a more or less recent SE deadlock ARM fix at: https://gem5-review.googlesource.com/c/public/gem5/+/21606 ________________________________ From: gem5-users <gem5-users-boun...@gem5.org<mailto:gem5-users-boun...@gem5.org>> on behalf of Rafael Pintar Alevato <rpa.alev...@gmail.com<mailto:rpa.alev...@gmail.com>> Sent: Tuesday, November 12, 2019 7:32 PM To: gem5-users@gem5.org<mailto:gem5-users@gem5.org> <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: [gem5-users] Bug when using mutex in ARM SE Hello everyone! I'm trying to use a program that uses mutex, but it was entering in deadlock. It was using standard mutex and not pthread library, so first I tried changing it to the pthread mutex. It was still entering in deadlock. After this I cloned a new clean gem5 and compiled it to run some tests. After running the standard tests for pthreads in ARM 64 I had some bugs. Full gem5 output below. Does anyone know if I can fix this? Thank you in advance, Rafael Alevato. Stats: OS: Linux Mint 18.1 Serena Kernel: 4.4.0-53-generic g++: 5.4.0 aarch64-linux-gnu-g++: 5.4.0 gem5 Compiling Command Line: scons build/ARM/gem5.opt CXX=g++ RUBY=True PROTOCOL=MOESI_CMP_directory -j4 Pthread Tests Compiling Command Line: make -f Makefile.aarch64 Execution Command Line: build/ARM/gem5.opt configs/example/se.py -n 16 --cpu-type DerivO3CPU --mem-size 4GB --ruby --l1d_assoc=4 --l1i_assoc=4 --l2_assoc=16 --cacheline_size 64 --l1i_size 64kB --l1d_size 64kB --l2_size 4MB --cmd pthread-tests-aarch64/test_pthread_mutex gem5 Output: gem5 Simulator System. http://gem5.org gem5 is copyrighted software; use the --copyright option for details. gem5 compiled Nov 12 2019 15:50:50 gem5 started Nov 12 2019 16:21:56 gem5 executing on eda01, pid 17621 command line: build/ARM/gem5.opt configs/example/se.py -n 16 --cpu-type DerivO3CPU --mem-size 4GB --ruby --l1d_assoc=4 --l1i_assoc=4 --l2_assoc=16 --cacheline_size 64 --l1i_size 64kB --l1d_size 64kB --l2_size 4MB --cmd pthread-tests-aarch64/test_pthread_mutex Global frequency set at 1000000000000 ticks per second warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (4096 Mbytes) 0: system.remote_gdb: listening for remote gdb on port 7000 0: system.remote_gdb: listening for remote gdb on port 7001 0: system.remote_gdb: listening for remote gdb on port 7002 0: system.remote_gdb: listening for remote gdb on port 7003 0: system.remote_gdb: listening for remote gdb on port 7004 0: system.remote_gdb: listening for remote gdb on port 7005 0: system.remote_gdb: listening for remote gdb on port 7006 0: system.remote_gdb: listening for remote gdb on port 7007 0: system.remote_gdb: listening for remote gdb on port 7008 0: system.remote_gdb: listening for remote gdb on port 7009 0: system.remote_gdb: listening for remote gdb on port 7010 0: system.remote_gdb: listening for remote gdb on port 7011 0: system.remote_gdb: listening for remote gdb on port 7012 0: system.remote_gdb: listening for remote gdb on port 7013 0: system.remote_gdb: listening for remote gdb on port 7014 0: system.remote_gdb: listening for remote gdb on port 7015 **** REAL SIMULATION **** info: Entering event queue @ 0. Starting simulation... warn: Replacement policy updates recently became the responsibility of SLICC state machines. Make sure to setMRU() near callbacks in .sm files! warn: ignoring syscall set_robust_list(...) warn: ignoring syscall rt_sigaction(...) warn: ignoring syscall rt_sigaction(...) warn: ignoring syscall rt_sigprocmask(...) (further warnings will be suppressed) info: Increasing stack size by one page. warn: ignoring syscall mprotect(...) warn: ClockedObject: Already in the requested power state, request ignored warn: User mode does not have SPSR warn: User mode does not have SPSR warn: ignoring syscall set_robust_list(...) warn: ignoring syscall mprotect(...) warn: User mode does not have SPSR warn: User mode does not have SPSR warn: ignoring syscall set_robust_list(...) warn: ignoring syscall mprotect(...) warn: User mode does not have SPSR warn: User mode does not have SPSR warn: ignoring syscall set_robust_list(...) warn: ignoring syscall mprotect(...) warn: User mode does not have SPSR warn: User mode does not have SPSR warn: ignoring syscall set_robust_list(...) warn: ignoring syscall mprotect(...) warn: User mode does not have SPSR warn: User mode does not have SPSR warn: ignoring syscall set_robust_list(...) warn: ignoring syscall mprotect(...) warn: User mode does not have SPSR warn: User mode does not have SPSR warn: ignoring syscall set_robust_list(...) warn: ignoring syscall mprotect(...) warn: User mode does not have SPSR warn: User mode does not have SPSR warn: ignoring syscall set_robust_list(...) warn: ignoring syscall mprotect(...) warn: User mode does not have SPSR warn: User mode does not have SPSR warn: ignoring syscall set_robust_list(...) warn: ignoring syscall mprotect(...) warn: User mode does not have SPSR warn: User mode does not have SPSR warn: ignoring syscall set_robust_list(...) warn: ignoring syscall mprotect(...) warn: User mode does not have SPSR warn: User mode does not have SPSR warn: ignoring syscall set_robust_list(...) warn: ignoring syscall madvise(...) warn: ignoring syscall madvise(...) panic: Page table fault when accessing virtual address 0 Memory Usage: 5171676 KBytes Program aborted at tick 2488935000 --- BEGIN LIBC BACKTRACE --- build/ARM/gem5.opt(_Z15print_backtracev+0x28)[0x1e96f38] build/ARM/gem5.opt(_Z12abortHandleri+0x46)[0x1ea7a66] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f803e38c390] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f803cd88428] /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f803cd8a02a] build/ARM/gem5.opt[0xb6a86f] build/ARM/gem5.opt(_ZN21GenericPageTableFault6invokeEP13ThreadContextRK14RefCountingPtrI10StaticInstE+0x57)[0x1ed38d7] build/ARM/gem5.opt(_ZN13DefaultCommitI9O3CPUImplE10commitHeadERK14RefCountingPtrI13BaseO3DynInstIS0_EEj+0x265)[0x22ea6b5] build/ARM/gem5.opt(_ZN13DefaultCommitI9O3CPUImplE11commitInstsEv+0x471)[0x22eb761] build/ARM/gem5.opt(_ZN13DefaultCommitI9O3CPUImplE6commitEv+0x9cc)[0x22ed93c] build/ARM/gem5.opt(_ZN13DefaultCommitI9O3CPUImplE4tickEv+0xb3)[0x22ee863] build/ARM/gem5.opt(_ZN9FullO3CPUI9O3CPUImplE4tickEv+0x152)[0x22f9e32] build/ARM/gem5.opt(_ZN10EventQueue10serviceOneEv+0xc5)[0x1e9dc55] build/ARM/gem5.opt(_Z9doSimLoopP10EventQueue+0x50)[0x1ebace0] build/ARM/gem5.opt(_Z8simulatem+0xd1b)[0x1ebbdcb] build/ARM/gem5.opt[0x1a34659] build/ARM/gem5.opt[0x19d7809] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7852)[0x7f803e649772] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f803e78005c] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7f803e648f1d] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f803e78005c] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7f803e648f1d] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f803e78005c] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7f803e648f1d] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f803e78005c] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f803e641da9] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x613b)[0x7f803e64805b] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f803e78005c] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7f803e648f1d] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f803e78005c] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f803e641da9] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyRun_StringFlags+0x76)[0x7f803e6bc1f6] --- END LIBC BACKTRACE --- Aborted IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
