GLib, GLib-GIO Critical Errors - app crashes
Current Behavior
I'm not quite sure what the trigger for the crash is, but once in a while, valent simply crashes. I believe it happens after using KDE Connect successfully and then trying to use it again maybe 10-15 minutes later.
Expected Behavior
Valent should run forever
Desktop
GNOME Shell
Other Desktop
No response
Operating System
Ubuntu 22.04
Installed from
Nightly Flatpak
Version
1.0.0.alpha.47
Devices
No response
Plugins
No response
Logs
01:47:46.6944 valent-lan-utils: DEBUG: Accepting certificate "7500DB6DC1A54067B54541625DADAF4F" per successful verification
01:47:46.6944 valent-lan-utils: DEBUG: Accepting certificate "7500DB6DC1A54067B54541625DADAF4F" per successful verification
01:47:46.6945 GLib: CRITICAL: g_atomic_ref_count_dec: assertion 'old_value > 0' failed
malloc(): unaligned tcache chunk detected
01:47:46.6945 GLib-GIO: CRITICAL: g_cancellable_pop_current: assertion 'l->data == cancellable' failed
after this it just exits/crashes.
I do also see more Critical errors 17 minutes earlier, though it didn't crash at that point:
01:30:39.3432 GLib: CRITICAL: g_variant_new_string: assertion 'string != NULL' failed
01:30:39.3432 GLib: CRITICAL: g_variant_ref_sink: assertion 'value != NULL' failed
01:30:39.3432 GLib-GIO: CRITICAL: g_settings_schema_key_type_check: assertion 'value != NULL' failed
01:30:39.3432 GLib: CRITICAL: g_variant_get_type_string: assertion 'value != NULL' failed
01:30:39.3433 GLib-GIO: CRITICAL: g_settings_set_value: key 'session-token' in 'ca.andyholmes.Valent.Plugin.xdp' expects type 's', but a GVariant of type '(null)' was given
01:30:39.3433 GLib: CRITICAL: g_variant_unref: assertion 'value != NULL' failed
Screenshots
No response
Hi, thanks for the report!
I have a fix queued up for the GSettings errors. The second one I expect is related to some thread-safety I've been working through.
Do you happen to know if a device was sending/receiving a file, possible even a notification with an icon? The note about "Accepting certificate..." indicates it's a known device and statistically this is usually for file transfers.
Hi, I mainly only use the “Run command” and “Remote input” features. I have been unable to reproduce the bug, but it seems to happen within a day of running and usually the app works normally a while before it eventually crashes. It’s almost as though the session expires and a reconnect attempt (by opening the iOS app after a period of time) triggers a null pointer somewhere. Is there any way to increase verbosity or enable a stack trace of some sort?Thank you On May 4, 2025, at 08:44, Andy Holmes @.***> wrote: andyholmes left a comment (andyholmes/valent#869) Hi, thanks for the report! I have a fix queued up for the GSettings errors. The second one I expect is related to some thread-safety I've been working through. Do you happen to know if a device was sending/receiving a file, possible even a notification with an icon? The note about "Accepting certificate..." indicates it's a known device and statistically this is usually for file transfers.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
Is there any way to increase verbosity or enable a stack trace of some sort?
If you can find the PID of the crashed process with coredumpctl list, then you can install ca.andyholmes.Valent.Debug and run flatpak-coredumpctl -m <PID> ca.andyholmes.Valent. That should give a backtrace with symbols.
Hi, I couldn't reproduce this yet myself, but I had some big refactorings planned for the LAN plugin that have now landed. Let me know if the problem seems like it disappears :)
Hi, it actually just happened again with the same version and error (assert old_value > 0). I believe it may be related with the virtual trackpad feature (btw this always asks for approval, which makes it inconvenient, it would be great to remember if a device has been approved before) as the app didn't crash for a while without using that feature. I will try upgrading shortly, thanks for notifying me!
(btw this always asks for approval, which makes it inconvenient, it would be great to remember if a device has been approved before)
That will be a portal issue, I'd guess you're just a version behind or so on Ubuntu 22.04. I'll see if I can reproduce with that plugin, though.
Yes, I'm on 22.04, however it is not that big of an issue if the app doesn't crash since I only have to approve once. After updating, I haven't had any crashes over the past week, so things are looking promising so far!
Great news :) I'm hoping that was a threading bug with the TLS connection, so we can give it a bit to be sure - might be a racey problem.
I'm going to close this one up, since I think it was probably fixed by refactoring. Let me know if it comes up again!