Similar issue on linux mint, my GPU is a 1660ti. However the client does not crash completely, it still remains running and is in my applet, able to launch games, but the main window is not accessible whatsoever.

I've updated my nvidia driver yesterday, could be related or coincidence, what is your specific driver version? Mine is 535.54.03

I'm getting the same

(process:73597): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
(process:73597): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

errors on Ubuntu 22.04.2 LTS, though steam does seem to start, only the friends list and options menus will render, the main window seems to be broken.

@databoose

Same issue on linux mint, my GPU is a 1660ti.

I've updated my nvidia driver yesterday, could be related or coincidence, what is your specific driver version? Mine is 535.54.03

I upgraded from 525.125.06 to 535.54.03 tryg to fix.

I'm getting the same

(process:73597): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
(process:73597): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

errors on Ubuntu 22.04.2 LTS, though steam does seem to start, only the friends list and options menus will render, the main window seems to be broken.

Then this is a similar but separate issue both of us are having, if i'm not mistaken for OP it completely crashes with no applet showing, for me the applet is there and the client is running, but the main window cannot be displayed.

Me and OP have the same exact driver version, so It seems like this may be a common root cause with either the new nvidia driver release or the steam client's interaction with the new NVIDIA driver release. What is your exact nvidia driver version?

@databoose

Same issue on linux mint, my GPU is a 1660ti.
I've updated my nvidia driver yesterday, could be related or coincidence, what is your specific driver version? Mine is 535.54.03

I upgraded from 525.125.06 to 535.54.03 tryg to fix.

Yep, so we have the same exact driver version.

Could you clarify if steam is viewable within your applet bar (if you have one), and if you are able to launch games from the applet icon menu, or if the steam client is a running process?

Or does the process completely crash and not running in any way?

@databoose
Clicking the icon or running from the cl, the "updating" dialog appears for a sec adn vanish and that's it, nothing else has it.

@mcneely
@AndyDurden

I have found two potential workarounds (that allow the client to partially run) :

