Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#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 5 years ago by sbingner (Sam Bingner)

Cc: sbingner added

comment:2 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

Milestone: MacPorts 2.6.0
Owner: set to ryandesign
Status: newassigned

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.

comment:3 Changed 4 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 4 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: assignedclosed

Ok. Since MacPorts fakeroot is already at 1.24, I'll close this.

comment:5 Changed 4 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 4 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.

Note: See TracTickets for help on using tickets.