Comment 1 Graham Perrin 2021-02-01 04:53:33 UTC

Does the fix for bug 248531 (core dump when ejecting FAT-formatted SD card) help to think about this bug 253149?

The reason for me using an extension cable to make the connection was to minimise the risk of an interruption to physical connectivity at the base of the phone (where contacts _might_ be a little dirty, although I did jiggle the connection there – after the event – with no sign of trouble).

Comment 2 Gleb Popov 2021-02-01 06:51:56 UTC

CAM errors in your log looks suspicious. Especially,

Feb  1 04:31:00 mowa219-gjp4-8570p kernel: (cd1:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)

Are you sure that your world/kernel are in a consistent state?

Anyways, most likely bsdisks is missing a check for errno somewhere. It'd helpful if you rebuild this port with WITH_DEBUG=yes and get a backtrace for the crash.

Comment 3 Graham Perrin 2021-02-01 07:39:19 UTC

(In reply to Gleb Popov from comment #2)

> … sure that your world/kernel are in a consistent state? …

Certain; the output from freebsd-version -kru

> … rebuild this port with WITH_DEBUG=yes …

OK

Comment 4 Gleb Popov 2021-02-11 05:43:19 UTC

(In reply to Graham Perrin from comment #3)
Managed to make any progress on this?

Here are detailed steps to set up for debugging:

- Compile the port WITH_DEBUG=yes, or build bsdisks from source with simple `cmake -DCMAKE_BUILD_TYPE=Debug <path_to_source> && make && make install`

- Before starting X run `gdb /usr/local/bin/bsdisks` and start the process.

- Start X and try reproduce the crash.

- Get the backtrace from the GDB.

Comment 5 Graham Perrin 2021-03-18 07:27:28 UTC

Sorry for the inactivity here, I did very little with disks recently, might do more in a few weeks.

Comment 6 Gleb Popov 2021-03-18 07:31:35 UTC

(In reply to Graham Perrin from comment #5)
Make sure to use bsdisks-0.25, which contains a lot of stability fixes.

Comment 7 Graham Perrin 2021-03-20 15:46:14 UTC

(In reply to Gleb Popov from comment #6)

<https://www.freshports.org/sysutils/bsdisks/#packages> I look forward to a package for FreeBSD:14:amd64 I'm in no rush :-)

Comment 8 Graham Perrin 2021-12-26 12:50:56 UTC

Occasional infrequent crashes with 0.26. I should aim to debug properly in due course. In the meantime: 


% grep -B 10 bsdisks /var/log/messages
Dec 17 10:02:46 mowa219-gjp4-8570p-freebsd kernel: umass1 on uhub2
Dec 17 10:02:46 mowa219-gjp4-8570p-freebsd kernel: umass1: <Kingston DataTraveler 3.0, class 0/0, rev 3.10/0.01, addr 5> on usbus0
Dec 17 10:02:46 mowa219-gjp4-8570p-freebsd kernel: da1 at umass-sim1 bus 1 scbus5 target 0 lun 0
Dec 17 10:02:46 mowa219-gjp4-8570p-freebsd kernel: da1: <Kingston DataTraveler 3.0 > Removable Direct Access SPC-4 SCSI device
Dec 17 10:02:46 mowa219-gjp4-8570p-freebsd kernel: da1: Serial Number E0D55EA1C84FF390A9500FDA
Dec 17 10:02:46 mowa219-gjp4-8570p-freebsd kernel: da1: 400.000MB/s transfers
Dec 17 10:02:46 mowa219-gjp4-8570p-freebsd kernel: da1: 29510MB (60437492 512 byte sectors)
Dec 17 10:02:46 mowa219-gjp4-8570p-freebsd kernel: da1: quirks=0x2<NO_6_BYTE>
Dec 17 10:02:45 mowa219-gjp4-8570p-freebsd ZFS[36677]: vdev state changed, pool_guid=1913339710710793892 vdev_guid=8248197705860927698
Dec 17 10:02:50 mowa219-gjp4-8570p-freebsd ZFS[36692]: vdev state changed, pool_guid=1913339710710793892 vdev_guid=7869384475889215193
Dec 17 10:02:53 mowa219-gjp4-8570p-freebsd kernel: pid 4428 (bsdisks), jid 0, uid 0: exited on signal 11 (core dumped)
--
Dec 21 13:08:10 mowa219-gjp4-8570p-freebsd syslogd: last message repeated 1 times
Dec 21 13:12:27 mowa219-gjp4-8570p-freebsd syslogd: last message repeated 2 times
Dec 21 13:25:26 mowa219-gjp4-8570p-freebsd syslogd: last message repeated 2 times
Dec 21 13:26:03 mowa219-gjp4-8570p-freebsd gnome-keyring-daemon[11840]: asked to register item /org/freedesktop/secrets/collection/Default_5fkeyring/814, but it's already registered
Dec 21 13:53:20 mowa219-gjp4-8570p-freebsd kernel: ugen1.10: <Android Android> at usbus1 (disconnected)
Dec 21 13:53:20 mowa219-gjp4-8570p-freebsd kernel: umass2: at uhub7, port 2, addr 10 (disconnected)
Dec 21 13:53:20 mowa219-gjp4-8570p-freebsd kernel: cd1 at umass-sim2 bus 2 scbus6 target 0 lun 0
Dec 21 13:53:20 mowa219-gjp4-8570p-freebsd kernel: cd1: <OnePlus Device Driveret 0310>  detached
Dec 21 13:53:20 mowa219-gjp4-8570p-freebsd kernel: (cd1:umass-sim2:2:0:0): Periph destroyed
Dec 21 13:53:20 mowa219-gjp4-8570p-freebsd kernel: umass2: detached
Dec 21 13:53:21 mowa219-gjp4-8570p-freebsd kernel: pid 2127 (bsdisks), jid 0, uid 0: exited on signal 11 (core dumped)
% uptime
12:47p.m.  up  4:14, 5 users, load averages: 1.48, 1.46, 1.28
% pkg info -x bsdisks
bsdisks-0.26
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #118 main-n251923-4bae154fe8c: Sat Dec 25 08:03:37 GMT 2021     root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  amd64 1400045 1400045
%

Comment 9 Graham Perrin 2021-12-26 19:11:26 UTC

I used poudriere to build WITH_DEBUG=yes, forced reinstallation of the package (from my poudriere repo), logged out from KDE Plasma, stopped SDDM, killed the bsdisks process, ran this command as root at ttyv3: 

gdb /usr/local/bin/bsdisks

– then used ttyv2 to start SDDM. 

Logged in to Plasma, reproduced a crash, nothing apparent at ttyv3, so I exited from gdb. 

I can't find the .core file (I'm not sure where to look in this situation.)

Please, what am I missing? ELI5 or 15 (I rarely touch things such as gdb.) Thanks. 

----

% tail -f -n 0 /var/log/messages
Dec 26 18:56:44 mowa219-gjp4-8570p-freebsd kernel: ugen1.9: <Android Android> at usbus1
Dec 26 18:56:44 mowa219-gjp4-8570p-freebsd kernel: umass3 on uhub5
Dec 26 18:56:44 mowa219-gjp4-8570p-freebsd kernel: umass3: <Mass Storage> on usbus1
Dec 26 18:56:44 mowa219-gjp4-8570p-freebsd kernel: cd1 at umass-sim3 bus 3 scbus7 target 0 lun 0
Dec 26 18:56:44 mowa219-gjp4-8570p-freebsd kernel: cd1: <OnePlus Device Driveret 0310> Fixed CD-ROM SCSI-2 device
Dec 26 18:56:44 mowa219-gjp4-8570p-freebsd kernel: cd1: 40.000MB/s transfers
Dec 26 18:56:44 mowa219-gjp4-8570p-freebsd kernel: cd1: 10MB (5281 2048 byte sectors)
Dec 26 18:56:44 mowa219-gjp4-8570p-freebsd kernel: cd1: quirks=0x10<10_BYTE_ONLY>
Dec 26 18:56:44 mowa219-gjp4-8570p-freebsd webcamd[38068]: webcamd: Cannot find USB device
Dec 26 18:56:56 mowa219-gjp4-8570p-freebsd kernel: ugen1.9: <Android Android> at usbus1 (disconnected)
Dec 26 18:56:56 mowa219-gjp4-8570p-freebsd kernel: umass3: at uhub5, port 6, addr 9 (disconnected)
Dec 26 18:56:56 mowa219-gjp4-8570p-freebsd kernel: cd1 at umass-sim3 bus 3 scbus7 target 0 lun 0
Dec 26 18:56:56 mowa219-gjp4-8570p-freebsd kernel: cd1: <OnePlus Device Driveret 0310>  detached
Dec 26 18:56:56 mowa219-gjp4-8570p-freebsd kernel: (cd1:umass-sim3:3:0:0): Periph destroyed
Dec 26 18:56:56 mowa219-gjp4-8570p-freebsd kernel: umass3: detached
Dec 26 18:56:57 mowa219-gjp4-8570p-freebsd kernel: pid 37641 (bsdisks), jid 0, uid 0: exited on signal 11 (core dumped)
Dec 26 18:57:56 mowa219-gjp4-8570p-freebsd devd[36772]: check_clients:  dropping disconnected client
^C
% grep bsdisks /var/log/messages
Dec 17 10:02:53 mowa219-gjp4-8570p-freebsd kernel: pid 4428 (bsdisks), jid 0, uid 0: exited on signal 11 (core dumped)
Dec 21 13:53:21 mowa219-gjp4-8570p-freebsd kernel: pid 2127 (bsdisks), jid 0, uid 0: exited on signal 11 (core dumped)
Dec 26 18:46:14 mowa219-gjp4-8570p-freebsd pkg[35520]: bsdisks reinstalled: 0.26 -> 0.26 
Dec 26 18:56:57 mowa219-gjp4-8570p-freebsd kernel: pid 37641 (bsdisks), jid 0, uid 0: exited on signal 11 (core dumped)
% grep WITH_DEBUG /usr/local/etc/poudriere.d/make.conf | grep -v \#
WITH_DEBUG=yes
%

Comment 10 Graham Perrin 2021-12-26 19:24:39 UTC

Created attachment 230429 [details]
Output from a run of bsdisks as root

(In reply to Graham Perrin from comment #9)

> Please, what am I missing? 

I realised one of my mistakes :-) 

I'm this far, but it's probably useless for debugging purposes: 

----

root@mowa219-gjp4-8570p-freebsd:~ # gdb -c ./bsdisks.core 
…
[New LWP 101786]
[New LWP 116721]
[New LWP 116722]
[New LWP 116723]
[New LWP 116724]
[New LWP 116725]
[New LWP 116726]
Core was generated by `/usr/local/bin/bsdisks'.
Program terminated with signal SIGSEGV, Segmentation fault.
Address not mapped to object.
#0  0x0000000000242cf7 in ?? ()
[Current thread is 1 (LWP 101786)]
(gdb) bt
#0  0x0000000000242cf7 in ?? ()
#1  0x0000000815710380 in ?? ()
#2  0x000000000026eca0 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) q
root@mowa219-gjp4-8570p-freebsd:~ # ls -hl bsdisks.core 
-rw-------  1 root  wheel    68M Dec 26 19:13 bsdisks.core
root@mowa219-gjp4-8570p-freebsd:~ # 

----

Instead, from near the tail of the attached file, this might be enough for other people to make the bug reproducible: 

Created block  "cd1"
Finished FS probe on  "cd1"
Finished GEOM probe on  "cd1"
"Registering /org/freedesktop/UDisks2/block_devices/cd1"
"Unregistering /org/freedesktop/UDisks2/block_devices/cd1"
Segmentation fault (core dumped)


### Steps to reproduce

1. make a USB connection to a OnePlus 2 mobile phone

2. disconnect

Comment 11 Gleb Popov 2021-12-26 19:44:43 UTC

If you used

# gdb /usr/local/bin/bsdisks

command to start bsdisks, then once it crashed just switch into the terminal in which you ran gdb. You'll get into gdb command prompt and then use "bt" command to print a backtrace.

You can also share a .core file with me, maybe I can figure something out.

Comment 12 Graham Perrin 2021-12-26 20:12:17 UTC

(In reply to Gleb Popov from comment #11)

> If you used
> 
> # gdb /usr/local/bin/bsdisks
> 
> command to start bsdisks, 

I did, originally, 

> then once it crashed just switch into the terminal in which you ran gdb. 
> You'll get into gdb command prompt and then use "bt" command to print a 
> backtrace.

There was nothing in response to bt, which made me wonder whether the build was truly debug-enabled. 

% grep WITH_DEBUG /usr/local/etc/poudriere.d/make.conf | grep -v \#
WITH_DEBUG=yes
%

– so I assume that it _was_ enabled, however I shouldn't take this bug report too far off-topic.

Comment 13 Graham Perrin 2021-12-26 20:14:54 UTC

Created attachment 230430 [details]
Output from /usr/local/bin/bsdisks --debug-devd

Comment 14 Graham Perrin 2021-12-26 20:19:30 UTC

(In reply to Gleb Popov from comment #11)

> … You can also share a .core file with me, …

With you personally, or attach here? 

(I can't guess whether this type of .core file might contain sensitive information.)

bsdisks.core.tar.gz is 12M, however I wonder whether it will be useful. As before: 

#0  0x0000000000242cf7 in ?? ()
#1  0x000000081487a580 in ?? ()
#2  0x000000000026eca0 in ?? ()
#3  0x0000000000000000 in ?? ()

Comment 15 Gleb Popov 2021-12-27 15:34:51 UTC

(In reply to Graham Perrin from comment #14)
The .core file shouldn't contain anything confidential, so you can share it here.

You can check if the executable is build with debugging enabled by running

file /usr/local/bin/bsdisks

Comment 16 Graham Perrin 2021-12-27 18:16:05 UTC

(In reply to Gleb Popov from comment #15)

Thanks!

% file /usr/local/bin/bsdisks
/usr/local/bin/bsdisks: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 14.0 (1400045), FreeBSD-style, with debug_info, not stripped
%

Comment 17 Gleb Popov 2021-12-27 18:19:07 UTC

(In reply to Graham Perrin from comment #16)
Looks good. To get a meaningful backtrace you probably need to put bsdisks sources into a correct directory:

# make -C /usr/ports/sysutils/bsdisks patch WRKDIRPREFIX=/wrkdirs

This is assuming you used poudriere to build bsdisks.

Comment 18 Graham Perrin 2021-12-27 18:28:51 UTC

(In reply to Gleb Popov from comment #11)

Compressed .core files are too large to attach in this case. 

Instead, for the most recent crash: 

<https://mega.nz/folder/UFMTUIiQ#YbIR4WFMl-sGYyhrVjZluA>

If it helps: I suspect that this type of crash occurs only whilst I use KDE Plasma. 

Also, for as long as gdb is _attached to_ a bsdisks process, the crash might not occur: 

* I could repeatedly connect and disconnect the Android device

* with the device finally disconnected, a crash was observed 
  immediately after I ceased using gdb.

Comment 19 Gleb Popov 2021-12-27 18:36:04 UTC

(In reply to Graham Perrin from comment #18)
Please share the bsdisks executable itself too, I need it to inspect the core file.

Comment 20 Graham Perrin 2021-12-27 19:05:09 UTC

(In reply to Gleb Popov from comment #19)

Uploaded to the MEGA area: 

bsdisks, comment 19.tar.gz

If I get a .core file with a different build of the binary (poudriere running now), I'll upload with distinctive file names.

Comment 21 Gleb Popov 2021-12-27 19:19:39 UTC

Created attachment 230464 [details]
Patch

Can you please try out this patch? Drop it into sysutils/bsdisks/files directory and rebuild the port.

Comment 22 Graham Perrin 2021-12-27 20:25:21 UTC

Created attachment 230466 [details]
Screenshot: multiple disconnections, no crash

(In reply to Gleb Popov from comment #21)

The result appears good, many thanks! 

Relevant history for the tab in the Konsole window to the right (commands run as root): 

  2008  20:14   pkill bsdisks
  2009  20:15   date ; uptime
  2010  20:15   bsdisks &

----

I'll lock the installed package (for now), restart the OS, allow the daemon to start in the normal way and continue to test.

Comment 23 Gleb Popov 2021-12-27 20:44:00 UTC

(In reply to Graham Perrin from comment #22)
Good to hear. Another piece of info I'm interested in:

# cat /var/run/devd.pipe

<insert your device that was causing a crash>
<remove it>

Post the output of the cat command.

Comment 24 Graham Perrin 2021-12-27 21:12:12 UTC

Created attachment 230468 [details]
Output from cat /var/run/devd.pipe

(In reply to Gleb Popov from comment #23)

Comment 25 Gleb Popov 2021-12-28 12:39:34 UTC

Indeed, devd doesn't send the

!system=GEOM subsystem=disk type=GEOM::physpath devname=cd1

event, so bsdisks doesn't create a drive object for "cd1".

Can you also please show an output of

# geom disk list

when the USB device is inserted? Specifically, I'm interested if there is an entry for "cd1".

Comment 26 Graham Perrin 2021-12-28 15:30:08 UTC

(In reply to Gleb Popov from comment #25)

% geom disk list cd1
Geom name: cd1
Providers:
1. Name: cd1
   Mediasize: 10815488 (10M)
   Sectorsize: 2048
   Mode: r0w0e0
   descr: OnePlus Device Driver\000et
   ident: (null)
   rotationrate: unknown
   fwsectors: 0
   fwheads: 0

% 

(Nothing else relevant in broader output from geom disk list.)

When mounted: 

% ls -ahl /media/OnePlus_Device_Driver\\000et_/
total 11
dr-xr-xr-x  1 root  wheel   2.0K  1 Jan  1970 .
drwxr-xr-x  4 root  wheel     4B 28 Dec 15:25 ..
-r-xr-xr-x  1 root  wheel   107B 29 May  2015 autorun.inf
-r-xr-xr-x  1 root  wheel    10M 29 May  2015 OnePlus_USB_Drivers_Setup.exe
%

Comment 27 Graham Perrin 2021-12-28 15:46:28 UTC

Created attachment 230498 [details]
Screenshot of Dolphin after eject results in an unmount

Incidentally, if I use the context menu in the sidebar of Dolphin to mount the volume (without opening a tab to its content), then _eject_, there's a red alert: 

> The requested operation has failed: Invalid argument

– then I find the volume no longer mounted. 

----

No such alert if I use the context menu to _release_. This, too, results in the volume no longer mounted. 

----

I don't imagine that what's above is a bsdisks bug. I should refrain from reporting it separately until after 253149 is fixed.

Comment 28 Gleb Popov 2021-12-28 15:50:03 UTC

(In reply to Graham Perrin from comment #27)
Can you check where the media gets mounted to in both cases? You can do this by running "mount" without arguments.

And am I correct that the initial problem is solved with the attached patch?

Comment 29 Graham Perrin 2021-12-28 16:01:53 UTC

(In reply to Gleb Popov from comment #28)

Correct, apparently fixed (no crashes observed). 

----

/media/OnePlus_Device_Driver\000et_

* true for use of the sidebar of Dolphin, with or without the context menu

* true for the Removal Devices widget, in a Plasma system tray. 

(If I use the widget to eject, there's the same red alert in Dolphin.)

Comment 30 Gleb Popov 2021-12-28 16:12:57 UTC

I wonder if this is due to the strange "\000et_" part of the pathname.(In reply to Graham Perrin from comment #29)

What happens if you unmount it manually with

# umount /media/OnePlus_Device_Driver\000et_

? Any error messages?

Comment 31 Graham Perrin 2021-12-28 17:04:28 UTC

(In reply to Gleb Popov from comment #30)

There's failure in the absence of an \ escape charater. 

root@mowa219-gjp4-8570p-freebsd:~ # umount /media/OnePlus_Device_Driver\000et_
umount: /media/OnePlus_Device_Driver000et_: statfs: No such file or directory
umount: /media/OnePlus_Device_Driver000et_: unknown file system
root@mowa219-gjp4-8570p-freebsd:~ # umount /media/OnePlus_Device_Driver\\000et_
root@mowa219-gjp4-8570p-freebsd:~ # 

In both cases: no red alert in Dolphin.

Comment 32 Gleb Popov 2021-12-28 17:29:32 UTC

Created attachment 230502 [details]
Patch

Can you try out this patch too? It also can just be dropped into sysutils/bsdisks/files directory.

Comment 33 Graham Perrin 2021-12-28 17:49:36 UTC

(In reply to Gleb Popov from comment #32)

% ls -hl /usr/local/poudriere/ports/default/sysutils/bsdisks/files
total 1
-rw-r--r--  1 root  wheel   563B 28 Dec 17:31 patch-blockfilesystem.cpp
-rw-r--r--  1 root  wheel   448B 27 Dec 19:46 patch-devdthread.cpp
% 

… then built and packaged with poudriere, then installed. No improvement, as far as I can tell. 

… 
Created block  "cd1"
Created drive  "cd1"
Finished FS probe on  "cd1"
"Registering /org/freedesktop/UDisks2/drives/cd1"
Finished GEOM probe on  "cd1"
"Registering /org/freedesktop/UDisks2/block_devices/cd1"
chown of  "/media/OnePlus_Device_Driver000et_"  to  "1002"
Eject failed:  "Invalid argument"
chown of  "/media/OnePlus_Device_Driver000et_"  to  "1002"
Eject failed:  "Invalid argument"

----

IMHO this is a minor issue, a nit. I didn't intend to broaden the scope of this bug (I imagined an issue at a Plasma level), would you like me to spin off to a separate bug? Or continue here? 

Thanks again

Comment 34 Gleb Popov 2021-12-28 17:54:50 UTC

(In reply to Graham Perrin from comment #33)
This patch made the "\" symbol go away. Ok, now we know that it wasn't the cause.

Comment 35 Graham Perrin 2021-12-28 19:03:43 UTC

(In reply to Gleb Popov from comment #32)

% ls -hlrt /usr/local/poudriere/ports/default/sysutils/bsdisks/files
total 1
-rw-r--r--  1 root  wheel   448B 27 Dec 19:46 patch-devdthread.cpp
-rw-r--r--  1 root  wheel   563B 28 Dec 17:31 patch-blockfilesystem.cpp
-rw-r--r--  1 root  wheel   559B 28 Dec 18:52 patch-253149-comment32.cpp
% 

…

% tail -n 20 /usr/local/poudriere/data/logs/bulk/main-default/2021-12-28_18h52m37s/logs/errors/bsdisks-0.26.log
===== env: DEVELOPER_MODE=yes USE_PACKAGE_DEPENDS_ONLY=1 USER=root UID=0 GID=0
===========================================================================
=======================<phase: patch          >============================
===== env: DEVELOPER_MODE=yes DEVELOPER=1 STRICT_DEPENDS=yes USER=root UID=0 GID=0
===>  Patching for bsdisks-0.26
===>  Applying FreeBSD patches for bsdisks-0.26 from /usr/ports/sysutils/bsdisks/files
Ignoring previously applied (or reversed) patch.
1 out of 1 hunks ignored--saving rejects to blockfilesystem.cpp.rej
===>  FAILED Applying FreeBSD patch-blockfilesystem.cpp
===> Cleanly applied FreeBSD patch(es)  patch-253149-comment32.cpp
===> FAILED to apply cleanly FreeBSD patch(es)  patch-blockfilesystem.cpp
*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/bsdisks
=>> Cleaning up wrkdir
===>  Cleaning for bsdisks-0.26
build of sysutils/bsdisks | bsdisks-0.26 ended at Tue Dec 28 19:00:18 GMT 2021
build time: 00:00:01
!!! build failure encountered !!!
%

Comment 36 Graham Perrin 2021-12-28 19:05:59 UTC

Sorry, I'm not sure what's going on here at the moment, it's as if things are disappearing from Bugzilla then reappearing (I'm certain that I keyed Control-F5 for the most up-to-date view but things now might be muddled).

Comment 37 Gleb Popov 2021-12-29 09:11:09 UTC

Created attachment 230530 [details]
Patch

Can you please do another test? Remove all patches from sysutils/bsdisks/files and then place this one there. Rebuild the port and check that initial problem (the crash) is still gone.

Comment 38 Graham Perrin 2021-12-29 10:09:28 UTC

Created attachment 230532 [details]
Screenshot: multiple disconnections, no crash, connected but not detected by the widget of Plasma

(In reply to Gleb Popov from comment #37)

No crash on disconnect. Good. 

No detection by the Disks & Devices widget of Plasma.

I can use Dolphin to mount and sanely unmount _without_ the previously observed red alert. Good. 

The apparent red underline, in Dolphin, is new to me. 

----

My system (CURRENT) felt a _little_ flaky before my most recent log in to KDE, so I'd like to restart then retest. 

In the meantime, I'll attach output from Konsole.

Comment 39 Graham Perrin 2021-12-29 10:10:45 UTC

Created attachment 230533 [details]
Output from Konsole.

(In reply to Graham Perrin from comment #38)

Comment 40 Graham Perrin 2021-12-29 10:14:59 UTC

(In reply to Graham Perrin from comment #39)

Sorry, I forgot to comment there. Re: the tail of the run of bsdisks, 

chown of  "/media/OnePlus_Device_Driver\\000et_"  to  "1002"
"umount: unmount of /media/OnePlus_Device_Driver\\000et_ failed: Device busy\n"
"umount: /media/OnePlus_Device_Driver\\\\000et_: statfs: No such file or directory\numount: /media/OnePlus_Device_Driver\\\\000et_: unknown file system\n"
"umount: /media/OnePlus_Device_Driver\\\\000et_: statfs: No such file or directory\numount: /media/OnePlus_Device_Driver\\\\000et_: unknown file system\n"

– the one failure was expected. An intentional insane attempt to unmount without first closing the Dolphin tab to the content of the volume. 

Is there proliferation of escape characters?

Comment 41 Gleb Popov 2021-12-29 12:45:02 UTC

Created attachment 230536 [details]
Patch

(In reply to Graham Perrin from comment #38)
> No detection by the Disks & Devices widget of Plasma.

Ouch, this is bad. This means my previous patch is also a hack, not a correct fix.

All right, once again remove all patches in use this one.

> The apparent red underline, in Dolphin, is new to me. 

This is a free space indicator. It is red because the device presents itself as a CD for some reason.

Comment 42 Graham Perrin 2021-12-29 14:32:33 UTC

(In reply to Gleb Popov from comment #41)

Patched, tested, then compared with the packaged (non-patched) version from the FreeBSD repo. 

Now, even with the non-patched version: it seems that I _sometimes_ 
_do not_ get recognition by the widget; no pop-up in response to a connection. 

----

There's the system flakiness that I mentioned earlier, most of which is cosmetic (appearance of Plasma), now I begin to wonder whether I have a broader set of symptoms, that's preventing me from giving you meaningful results. Sorry! 

Re: the flakiness, just FYI <https://forums.freebsd.org/threads/83524/>

Comment 43 Graham Perrin 2021-12-29 15:37:11 UTC

(In reply to Graham Perrin from comment #36)

Gleb, it may be sane to pause activity in Bugzilla until things become reliably orderly. FYI bug 260261 comment 13.

For now: big thanks!

Comment 44 Gleb Popov 2021-12-30 08:31:34 UTC

(In reply to Graham Perrin from comment #43)
I don't think the symptoms you're describing have any effect on bsdisks. So, if you don't see any regressions with the last patch, and the intial problem seems fixed too, I'm going to commit it.

Comment 45 Graham Perrin 2021-12-30 10:19:04 UTC

(In reply to Gleb Popov from comment #44)

I resolved my desktop environment issues (and was partly mistaken about issues with/affecting Bugzilla) so I'll retest with the latest patch. Building now. Thanks again.

Comment 46 Graham Perrin 2021-12-30 10:53:46 UTC

Created attachment 230554 [details]
Screenshot of Dolphin after repeatedly connecting then disconnecting

(In reply to Gleb Popov from comment #41)

I began with an (expected) crashing run of the non-patched release. 

Then a non-crashing run of the patched binary. Connected, disconnected a few times. Intentionally careless behaviour probably included:

* at least one disconnection _without_ first unmounting the volume

– not that this matters, for read-only cd9660. 

There remain some 'ghosts' in the Dolphin sidebar view of things. When I took the attached screenshot, the device was _not_ connected, however: 

* there appeared _two_ 'Removable Devices' sections in the sidebar
  (extraordinary); and 

* the device appeared connected, under 'Devices'

After taking the shot I tested a little more. After closing a Dolphin tab to the volume, a sidebar context menu release of just one of the multiple 'active' icons for the volume successfully resulted in an unmount, and most of the active icons switched to non-active (with the amber icon, which I can not quite make out). 

When I clicked (or maybe right-clicked) the one remaining active icon, Dolphin disappeared. Probably not a crash, I see no .core file, but we have this line in /var/log/messages: 

Dec 30 10:46:08 mowa219-gjp4-8570p-freebsd dbus-daemon[1740]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.60" (uid=0 pid=23751 comm="bsdisks ") interface="(unset)" member="(unset)" error name="org.freedesktop.UDisks2.Error.Failed" requested_reply="0" destination=":1.44" (uid=1002 pid=3765 comm="/usr/local/bin/dolphin ")


----

I'll restart the OS then test methodically, to tell whether any of what's above is _consistently_ reproducible. 

Continue in this bug, yes? Or spin off to something new for any aspect?

Comment 47 Gleb Popov 2021-12-30 11:17:20 UTC

Did you start bsdisks manually via terminal during your testing? If not, repeat the testing with manually started bsdisks to see if it crashes.

The repeated "ONEPLUS DRIVERS" item is usually a sign of crashed and automatically restarted bsdisks.

Comment 48 Graham Perrin 2021-12-30 11:37:12 UTC

(In reply to Gleb Popov from comment #47)

> Did you start bsdisks manually via terminal during your testing? 

Yes. 

Is what's below the preferred way to start, for test purposes? With /bin/csh preferred by me for the root user: 

bsdisks &

– I'm not sure whether the   &    is required for these types of test. 


> … The repeated "ONEPLUS DRIVERS" item is usually a sign of crashed and automatically 
> restarted bsdisks.

OK, thanks, that makes sense. For comparison, I did begin with a few manual runs of the non-patched crashing binary: 

* solely to check that the pop-up appeared, from the system tray, at least once. 

The next run of Dolphin – with the patched non-crashing patched binary already running – was free from repetition in the sidebar. 

----

I'll now restart, log in to Plasma, kill bsdisks then run it manually per your advice.

Comment 49 Gleb Popov 2021-12-30 11:40:27 UTC

(In reply to Graham Perrin from comment #48)
Adding & at the end of the command makes it detach from the terminals stdin. You will still be able to see what it prints, but since you can run other commands in this terminal, you might miss the fact that it crashed, so pay attention to that.

> Continue in this bug, yes? Or spin off to something new for any aspect?

As far as the intial crash can't be reproduced anymore, I think this bug can be closed.

Comment 50 Graham Perrin 2021-12-30 12:03:52 UTC

+1 to closure. Thanks for your patience and guidance! I look forward to the commit.

Comment 51 commit-hook 2022-01-17 11:30:39 UTC

A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=46588a8950a137c371683e79c54598cf112e3fec

commit 46588a8950a137c371683e79c54598cf112e3fec
Author:     Gleb Popov <arrowd@FreeBSD.org>
AuthorDate: 2022-01-17 11:29:06 +0000
Commit:     Gleb Popov <arrowd@FreeBSD.org>
CommitDate: 2022-01-17 11:29:06 +0000

    sysutils/bsdisks: Update to 0.27

    PR:             253149

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