1. Running steam in the terminal with the command "steam -vgui"
2. Going to the directory "/home/USERNAME-HERE/.local/share/Steam" , removing the "steamapps" directory (place it on your desktop, or delete it if you don't care about the games on your internal drive)

Tell me if one of these methods work and which one worked if they do.

@databoose Neither worked, as stated above already tried -vgui and I completely purged steam off my system before reinstalling so the steamapps isn't created at that point.

@mcneely

Try downgrading your nvidia driver to 525 series, while obviously it's not preferable, i'm curious if this works for you as it allows me to fully use the steam client with no issues. (At least with the flatpak version)

@databoose like I stated, I started out on that and only upgraded to try to fix this issue.

@databoose like I stated, I started out on that and only upgraded to try to fix this issue.

Ah, i thought you meant you updated to 535 and then encountered the issue. My bad

i have the same issue on manjaro and steam -vgui worked but it still gives me the critical errors in the console log.

i have the same issue on manjaro and steam -vgui worked but it still gives me the critical errors in the console log.

just noticed that i cant connect to the steam friend network for some reason.

some other thing dont work too, like settings for specific games (im german so i dont know how its called in english)

i fixed it by installing xdg-desktop-portal-gtk using pacman on arch

Hello @mcneely,

Please provide the following:

• output of running ~/.local/share/Steam/ubuntu12_32/steam-runtime/run.sh steam-runtime-system-info
• ~/.steam/steam/logs/bootstrap_log.txt log file
• ~/.steam/steam/logs/webhelper.txt log file

If you don't feel like posting them publicly, it's ok to send those to me directly ([email protected])

Problem was indeed long line in /etc/dconf/profile/user per the original report. Unclear what's happening there, but this doesn't look like a steam issue.

Hey @TTimo , I'm having the exact same problem:
** (process:29488): ERROR **: long line in /etc/dconf/profile/user
/home/martin/.steam/steam.sh : ligne 798 : 29488 Trappe pour point d'arrêt et de trace (core dumped) "$STEAMROOT/$STEAMEXEPATH" "$@"

Can you point me in the right direction?

Just move/remove that file - although I don't know what consequences that might have in gnome..

long line in /etc/dconf/profile/user

What is in that file?

On various test systems with GNOME (Ubuntu 22.04, Ubuntu 20.04, Debian 12, Debian 11), I don't have that file at all. The only file in /etc/dconf/profile for me is ibus, which is a short text file like this:

user-db:user
system-db:ibus

If there is a reason for /etc/dconf/profile/user to exist, then I would have expected it to be a similarly small text file.

@TTimo, it might be helpful to retitle this to "Steam not launching with: ERROR **: long line in /etc/dconf/profile/user" and reopen it?

From the dconf source code, it seems anything in /etc/dconf/profile ought to be a relatively small text file:

 * In the case that no explicit profile was given and DCONF_PROFILE is
 * unset, dconf attempts to open and use a profile called "user" (ie:
 * /etc/dconf/profile/user or XDG_DATA_DIRS/dconf/profile/user).  If
 * that fails then the fallback is to act as if the profile file existed
 * and contained a single line: "user-db:user".

and the most common reason to create one is for "lockdown" (a sysadmin changing certain settings for all of their users and/or preventing users from changing those settings).

long line in /etc/dconf/profile/user

What is in that file?

On various test systems with GNOME (Ubuntu 22.04, Ubuntu 20.04, Debian 12, Debian 11), I don't have that file at all. The only file in /etc/dconf/profile for me is ibus, which is a short text file like this:

user-db:user
system-db:ibus

If there is a reason for /etc/dconf/profile/user to exist, then I would have expected it to be a similarly small text file.

Thanks, after looking up dconf superficially, I came to the same conclusion, and came here to post about it. My file was just a copy of ibus (i have ibus in the same directory also), no idea why it was created (quite some time ago apparently…), I really don't think I did that manually, but hey might have forgotten :). I deleted it, and Steam started.
Thanks for your help

My file was just a copy of ibus (i have ibus in the same directory also)

I'm surprised that would break Steam with error message long line in /etc/dconf/profile/user, because system-db:ibus is not a long line (historically the arbitrary limit seems to have been 80 bytes per line, and my entire /etc/dconf/profile/ibus is only 28 bytes).

I tried copying /etc/dconf/profile/ibus to /etc/dconf/profile/user on a Debian 12 test system and Steam still started up successfully.

I'm surprised that would break Steam with error message long line in /etc/dconf/profile/user

I agree there is something fishy, but that was the content of the file, and deleting it did allow Steam to start. Now, among many things I didn't check the authorizations on the file, and there could be a million things that could contribute to the problem I suppose, maybe a weird corner case, maybe some unwanted interpolation on the content of the file? No idea, but the crash has something to do with that file obviously.

Ok I just ran
`` sudo cp /etc/dconf/profile/ibus /etc/dconf/profile/user
restarted steam and it runs fine… So a mystery… I must admit I wasn't very careful with my observations.

At some point I'll try to look into whether the long line in... message in the old libdconf can occur for a reason that isn't actually anything to do with long lines (a guess: maybe something like 64-bit inode numbers, or 64-bit timestamps like in #9605).

For reference, the error long line in ... comes from usr/lib/*/gio/modules/libdconfsettings.so in the Steam Runtime, which should only be used if you are using the 32-bit GLib that comes from the Steam Runtime. It might be possible to backport some robustness fixes into the Steam Runtime's dconf to make this crash not happen.

For anyone who encounters this specific error message (like @mcneely and @DerProctophantasmist), installing a newer 32-bit library on the host system (libglib2.0-0:i386 and dconf-gsettings-backend:i386 on Debian/Ubuntu, naming will vary in other distributions) might work around it. If you can, please report details and contents of your /etc/dconf/profile/user even if that workaround is successful, because I'd like to have a better idea of how/why this is crashing.

If Steam is not launching but there is not a message ERROR **: long line in /etc/dconf/profile/user, then that's out of scope for this issue and should be reported separately. I think @databoose and maybe @AndyDurden had a different problem involving NVIDIA drivers, and @ItsFrocat had a different problem involving xdg-desktop-portal-gtk; neither of those is in-scope for this issue. Mixing up different causes for a crash on one issue report usually makes the bugs take longer to identify and fix, so we should try not to do that.

These "critical warnings" can often be ignored, and should not be used as evidence that two crashes are the same:

(process:73597): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
(process:73597): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

They indicate that someone somewhere is doing something wrong, but they are not a clear diagnostic for anything, and will often appear even when Steam is working normally. They look worse than they really are, and are usually not fatal.

In my case the file looked like this

I added a new line at the end and that fixed the issue.

@zihadmahiuddin, thank you, that's useful information.

It looks as though old versions of dconf require dconf profiles such as /etc/dconf/profile/user to end with a newline, and will fail with the misleading error message long line in ... if it does not.

@mcneely, does your /etc/dconf/profile/user also not end with a newline? A good way to check is:

$ cat /etc/dconf/profile/user; echo EOF

If the file correctly ends with a newline, the result will look something like:

$ cat /etc/dconf/profile/user; echo EOF
user-db:user
system-db:local
EOF

If the file does not end with a newline (which can trigger this crash) it will look more like:

$ cat /etc/dconf/profile/user; echo EOF
user-db:user
system-db:localEOF

Installing dconf-gsettings-backend:i386 on Debian/Ubuntu, or the closest equivalent package on other distributions, should still work as a workaround for this.

@DerProctophantasmist: please ignore the request for information in my previous comment. Re-reading your earlier comments I see that you already worked around this by overwriting the relevant file, so whatever state previously triggered it for you has already been lost anyway.