Bug 254459 - sysutils/bsdisks: core dump when unmounting NTFS-formatted SD card
Summary: sysutils/bsdisks: core dump when unmounting NTFS-formatted SD card
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Gleb Popov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-03-21 10:54 UTC by Martin Birgmeier
Modified: 2021-04-15 11:45 UTC (History)
0 users

See Also:
arrowd: maintainer-feedback+


Attachments
script file of running "bsdisks" and typing some explanatory text while it is running (6.36 KB, text/plain)
2021-03-21 10:54 UTC, Martin Birgmeier
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Birgmeier 2021-03-21 10:54:18 UTC
Created attachment 223472 [details]
script file of running "bsdisks" and typing some explanatory text while it is running

Scenario:
- FreeBSD 12.2 latest patches
- Ports up-to-date as of 2021-03-20
- Therefore bsdisks updated from 0.2.4 to 0.2.5
- SD card formatted using NTFS, with the following entry in /etc/fstab:

/dev/ntfs/disk51s1      /d/51s1         ntfs    rw,noauto,mountprog=/usr/local/bin/ntfs-3g      0 0

- Inserting SD card
- mounting: mount /d/51s1
- unmounting: umount /d/51s1

Result:
- bsdisks crashes

Notes:
- A script of running bsdisks in the foreground is attached
- It seems that bsdisks does not react correctly to the mount (as it did in the previous version)
- The same problem occurs with a USB stick with NTFS filesystem and the following fstab entry:

/dev/ntfs/disk38        /d/38           ntfs    rw,noauto,mountprog=/usr/local/bin/ntfs-3g      0 0

Version 0.2.4 worked perfectly (for me).

-- Martin
Comment 1 Gleb Popov freebsd_committer freebsd_triage 2021-03-22 07:52:46 UTC
I don't have a machine with FreeBSD 12 and SD card reader on it, so I'll need your help with debugging.

Can you please compile bsdisks with debugging symbols enabled, then reproduce the crash under gdb and generate a backtrace?
Comment 2 Martin Birgmeier 2021-03-28 11:07:25 UTC
After adding WITH_DEBUG=yes in the Makefile and recreating the port using portmaster:

[0]# lldb /usr/local/bin/bsdisks
(lldb) target create "/usr/local/bin/bsdisks"
Current executable set to '/usr/local/bin/bsdisks' (x86_64).
(lldb) run
Process 15825 launching
Process 15825 launched: '/usr/local/bin/bsdisks' (x86_64)
...
"Registering /org/freedesktop/UDisks2/block_devices/ada0s4"
Pop  "ada0s4"  from m_postponedRegistrations
"Registering /org/freedesktop/UDisks2/block_devices/ada0s4b"
Pop  "ada0s4b"  from m_postponedRegistrations
"Registering /org/freedesktop/UDisks2/block_devices/ada0s4e"
Pop  "ada0s4e"  from m_postponedRegistrations
"Registering /org/freedesktop/UDisks2/block_devices/ada0s4a"
Pop  "ada0s4a"  from m_postponedRegistrations
Finished FS probe on  "cd0"
"Registering /org/freedesktop/UDisks2/block_devices/cd0"
...

(inserting an NTFS-formatted USB drive)

...
Created drive  "da0"
Created block  "da0"
Finished FS probe on  "da0"
Finished GEOM probe on  "da0"
"da0"  waits for drive  "da0"
"Registering /org/freedesktop/UDisks2/drives/da0"
"Registering /org/freedesktop/UDisks2/block_devices/da0"
Pop  "da0"  from m_postponedRegistrations

(mounting it; unmounting it)

Process 15825 stopped
* thread #1, name = 'bsdisks', stop reason = signal SIGSEGV: invalid address (fault address: 0x58)
    frame #0: 0x0000000000278dc4 bsdisks`std::__1::__bitset<1ul, 2ul>::all(this=0x0000000000000058) const at bitset:578:15
   575  __bitset<1, _Size>::all() const _NOEXCEPT
   576  {
   577      __storage_type __m = ~__storage_type(0) >> (__bits_per_word - _Size);
-> 578      return !(~__first_ & __m);
   579  }
   580
   581  template <size_t _Size>
(lldb) bt
error: bsdisks DWARF DW_TAG_array_type DIE at 0x00358719 has a class/union/struct element type DIE 0x00358726 that is a forward declaration, not a complete definition.
Try compiling the source file with -fstandalone-debug or disable -gmodules
error: bsdisks :: Class 'GeomProber' has a base class 'QObject' which does not have a complete definition.
error: bsdisks :: Try compiling the source file with -fstandalone-debug.
* thread #1, name = 'bsdisks', stop reason = signal SIGSEGV: invalid address (fault address: 0x58)
  * frame #0: 0x0000000000278dc4 bsdisks`std::__1::__bitset<1ul, 2ul>::all(this=0x0000000000000058) const at bitset:578:15
    frame #1: 0x0000000000275708 bsdisks`std::__1::bitset<2ul>::all(this=0x0000000000000058) const at bitset:1027:18
    frame #2: 0x000000000026dc2c bsdisks`ObjectManager::updateBlock(this=0x00000000002a2ca0, dev=<unavailable>) at objectmanager.cpp:157:22
    frame #3: 0x0000000000246bb9 bsdisks`QtPrivate::FunctorCall<QtPrivate::IndexesList<0>, QtPrivate::List<QString>, void, void (ObjectManager::*)(QString)>::call(f=f0 db 26 00 00 00 00 00 00 00 00 00 00 00 00 00, o=0x00000000002a2ca0, arg=0x0000000802143438)(QStr
ing), ObjectManager*, void**) at qobjectdefs_impl.h:152:13
    frame #4: 0x0000000000246ae8 bsdisks`void QtPrivate::FunctionPointer<void (ObjectManager::*)(QString)>::call<QtPrivate::List<QString>, void>(f=f0 db 26 00 00 00 00 00 00 00 00 00 00 00 00 00, o=0x00000000002a2ca0, arg=0x0000000802143438)(QString), ObjectManage
r*, void**) at qobjectdefs_impl.h:185:13
    frame #5: 0x00000000002469d5 bsdisks`QtPrivate::QSlotObject<void (ObjectManager::*)(QString), QtPrivate::List<QString>, void>::impl(which=1, this_=0x00000008019dd640, r=0x00000000002a2ca0, a=0x0000000802143438, ret=0x0000000000000000) at qobjectdefs_impl.h:418
:17
    frame #6: 0x000000080086ddcd libQt5Core.so.5`QObject::event(QEvent*) + 813
    frame #7: 0x000000080084261d libQt5Core.so.5`QCoreApplicationPrivate::notify_helper(QObject*, QEvent*) + 109
    frame #8: 0x0000000800842220 libQt5Core.so.5`QCoreApplication::notifyInternal2(QObject*, QEvent*) + 176
    frame #9: 0x00000008008432b9 libQt5Core.so.5`QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 761
    frame #10: 0x000000080089bec8 libQt5Core.so.5`___lldb_unnamed_symbol2603$$libQt5Core.so.5 + 24
    frame #11: 0x00000008016b8c8e libglib-2.0.so.0`g_main_context_dispatch + 366
    frame #12: 0x00000008016b9034 libglib-2.0.so.0`___lldb_unnamed_symbol121$$libglib-2.0.so.0 + 548
    frame #13: 0x00000008016b90f6 libglib-2.0.so.0`g_main_context_iteration + 102
    frame #14: 0x000000080089b900 libQt5Core.so.5`QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 96
    frame #15: 0x000000080083e467 libQt5Core.so.5`QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 567
    frame #16: 0x00000008008428be libQt5Core.so.5`QCoreApplication::exec() + 142
    frame #17: 0x000000000023ff6d bsdisks`main(argc=1, argv=0x00007fffffffdf08) at main.cpp:161:5
    frame #18: 0x000000000022bab0 bsdisks`_start + 256
(lldb)
Comment 3 Gleb Popov freebsd_committer freebsd_triage 2021-03-28 13:40:00 UTC
Thanks for the report.

The correct fix for this bug requires changes in FreeBSD base, reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254625

For now, I worked around the issue in following upstream commit: https://foss.heptapod.net/bsdutils/bsdisks/-/commit/e0e705f78ff9ae710eb022941e5e4032619ffcbb

Please, try this out and report if it fixes the problem for you.
Comment 4 Martin Birgmeier 2021-03-28 15:47:03 UTC
Hi Gleb,

Thank you for the patch. There is no coredump anymore, but still an issue: While the disk is mounted manually, it is still shown as a mountable device in "Disks & Devices" in the KDE toolbar. But v0.24 does the same.

Isn't this current issue pretty much the same as bug #248531?

-- Martin
Comment 5 Gleb Popov freebsd_committer freebsd_triage 2021-03-28 20:58:46 UTC
(In reply to Martin Birgmeier from comment #4)
> Thank you for the patch. There is no coredump anymore, but still an issue: While the disk is mounted manually, it is still shown as a mountable device in "Disks & Devices" in the KDE toolbar. But v0.24 does the same.

Yep, this is due to bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254625
which is not easy to fix right away.

> Isn't this current issue pretty much the same as bug #248531?

Nope, despite the same symptoms this one is caused by a different event.

I'll release a new version with this fix soon.
Comment 6 commit-hook freebsd_committer freebsd_triage 2021-04-15 11:45:21 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=2905efd87782c3ca2a07401ebdde0e6850e64219

commit 2905efd87782c3ca2a07401ebdde0e6850e64219
Author:     Gleb Popov <arrowd@FreeBSD.org>
AuthorDate: 2021-04-15 11:43:23 +0000
Commit:     Gleb Popov <arrowd@FreeBSD.org>
CommitDate: 2021-04-15 11:44:26 +0000

    sysutils/bsdisks: Update to 0.26

    PR:             254459

 sysutils/bsdisks/Makefile | 6 +++---
 sysutils/bsdisks/distinfo | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)