Bug 2361557 - SEGV after launch when google driver is "mounted"
Summary: SEGV after launch when google driver is "mounted"
Keywords:
Status: CLOSED DUPLICATE of bug 2360468
Alias: None
Product: Fedora
Classification: Fedora
Component: baobab
Version: 42
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kalev Lember
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-04-22 02:54 UTC by Benjamin Herrenschmidt
Modified: 2025-06-25 10:00 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-06-25 10:00:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Benjamin Herrenschmidt 2025-04-22 02:54:28 UTC
When launching baobab, if google drive is mounted in gvfs, the application will SEGV shortly after displaying the window.

The window content is correct, it dies about a second later (see below for more details).

Reproducible: Always

Steps to Reproduce:
1. Setup google account in gnome
2. Mount google drive (using either baobab itself or nautilus)
3. Baobab crashes
Actual Results:
Crash after displaying the window

Expected Results:
It doesn't crash :-)

Additional Information:
So running it with gdb, it dies in a g_idle callback. Here's the full backtrace:

Thread 1 "baobab" received signal SIGSEGV, Segmentation fault.
baobab_location_list_volume_changed (self=0x555555852ae0, volume=0x555555718010) at ../src/baobab-location-list.vala:160
160	            foreach (var location in locations) {
(gdb) backtrace 
#0  baobab_location_list_volume_changed (self=0x555555852ae0, volume=0x555555718010) at ../src/baobab-location-list.vala:160
#1  0x000055555556242e in baobab_location_list_mount_added (self=0x555555852ae0, mount=0x555555ee69e0)
    at ../src/baobab-location-list.vala:217
#5  0x00007ffff7c3a02a in <emit signal '0x7ffff7ddd150 "mount-added" or mount-added' on instance ???>
    (instance=0x555555851740, detailed_signal=0x7ffff7ddd150 "mount-added") at ../gobject/gsignal.c:3638
    #2  0x00007ffff7c19b1a in g_closure_invoke
    (closure=0x5555557d16e0, return_value=0x0, n_param_values=2, param_values=0x7fffffffce40, invocation_hint=0x7fffffffcd90)
    at ../gobject/gclosure.c:833
    #3  0x00007ffff7c37aba in signal_emit_unlocked_R
    (node=node@entry=0x7fffffffcf50, detail=detail@entry=0, instance=instance@entry=0x555555851740, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffce40) at ../gobject/gsignal.c:3902
    #4  0x00007ffff7c39adc in signal_emit_valist_unlocked
    (instance=instance@entry=0x555555851740, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffd0a0)
    at ../gobject/gsignal.c:3534
#9  0x00007ffff7c3a02a in <emit signal '0x7fffd67c7d19 "mount-added"' on instance ???>
    (instance=0x7fffd800ca70, detailed_signal=0x7fffd67c7d19 "mount-added") at ../gobject/gsignal.c:3638
    #6  0x00007ffff7c1877a in g_cclosure_marshal_VOID__OBJECTv
    (closure=<optimized out>, return_value=<optimized out>, instance=<optimized out>, args=<optimized out>, marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x555555869010) at ../gobject/gmarshal.c:1910
    #7  0x00007ffff7c39c43 in _g_closure_invoke_va
    (closure=0x55555568b990, return_value=0x0, instance=0x7fffd800ca70, args=0x7fffffffd440, n_params=1, param_types=0x555555869010)
    at ../gobject/gclosure.c:896
    #8  signal_emit_valist_unlocked
    (instance=instance@entry=0x7fffd800ca70, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffd440)
    at ../gobject/gsignal.c:3438
#10 0x00007fffd67bf7f7 in signal_emit_in_idle_do (data=0x555555d69b70) at ../monitor/proxy/gproxyshadowmount.c:546
#11 0x00007ffff7e8776d in g_idle_dispatch
    (source=0x555555d95b90, callback=0x7fffd67bf830 <signal_emit_in_idle_do.lto_priv>, user_data=0x555555d69b70) at ../glib/gmain.c:6284
#12 0x00007ffff7e81040 in g_main_dispatch (context=0x5555555c0e00) at ../glib/gmain.c:3398
#13 g_main_context_dispatch_unlocked (context=0x5555555c0e00) at ../glib/gmain.c:4249
#14 0x00007ffff7e8a128 in g_main_context_iterate_unlocked
    (context=context@entry=0x5555555c0e00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4314
#15 0x00007ffff7e8a2d3 in g_main_context_iteration (context=context@entry=0x5555555c0e00, may_block=may_block@entry=1)
    at ../glib/gmain.c:4379
#16 0x00007ffff7d240ad in g_application_run
    (application=application@entry=0x5555555bccf0, argc=argc@entry=1, argv=argv@entry=0x7fffffffd8a8) at ../gio/gapplication.c:2715
#17 0x0000555555557f7f in _vala_main (args=0x7fffffffd8a8, args_l

Now I'm not particularly knowledgable in vala nor do I know much about vala/gdb integration. gdb doesn't seem to find a symbol called "locations" here, but "location" does seem to be NULL:

(gdb) p location
$1 = 0x0

Comment 1 Milan Crha 2025-06-25 10:00:19 UTC
Thanks for a bug report and the detailed steps with the backtrace. The bug #2360468 is about the same, thus I'll close this as a duplicate of it (it had been filled earlier). Please see bug #2360468 for further information.

*** This bug has been marked as a duplicate of bug 2360468 ***


Note You need to log in before you can comment on or make changes to this bug.