Skip to content

gh-127604: Don't rely on dprintf() for faulthandler C stacks #132800

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.

Sign up for GitHub

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

Closed
wants to merge 5 commits into from
Closed

gh-127604: Don't rely on dprintf() for faulthandler C stacks #132800

Show file tree
Hide file tree
Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
dc39d9a
Don't rely on dprintf() for faulthandler C stacks
ZeroIntensity Apr 22, 2025
b9520d5
Add fclose()
ZeroIntensity Apr 23, 2025
a3ded44
Add dup()
ZeroIntensity Apr 23, 2025
d8e1279
Add close()
ZeroIntensity Apr 23, 2025
6f6444d
Remove needless close()
ZeroIntensity Apr 23, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions Include/internal/pycore_fileutils.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -132,6 +132,8 @@ PyAPI_FUNC(Py_ssize_t) _Py_write_noraise(
const void *buf,
size_t count);

extern int _Py_fdprintf(int fd, const char *fmt, ...);

#ifdef HAVE_READLINK
extern int _Py_wreadlink(
const wchar_t *path,
Expand Down
28 changes: 28 additions & 0 deletions Python/fileutils.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,9 @@
# include <windows.h>
# include <winioctl.h> // FILE_DEVICE_* constants
# include "pycore_fileutils_windows.h" // FILE_STAT_BASIC_INFORMATION
# define fdopen _fdopen
# define dup _dup
# define close _close
# if defined(MS_WINDOWS_GAMES) && !defined(MS_WINDOWS_DESKTOP)
# define PATHCCH_ALLOW_LONG_PATHS 0x01
# else
Expand Down Expand Up @@ -2059,6 +2062,31 @@ _Py_write_noraise(int fd, const void *buf, size_t count)
return _Py_write_impl(fd, buf, count, 0);
}

int
_Py_fdprintf(int fd, const char *fmt, ...)
{
int newfd = dup(fd);
if (newfd < 0) {
return -1;
}
FILE *handle = fdopen(newfd, "a");
if (handle == NULL) {
close(newfd);
return -1;
}
va_list vargs;
va_start(vargs, fmt);
int res = vfprintf(handle, fmt, vargs);
va_end(vargs);
fclose(handle);
close(newfd);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't need close() here, because fclose() closes the file descriptor.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I'm not used to going between FILE * and int like this. Fixed it.

if (res != 0) {
return -1;
}

return 0;
}

#ifdef HAVE_READLINK

/* Read value of symbolic link. Encode the path to the locale encoding, decode
Expand Down
16 changes: 8 additions & 8 deletions Python/traceback.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1210,7 +1210,7 @@ _Py_backtrace_symbols_fd(int fd, void *const *array, Py_ssize_t size)
|| info[i].dli_fname == NULL
|| info[i].dli_fname[0] == '\0'
) {
dprintf(fd, " Binary file '<unknown>' [%p]\n", array[i]);
_Py_fdprintf(fd, " Binary file '<unknown>' [%p]\n", array[i]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be safer to not use printf family but use traceback.c functions to write directly into the fd.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but then we have to deal with stack limits. I'll probably end up using those regardless, though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrote #132854 to replace dprintf() with _Py_write_noraise().

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but then we have to deal with stack limits

Which stack limits? traceback.c code is designed to use little stack memory and be async-signal safe.

Copy link
Member Author

@ZeroIntensity ZeroIntensity Apr 23, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking of a sprintf that would be incrementally printed. Your solution works a lot better.

continue;
}

Expand All @@ -1222,9 +1222,9 @@ _Py_backtrace_symbols_fd(int fd, void *const *array, Py_ssize_t size)

if (info[i].dli_sname == NULL
&& info[i].dli_saddr == 0) {
dprintf(fd, " Binary file \"%s\" [%p]\n",
info[i].dli_fname,
array[i]);
_Py_fdprintf(fd, " Binary file \"%s\" [%p]\n",
info[i].dli_fname,
array[i]);
}
else {
char sign;
Expand All @@ -1238,10 +1238,10 @@ _Py_backtrace_symbols_fd(int fd, void *const *array, Py_ssize_t size)
offset = info[i].dli_saddr - array[i];
}
const char *symbol_name = info[i].dli_sname != NULL ? info[i].dli_sname : "";
dprintf(fd, " Binary file \"%s\", at %s%c%#tx [%p]\n",
info[i].dli_fname,
symbol_name,
sign, offset, array[i]);
_Py_fdprintf(fd, " Binary file \"%s\", at %s%c%#tx [%p]\n",
info[i].dli_fname,
symbol_name,
sign, offset, array[i]);
}
}
}
Expand Down
Loading