udisks coredump

[qiuxinyidian]

(gdb) bt
#0  __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283
#1  0x00007fa230ad181d in is_valid_child_object_path (manager=manager@entry=0x55fd2a48b610, child_object_path=child_object_path@entry=0x0) at ../gio/gdbusobjectmanagerserver.c:485
#2  0x00007fa230ad279b in g_dbus_object_manager_server_export_uniquely (manager=0x55fd2a48b610, object=object@entry=0x55fd2a4cfc20) at ../gio/gdbusobjectmanagerserver.c:607
#3  0x000055fd085fad13 in handle_block_uevent_for_drive (provider=provider@entry=0x55fd2a49b200, action=action@entry=0x55fd086407d9 "add", device=device@entry=0x55fd2a4b9390) at udiskslinuxprovider.c:1125
#4  0x000055fd085fc3d2 in handle_block_uevent (device=0x55fd2a4b9390, action=0x55fd086407d9 "add", provider=0x55fd2a49b200) at udiskslinuxprovider.c:1409
#5  udisks_linux_provider_handle_uevent (provider=provider@entry=0x55fd2a49b200, action=action@entry=0x55fd086407d9 "add", device=0x55fd2a4b9390) at udiskslinuxprovider.c:1439
#6  0x000055fd085fc5bf in do_coldplug (udisks_devices=<optimized out>, provider=<optimized out>) at udiskslinuxprovider.c:549
#7  udisks_linux_provider_start (_provider=0x55fd2a49b200) at udiskslinuxprovider.c:756
#8  0x000055fd085f7dc6 in udisks_daemon_constructed (object=0x55fd2a477200) at udisksdaemon.c:414
#9  0x00007fa2308173a6 in g_object_new_internal (class=class@entry=0x55fd2a476770, params=params@entry=0x7ffecee995a0, n_params=n_params@entry=5) at ../gobject/gobject.c:2296
#10 0x00007fa230819003 in g_object_new_valist (object_type=<optimized out>, first_property_name=first_property_name@entry=0x55fd0864084e "connection", var_args=var_args@entry=0x7ffecee99870)
    at ../gobject/gobject.c:2584
#11 0x00007fa230819659 in g_object_new (object_type=<optimized out>, first_property_name=first_property_name@entry=0x55fd0864084e "connection") at ../gobject/gobject.c:2057
#12 0x000055fd085f8872 in udisks_daemon_new (connection=0x55fd2a475020, disable_modules=0, force_load_modules=0, uninstalled=0, enable_tcrypt=0) at udisksdaemon.c:597
#13 0x000055fd085f76d2 in on_bus_acquired (connection=<optimized out>, name=<optimized out>, user_data=<optimized out>) at main.c:63
#14 0x00007fa230abbfe1 in connection_get_cb (source_object=<optimized out>, res=0x55fd2a474f40, user_data=0x55fd2a46b8e0) at ../gio/gdbusnameowning.c:506
#15 0x00007fa230a55c94 in g_task_return_now (task=task@entry=0x55fd2a474f40) at ../gio/gtask.c:1371
#16 0x00007fa230a568e3 in g_task_return (type=<optimized out>, task=0x55fd2a474f40) at ../gio/gtask.c:1440
#17 g_task_return (task=0x55fd2a474f40, type=<optimized out>) at ../gio/gtask.c:1397
#18 0x00007fa230aab6d2 in bus_get_async_initable_cb (source_object=0x55fd2a475020, res=<optimized out>, user_data=0x55fd2a474f40) at ../gio/gdbusconnection.c:7957
#19 0x00007fa230a55c94 in g_task_return_now (task=task@entry=0x55fd2a475910) at ../gio/gtask.c:1371
#20 0x00007fa230a55cc9 in complete_in_idle_cb (task=task@entry=0x55fd2a475910) at ../gio/gtask.c:1385
#21 0x00007fa2308b0a9e in g_idle_dispatch (source=0x7fa21c008940, callback=0x7fa230a55cc0 <complete_in_idle_cb>, user_data=0x55fd2a475910) at ../glib/gmain.c:6282
#22 0x00007fa2308b3299 in g_main_dispatch (context=0x55fd2a46b210) at ../glib/gmain.c:3476
#23 g_main_context_dispatch_unlocked (context=context@entry=0x55fd2a46b210) at ../glib/gmain.c:4284
#24 0x00007fa2308b4e40 in g_main_context_iterate_unlocked (context=0x55fd2a46b210, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4349
#25 0x00007fa2308b56ef in g_main_loop_run (loop=0x55fd2a46b3c0) at ../glib/gmain.c:4551
#26 0x000055fd085f740e in main (argc=<optimized out>, argv=<optimized out>) at main.c:184

[tbzatek]

Can you put a breakpoint or a print inside udisks_linux_drive_object_constructed() to see what string is being fed to g_dbus_object_skeleton_set_object_path()? Trying to find out why the string is failing the object path validation.

If this happens for a specific device, please also post udevadm info.

[tbzatek]

Also, make sure you have the latest UDisks version.

[qiuxinyidian]

Can you put a breakpoint or a print inside udisks_linux_drive_object_constructed() to see what string is being fed to g_dbus_object_skeleton_set_object_path()? Trying to find out why the string is failing the object path validation.

If this happens for a specific device, please also post udevadm info.

udisksd[549503]: g_dbus_object_skeleton_set_object_path: assertion 'object_path == NULL || g_variant_is_object_path (object_path)' failed

[tbzatek]

udisksd[549503]: g_dbus_object_skeleton_set_object_path: assertion 'object_path == NULL || g_variant_is_object_path (object_path)' failed

I need the actual string that is passed to g_dbus_object_skeleton_set_object_path(), not the assert message.

[qiuxinyidian]

@tbzatek

[tbzatek]

Can you print contents of str->str right before it's passed into g_dbus_object_skeleton_set_object_path() at this place?

udisks/src/udiskslinuxdriveobject.c

Line 288 in bab3cbe

g_dbus_object_skeleton_set_object_path (G_DBUS_OBJECT_SKELETON (object), str->str);

Can you also provide udevadm info output on the affected device? This will require more debugging to find out what's really wrong - the patches you provided are only fixing the aftermath, not the cause and it may fail similarly elsewhere.

[qiuxinyidian]

Can you print contents of str->str right before it's passed into g_dbus_object_skeleton_set_object_path() at this place?

udisks/src/udiskslinuxdriveobject.c

Line 288 in bab3cbe
g_dbus_object_skeleton_set_object_path (G_DBUS_OBJECT_SKELETON (object), str->str);

Can you also provide udevadm info output on the affected device? This will require more debugging to find out what's really wrong - the patches you provided are only fixing the aftermath, not the cause and it may fail similarly elsewhere.

As far as I know, it was a debug/sample NVMe device that lacked model and serial information. I currently no longer have the environment available.

[tbzatek]

I see, thanks anyway. If you happen to get access to the device again, please grab the ouput of nvme id-ctrl -H /dev/... and nvme id-ns -H /dev/... along with nvme ns-descs.

Another aspect here is that the device identifiers may be subject to kernel host driver quirks while UDisks sends admin commands directly to the device resulting in unfiltered data that may be invalid.

Let me see if we can come up with some universal solution, based on your PRs.

[tbzatek]

Fixed in #1528