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

mremap01 is TBROK on ppc64le #90

Closed
mnowaksuse opened this issue Sep 6, 2016 · 5 comments
Closed

mremap01 is TBROK on ppc64le #90

mnowaksuse opened this issue Sep 6, 2016 · 5 comments

Comments

@mnowaksuse
Copy link

<<<test_start>>>
tag=mremap01 stime=1472852641
cmdline="mremap01"
contacts=""
analysis=exit
<<<test_output>>>
mremap01    1  TBROK  :  tst_sig.c:233: unexpected signal SIGBUS(7) received (pid = 15068).
mremap01    2  TBROK  :  tst_sig.c:233: Remaining cases broken
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=2 corefile=no
cutime=17 cstime=12
<<<test_end>>>

Logs and test setup: https://openqa.suse.de/tests/539272#downloads.

@metan-ucw
Copy link
Member

SIGBUS usually means that we attempted to access memory outside the mapped file but I don't see anything wrong with the test here. It opens a file lseek()s and write()s it in order to resize it, then mmap()s it, and then mremap()s it so that the mapping is twice it's size and writes to the memory. And then it fills the memory that corresponds to the mapped file which is likely the place where we get the SIGBUS.

The only thing that caught my eye is that the memory is mapped PROT_WRITE only, but we do not attempt to read from the mapping at all.

Is that problem 100% reproducible? Can you get a strace of the failure?

@jstancek
Copy link
Contributor

jstancek commented Sep 6, 2016

What kernel are you using? What filesystem is on TMPDIR?

@mnowaksuse
Copy link
Author

Log: runltp.log.txt
Kernel is 4.4 (from SLES12SP2 RC2), heavily patched. There's ext4 on the loopback connected to TMPDIR.

mnowaksuse pushed a commit to mnowaksuse/os-autoinst-distri-opensuse that referenced this issue Sep 6, 2016
This change adds various workarounds for following issues

* linux-test-project/ltp#89
* linux-test-project/ltp#92
* linux-test-project/ltp#90
* linux-test-project/ltp#91

so the LTP (just syscalls) in openQA actually passes.
@metan-ucw
Copy link
Member

@mnowaksuse any chance to get the strace from the failing testcase? Otherwise I doubt that we can figure out what is wrong there.

@mnowaksuse
Copy link
Author

Haven't seen it fail for quite some time.

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

3 participants