You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _gsocproposals/2026/proposal_CVMFS_DStateDebugging.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,7 +31,7 @@ In many cases, it replaces package managers and shared software areas on cluster
31
31
32
32
## Task idea
33
33
34
-
CVMFS is implemented as a FUSE filesystem, which are surprisingly easy to deadlock. While it's a rare occurence in production, if a kernel deadlock occurs, debugging the cause is very difficult. This is because debuggers like gdb rely on sending a PTRACE signal to the process.
34
+
CVMFS is implemented as a FUSE filesystem, which are surprisingly easy to deadlock. While it's a rare occurrence in production, if a kernel deadlock occurs, debugging the cause is very difficult. This is because debuggers like gdb rely on sending a PTRACE signal to the process.
35
35
36
36
In this project proposal, we'd like to investigate ways of obtaining a stacktrace and other possibilities of getting diagnostic information from a stuck process. Even if the process is stuck in a kernel call it *should* still be possible to trigger a coredump and load it with a debugger to get a stacktrace, but we are not aware of any easy way to do this. The resulting utility would be generally useful for FUSE filesystems, but we would want to integrate it into CVMFS.
0 commit comments