[1.4] Janus crashes with general protection fault in kernel log

[bijaykandel37]

janus_videoroom_helper_thread() in plugins/janus_videoroom.c crashes with SIGSEGV inside
strlen() (called via JANUS_LOG → janus_vprintf → g_vasprintf → vasprintf) when logging
its own exit message:

JANUS_LOG(LOG_VERB, "[%s/#%d] Leaving VideoRoom helper thread\n", room->room_id_str, helper->id);

This happens at plugins/janus_videoroom.c:14261. Reproduced twice independently on production,
one day apart, with identical signatures — in both cases two helper threads crash simultaneously
at the exact same instruction, strongly suggesting the room (and its room_id_str) is freed by the
room-destroy path while one or more helper threads for that room are still exiting their loop and
about to log their own shutdown message.

Environment

• Janus version: 1.4.2 (build 1402)
• Commit: 94408ffccbc1a7c39dac82d55e5dd475c807e770
• OS: Ubuntu (24.04-based), kernel via AWS EC2
• Compiled: Mon May 11 08:58:51 UTC 2026
• Plugins active: VideoRoom, AudioBridge, Streaming, SIP, NoSIP, VideoCall, TextRoom, RecordPlay, EchoTest
• Transports active: HTTP, WebSockets

Steps to reproduce

Not deterministically reproducible on demand — occurs under normal production load with routine
room creation/destruction and multiple active VideoRoom helper threads (multi-forwarder / simulcast
setups spawn helper threads per room). Appears tied to a room being destroyed while its helper
thread(s) are still in their processing loop.

Crash 1 — backtrace (gdb, via apport core, Jul 12 2026)

#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
#1  __printf_buffer (format="%s%s%s%s[%s/#%d] Leaving VideoRoom helper thread\n", ...) at ./stdio-common/vfprintf-process-arg.c:443
#2  __vasprintf_internal () at ./libio/vasprintf.c:102
#3  g_vasprintf ()
#4  janus_vprintf (format=...) at log.c:149
    str = 0x0
#5  janus_videoroom_helper_thread (data=0x74b0fc002fb0) at plugins/janus_videoroom.c:14261
#6  start_thread ()
#7  __clone3 ()

A second thread (different LWP) crashed at the identical instant, same backtrace, same line
— both helper threads for the same room exiting concurrently.

Crash 2 — backtrace (gdb via coredumpctl, Jul 13 2026, ~24h later)

Identical signature and line number (plugins/janus_videoroom.c:14261), again with two threads
crashing simultaneously at the same instruction (LWP 1079909 and 1079910 in this instance).
str = 0x0 again in janus_vprintf's frame.

Relevant source (plugins/janus_videoroom.c, lines ~14234–14261)

static void *janus_videoroom_helper_thread(void *data) {
    janus_videoroom_helper *helper = (janus_videoroom_helper *)data;
    janus_videoroom *room = helper->room;
    janus_videoroom_publisher_stream *ps = NULL;
    GList *subscribers = NULL;
    JANUS_LOG(LOG_VERB, "[%s/#%d] Joining VideoRoom helper thread\n", room->room_id_str, helper->id);
    janus_videoroom_rtp_relay_packet *pkt = NULL;
    while(!g_atomic_int_get(&stopping) && !g_atomic_int_get(&room->destroyed) && !g_atomic_int_get(&helper->destroyed)) {
        pkt = g_async_queue_pop(helper->queued_packets);
        if(pkt == &exit_packet)
            break;
        janus_mutex_lock(&helper->mutex);
        ps = pkt->source;
        subscribers = g_hash_table_lookup(helper->subscribers, ps);
        if(subscribers != NULL) {
            g_list_foreach(subscribers,
                pkt->is_rtp ? janus_videoroom_relay_rtp_packet : janus_videoroom_relay_data_packet,
                pkt);
        }
        janus_mutex_unlock(&helper->mutex);
        janus_videoroom_rtp_relay_packet_free(pkt);
    }
    JANUS_LOG(LOG_VERB, "[%s/#%d] Leaving VideoRoom helper thread\n", room->room_id_str, helper->id);
    janus_refcount_decrease(&helper->ref);
    janus_refcount_decrease(&room->ref);
    g_thread_unref(g_thread_self());
    return NULL;
}

Suspected root cause

The loop condition checks room->destroyed, but room->room_id_str appears to be freed by the
room-destruction path before janus_refcount_decrease(&room->ref) is called at the bottom of
this function — i.e. before the helper thread has fully released its hold on the room. If the
room's destroy callback frees room_id_str as soon as room->destroyed is set (rather than
waiting for the refcount to reach zero), any helper thread that is mid-loop or just breaking out
of it will read a dangling pointer when it logs its own exit message, causing strlen(NULL) /
strlen(<freed memory>) inside the printf formatting machinery.

The fact that two helper threads crashed at the identical instant in both independent
occurrences supports this: multiple helpers belonging to the same room hit their shutdown log
line concurrently right as the room is torn down.

Suggested fix

Cache the room ID as a local string at the top of janus_videoroom_helper_thread, before the
loop, so neither the "Joining" nor "Leaving" log lines dereference room->room_id_str after
the room may have started being destroyed:

char room_id_str[64];
g_snprintf(room_id_str, sizeof(room_id_str), "%s", room->room_id_str);
...
JANUS_LOG(LOG_VERB, "[%s/#%d] Joining VideoRoom helper thread\n", room_id_str, helper->id);
...
JANUS_LOG(LOG_VERB, "[%s/#%d] Leaving VideoRoom helper thread\n", room_id_str, helper->id);

Alternatively, ensure room_id_str (and any other fields referenced during helper shutdown) are
only freed once all helper threads' refcounts have actually dropped to zero, not merely when
room->destroyed is set.

Additional context

Two independent crash captures, ~24 hours apart, both production, both identical signature/line —
this is a real, reproducible race rather than an isolated fluke. Happy to provide the full
thread apply all bt output from either core if useful.

[lminiero]

Please set a proper title for this issue.

I don't think cachine the room ID is the right fix. This shouldn't happen in the first place, exactly because each helper thread is configured to add a reference to the room instance they belong to. If a room is being destroyed before the helper releases their reference, it means the room free function is being called too early (references get to 0 when they shouldn't). A way to debug what's happening is enabling refcount debugging, which will print on the logs how references change.

Rather than enabling refcount debugging for everything (which could make your logs quite big), you can try only enabling debug for the videoroom room references: this means changing

• janus_refcount_init --> janus_refcount_init_debug
• janus_refcount_increase --> janus_refcount_increase_debug
• janus_refcount_decrease --> janus_refcount_decrease_debug

in all places they're invoked for a videoroom room instance (e.g., everywhere you see a room->ref). You could also replace all calls in the VideoRoom, but again that might probably be too verbose (although it could help, in case a different resources being freed too early could be the actual cause here). Once you have a log where it crashes and you have the refcount debug info available, we can figure out what happened.