-
Notifications
You must be signed in to change notification settings - Fork 18
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
0.43 make check fails on i686 #32
Comments
Also did a local build, so I have ```test/test-suite.log:
|
can you run those commands manually? they should print the reason for the abort on stderr but don't seem to be captured by either of those logs. |
All I see is:
And I cannot see a core file. I added strace to the spec file, here is the output:
|
This happens on Debian as well. The commit which broke it is 491daf4 noted as ' iv_fd_epoll: Add support for epoll_pwait2()'. |
It seems that
The man page for
But neither of those are the case, so this doesn't tell us much. I suspect that the layout of |
Can you test whether c4f4e9f makes the issue go away for you? |
The patch itself looks good, but I did not test it. I'd need a 64bit kernel + 32 bit userland, let me think. |
I reproduced this issue with |
I've just tested this using docker using i386 images. First I reproduced the issue on the master branch (e.g. without the patch), failed
confirmed that it's indeed the EINVAL issue:
Then reset my tree to your change, recompiled and the aborts are gone:
|
Thanks! I added your |
Bit slower feedback. Tested on Debian/i386 and now it compiles here as well. Did an amd64 test as well, still working fine. |
When built for i386, the iv_fd_epoll poll method is getting -EINVAL back from epoll_pwait2(2), presumably because the userland version and the system call version of 'struct timespec' have different layouts, and because we invoke the system call via the syscall() wrapper, which means that no layout translation can be performed by glibc. When this code was originally written, glibc did not provide an epoll_pwait2(2) wrapper, and this is why we invoke it using syscall(). However, glibc does provide a wrapper now, and if we use that wrapper, the issue seems to go away, so let's do that. Issue originally reported by Peter Czanik: #32 Reported-by: Peter Czanik <[email protected]> Signed-off-by: Lennert Buytenhek <[email protected]> Tested-by: Balazs Scheidler <[email protected]> Tested-by: László Böszörményi (GCS) <[email protected]>
Fix merged to master: cc777b2 |
Thanks! Started to work on updating the ivykis package in Fedora Rawhide / openSUSE Tumbleweed / FreeBSD. My current ETA is next week, depending on my health and the speed of the various approval processes. |
@buytenh @bazsi I did a few tests using 0.43.1 and syslog-ng. FreeBSD seems to be all right. However, on Fedora Linux syslog-ng behaves strangely since the new ivykis was installed: it works when started from a terminal, but not when started from systemd. No test on openSUSE, as that uses the ivykis version embedded into syslog-ng sources. |
@bazsi Can you take this one? |
Update: yesterday, when it failed, I tested it on Fedora 39. This morning I tested it on Rocky Linux 9, and experienced no problems. Next I tested it on Fedora Rawhide, and it also failed the same way. |
Sorry, I was out on a conference, just returned. I don't have a fedora environment handy, but I'll try to reproduce this. |
I've checked and it did start up for me properly. I've noticed two issues, but neither are ivykis related:
The first seems to be a systemd unit issue, the 2nd is a missing selinux permission. Here's the list of audit failure events for syslog-ng: Versions of the packages (pulled them from your githead repo): |
While trying to update the ivykis package on Fedora from 0.42.4 to 0.43 I ran into a problem.
make check
runs fine on all Fedora platforms for ivykis 0.42.4. However, for 0.43 it fails on i686:You can find the full log at: https://kojipkgs.fedoraproject.org//work/tasks/1834/112651834/build.log
Is there a real bug behind these failures, or I should just disable
make check
on i686?The text was updated successfully, but these errors were encountered: