Skip to content

Conversation

@jp-sarte
Copy link

This fixes a potential segfault when avio_open fails -> we go to cleanup -> cleanup sees that s->mutex_held (now s->mutex_status) is true, and thus tries to acquire the mutex, yet the mutex isn't initialized: segfault.

A similar issue occurs when we try to pthread_join on the thread in the cleanup if it's not created. Thus a "bool" for the initialization of the thread is added.

One condition that avio_open can fail on is when the file path is too long.

This is most likely the segfault experienced in #110

@jp-sarte jp-sarte force-pushed the bugfix/segfault-in-encode-cleanup branch 2 times, most recently from b695675 to 949ca76 Compare December 10, 2025 22:42
pthread_join(ctx->thread, NULL);
}
if (ctx->mutex_status != MUTEX_STATUS_NOT_INITIALIZED) {
pthread_mutex_destroy(&ctx->lock);
Copy link
Owner

Choose a reason for hiding this comment

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

You can just check if it exists by checking its value, you know?

Copy link
Author

@jp-sarte jp-sarte Dec 14, 2025

Choose a reason for hiding this comment

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

I presume that you mean ctx->thread here, which you're correct about. I didn't know about that! Thanks.
Based on my research though it doesn't look like it's a good idea to rely on a zero-value for whether ctx->lock is valid or not, since a valid lock might actually just be zero. See PTHREAD_MUTEX_INITIALIZER at https://elixir.bootlin.com/glibc/glibc-2.29/source/sysdeps/nptl/pthread.h

This fixes a potential segfault when `avio_open` fails -> we go to
cleanup -> cleanup sees that `s->mutex_held` (now `s->mutex_status`) is true, and thus tries
to acquire the mutex, yet the mutex isn't initialized: segfault.

A similar issue occurs when we try to `pthread_join` on the thread in
the cleanup if it's not created. Thus a "bool" for the initialization of
the thread is added.

One condition that `avio_open` can fail on is when the file path is too
long.
@jp-sarte jp-sarte force-pushed the bugfix/segfault-in-encode-cleanup branch from 949ca76 to a7ed86f Compare December 14, 2025 22:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants