Project

General

Profile

Bug #11738

DT 2.2.5 stuck when portable phone connected by USB for charging

Added by Sergei Rybalko over 1 year ago. Updated 6 months ago.

Status:
Confirmed
Priority:
Medium
Assignee:
-
Category:
-
Start date:
09/13/2017
Due date:
% Done:

10%

Affected Version:
git master branch
System:
Debian
bitness:
64-bit
hardware architecture:
amd64/x86

Description

DT stuck when portable phone connected by USB for charging. I found it accidentally. Once I attached my portable phone by USB for charging and open DT for edit, in several seconds DT stuck and crashed after. I repeated opening with same result. After some time I realized that the only change I did was plugging my phone to USB. When I unplugged it DT stared working fluently as previously.


Related issues

Related to darktable - Bug #10624: Having mounted a Smartphone may be confusing Incomplete 08/31/2015

History

#1 Updated by Tobias Ellinghaus over 1 year ago

  • Related to Bug #10624: Having mounted a Smartphone may be confusing added

#2 Updated by Tobias Ellinghaus over 1 year ago

  • Status changed from New to Incomplete
  • % Done changed from 0 to 20

In the past we saw hangs when a phone was attached. Crashes are new. Do you happen to have a backtrace? /tmp/dt* might have one.

#3 Updated by Sergei Rybalko over 1 year ago

Tobias Ellinghaus wrote:

In the past we saw hangs when a phone was attached. Crashes are new. Do you happen to have a backtrace? /tmp/dt* might have one.

OK, it will not crash it will stuck and become unresponsive.

#4 Updated by Tobias Ellinghaus over 1 year ago

Could you try running dt in gdb, wait for it to hang and get a backtrace?

The steps are:

gdb darktable
r

wait for the deadlock and switch back to the terminal

ctrl-c
set pagination off
set logging file gdb.txt
set logging on
thread apply all bt full
q
y

Then attach gdb.txt to this bug.

#5 Updated by Sergei Rybalko over 1 year ago

After update my system and restart the computer I cannot reproduce this bug

Tobias Ellinghaus wrote:

Could you try running dt in gdb, wait for it to hang and get a backtrace?

The steps are:

[...]

wait for the deadlock and switch back to the terminal

[...]

Then attach gdb.txt to this bug.

#6 Updated by Tobias Ellinghaus over 1 year ago

  • Status changed from Incomplete to Closed: invalid
  • % Done changed from 20 to 0

Thanks for getting back to us. Should it happen again we can just re-open the bug.

#7 Updated by Roman Lebedev over 1 year ago

  • Target version set to 2.4.0

#8 Updated by Roman Lebedev about 1 year ago

  • Status changed from Closed: invalid to Confirmed
  • Priority changed from Low to Medium
  • Target version changed from 2.4.0 to Candidate for next minor release
  • % Done changed from 0 to 10
  • Affected Version changed from 2.2.5 to git master branch

There were two users with this problem today in IRC. one with 2.4.0, one with debian stable (so either 2.2.5 or 2.2.1).
Removing the phone solved the problem for the second user.

How about not scanning for camera on startup, but only once asked for?
I strongly believe it would be better than introducing rather mysterious hangs.

#9 Updated by Tobias Ellinghaus about 1 year ago

Did anyone of them provide a backtrace?

#10 Updated by Roman Lebedev about 1 year ago

No

#11 Updated by Fred Smith 6 months ago

I've experienced this recently on 2.4.0/Fedora 28.

This is with an Android phone, plugged in and charging - it's recognised and "mounted" as an MTP device, although with Android set to "charge only" - this means that e.g. in Nautilus GNOME Files, the device is shown as mounted, and its navigable at e.g. mtp://%5Busb%3A002,011%5D/, but shows as an empty location (in contrast, if "transfer files" is enabled on the phone, it's shown as an MTP device but that location has subfolder(s) (e.g. sdcard0 for internal storage).

When Darktable is run, it functions for some tens of seconds normally, then suddenly starts freezing for long periods (10+ seconds) - though it eventually responds to the last user interaction briefly, before freezing immediately again.

Running strace darktable, the last message during a freeze is:

poll([{fd=18, events=POLLIN}, {fd=20, events=POLLIN}, {fd=21, events=POLLOUT}], 3, 60000

Every freeze, the same poll event is shown.

/proc/$(pidof darktable)/fd/21 points to /dev/bus/usb/002/011 (i.e. the bus location of the phone).

Without the phone attached, Darktable operates normally without freezing.

EDIT: freezing also occurs with the MTP device "unmounted" (i.e. not GIO-mounted). Which is probably expected really.

Also available in: Atom PDF