From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cyril Hrubis Date: Fri, 15 Jan 2021 15:27:58 +0100 Subject: [LTP] Holidays and LTP release In-Reply-To: References: <20210113095724.214c904a@kmaincent-XPS-13-7390> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ltp@lists.linux.it Hi! > > > > getrlimit03.c:168: TPASS: __NR_prlimit64(0) and __NR_ugetrlimit(0) > > > > gave consistent results > > > > tst_test.c:1313: TBROK: Test killed by SIGILL! > > > > > > Can we have a backtrace here? It's impossible to say what happened here > > > without further debugging. > > > > I do not have backtrace log for this now. > > Let me share strace output log in this link, > > # strace -f ./getrlimit03 > > https://lkft.validation.linaro.org/scheduler/job/2145166#L2569 > > Thanks. > > I've managed to reproduce as well but I have no idea what happens there, > it looks like something gets corrupted and the processor attempts to > execute invalid code. > > Maybe we pass wrong size of the rlim structure somewhere and kernel > writes over a stack. This is really strange it looks like glibc has wrong syscall number for getrlimit. On 32bit ARM I do have in /usr/include/asm-generic/unistd.h #define __NR_getrlimit 163 While the getrlimit should be 191. It looks like x86-64 syscall definitions are installed on the system for some strange reason, even the header says that it's for x86-64. -- Cyril Hrubis chrubis@suse.cz