Segmentation fault when attempting to create a dock with no X connections available

[Starwort]

Operating System Info

Ubuntu 22.04

Other OS

No response

OBS Studio Version

30.1.2

OBS Studio Version (Other)

No response

OBS Studio Log URL

Can't obtain - crash on startup

OBS Studio Crash Log URL

No response

Expected Behavior

OBS not crashing

Current Behavior

OBS crashes as soon as Twitch chat loads (within about half a second of the rest of the program loading)

Steps to Reproduce

1. Launch OBS
2. Crash as soon as Twitch chat loads (no content, just a white panel)

Anything else we should know?

Crash occurs in both Safe Mode and Run Normally Relevant output (obtained from the output of obs -v):

Maximum number of clients reachedMaximum number of clients reachedMaximum number of clients reachedMaximum number of clients reachedMaximum number of clients reachedMaximum number of clients reachedMaximum number of clients reachedMaximum number of clients reachedMaximum number of clients reachedMaximum number of clients reachedMaximum number of clients reachedMaximum number of clients reachedMaximum number of clients reachedMaximum number of clients reachedMaximum number of clients reachedinfo: adding 42 milliseconds of audio buffering, total audio buffering is now 42 milliseconds (source: Mic/Aux)

Maximum number of clients reached
(obs:1569938): dbind-WARNING **: 09:58:59.537: Could not open X display
Maximum number of clients reached
Segmentation fault (core dumped)

[mihawk90]

Judging by your output this is not a bug with OBS, but rather a support issue - with your distro, not OBS.

Both

Maximum number of clients reached

and

(obs:1569938): dbind-WARNING **: 09:58:59.537: Could not open X display

... are errors from your X server telling you that it cannot open any further connections, and therefore OBS (or rather Qt) fails to register a Window.

This is a scenario that happens when you have either too many applications open that open a socket to your X server, or (more likely) an issue with your distribution where it leaks open X server connections. I've run into the latter scenario before.

You can see how many open sockets there are to your X server using

ss -x src "@/tmp/.X11-unix/*" | wc -l

Any return value north of 100 (which is already an extreme for regular user's usecase scenarios) points towards an issue with your Distribution.

Either way, this is not an OBS issue. OBS tries to register a window, but your X server refuses to do so.

[Starwort]

You can see how many open sockets there are to your X server using

ss -x src "@/tmp/.X11-unix/*" | wc -l

Any return value north of 100 (which is already an extreme for regular user's usecase scenarios) points towards an issue with your Distribution.

Yup - I'm getting 250 open sockets(!), now I just have to figure out what's causing the leak on my end

That said, it feels like it should be possible to avoid the segfault in such a case - I'll leave this issue open for that

[mihawk90]

Yup - I'm getting 250 open sockets(!), now I just have to figure out what's causing the leak on my end

When I faced this issue it seemed to be related to a specific KDE version, so if you happen to be using KDE, that might be the issue. I don't know what version it was or what version fixed it though, since that was 2 years ago. Killing and restarting KDE would immediately drop the sockets.

That said, it feels like it should be possible to avoid the segfault in such a case

Not sure how to be honest. Even if it's possible though, the only other alternative is just shutting OBS down by itself, which effectively results in the same behaviour.

[Starwort]

so if you happen to be using KDE, that might be the issue.

Yeah - I've since reduced the number of open sockets (though I have genuinely no clue how!), so things are running more smoothly. My install is less than a year old though, so unlikely to be the same issue you had

Not sure how to be honest. Even if it's possible though, the only other alternative is just shutting OBS down by itself, which effectively results in the same behaviour.

1. If the crash occurs when loading a dock, the dock could just be closed without crashing the rest of the program (this would also allow pulling logs in these cases)
2. A clean shutdown would prevent the 'do you want to start in safe mode' dialogue from appearing; given that Safe Mode does not actually reduce the X socket usage (and therefore doesn't fix the problem), this is probably a worthwhile quality of life change

[dtronicsuk]

Unfortually this issue also happens on Windows, obs is fine if the chat isnt docked but as soon as your try obs crashes

[RytoEX]

Unfortually this issue also happens on Windows, obs is fine if the chat isnt docked but as soon as your try obs crashes

Please provide a crash log and a normal OBS log.

[dtronicsuk]

@RytoEX Here you go

2024-05-07 21-49-26.txt

Crash 2024-05-07 21-49-16.txt

[RytoEX]

@dtronicsuk I'm pretty sure your problem is unrelated. You're experiencing a crash deep in Qt. Do you buy chance have any environment variables set, such as QT_WIDGETS_RHI? In any case, ask in our normal support channels to see if this is a known issue or a reportable bug.

1. If the crash occurs when loading a dock, the dock could just be closed without crashing the rest of the program (this would also allow pulling logs in these cases)
2. A clean shutdown would prevent the 'do you want to start in safe mode' dialogue from appearing; given that Safe Mode does not actually reduce the X socket usage (and therefore doesn't fix the problem), this is probably a worthwhile quality of life change

1. If Qt crashes, I don't think we can stop that.
2. The Safe Mode check is an alert to notify the user that OBS did not exit cleanly as this is not always obvious to the user. If OBS is crashing, it may not be saving user data correctly. We're not going to special case it on different kinds of crashes. If you do not find it valuable, you can disable it by launching OBS with --disable-shutdown-check.

Closing per @mihawk90 's comments. This doesn't sound like an OBS issue.