#58296 closed defect (fixed)
fakeroot @1.22: hangs on interrupted system call
Reported by: | sbingner (Sam Bingner) | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.5.4 |
Keywords: | haspatch | Cc: | sbingner (Sam Bingner) |
Port: | fakeroot |
Description
If fakeroot encounters an interrupted system call it will hang forever after the message libfakeroot, when sending message: Interrupted system call
Debian has a patch for this bug at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883780
Change History (6)
comment:1 Changed 6 years ago by sbingner (Sam Bingner)
Cc: | sbingner added |
---|
comment:2 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
Milestone: | MacPorts 2.6.0 |
---|---|
Owner: | set to ryandesign |
Status: | new → assigned |
comment:3 Changed 5 years ago by sbingner (Sam Bingner)
Sorry for late response, it did not help but 1.24 released in Sept supposedly fixes it based on the bug report
comment:4 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Ok. Since MacPorts fakeroot is already at 1.24, I'll close this.
comment:5 Changed 5 years ago by sbingner (Sam Bingner)
Can confirm that 1.24 did fix this but I had to patch it to get it to work as it was not correctly replacing next_openat
with openat
in the function to handle openat
-- not sure if my patch was proper but it made it work and I verified that it works on openat calls as well. This may have been some quirk in my build environment because I can't imagine nobody noticing that fakeroot always crashed with an error about a missing next_openat
symbol
--- wrapfunc.inp 2019-11-16 22:33:24.000000000 -1000 +++ wrapfunc.inp.new 2019-11-16 22:33:16.000000000 -1000 @@ -197,7 +197,7 @@ mkdirat;int;(int dir_fd, const char *pathname, mode_t mode);(dir_fd, pathname, mode) #endif /* HAVE_MKDIRAT */ #ifdef HAVE_OPENAT -openat;int;(int dir_fd, const char *pathname, int flags, ...); +openat;int;(int dir_fd, const char *pathname, int flags, ...) #endif /* HAVE_OPENAT */ #ifdef HAVE_RENAMEAT renameat;int;(int olddir_fd, const char *oldpath, int newdir_fd, const char *newpath);(olddir_fd, oldpath, newdir_fd, newpath) --- libfakeroot.c 2019-11-16 23:23:50.000000000 -1000 +++ libfakeroot.c.new 2019-11-16 23:24:42.000000000 -1000 @@ -2437,6 +2437,7 @@ #ifdef HAVE_OPENAT int openat(int dir_fd, const char *pathname, int flags, ...) { +#undef openat if (flags & O_CREAT) { va_list args; @@ -2444,8 +2445,9 @@ va_start(args, flags); mode = va_arg(args, int); va_end(args); - return next_openat(dir_fd, pathname, flags, mode); + return openat(dir_fd, pathname, flags, mode); } - return next_openat(dir_fd, pathname, flags, NULL); + return openat(dir_fd, pathname, flags); +#define openat my_openat } #endif
comment:6 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)
That isn't really related to this bug report.
The openat problems have been reported to the developer 5 years ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766649 I don't know why it has gone unresolved for so long.
We are already applying some local patches to fix something, since 4 years ago, but I guess what we've done isn't working. It says as much in comment:ticket:49858:14.
It's not our job to develop this software; it's the developer's job. So I would recommend communicating with the developer of fakeroot about getting these issues fixed. This is the repository: https://salsa.debian.org/clint/fakeroot If you can submit merge requests to them to fix any problems, hopefully they would appreciate that.
I have updated fakeroot to 1.23. Did that help?
If not, please discuss the issue with the developers in the Debian bug report you mentioned above and ask them to release a new version of fakeroot containing the fix; if they do, we can then update MacPorts fakeroot to that version.