Segfault right after launch (solved, most likely caused by XP-Pen) about darktable HOT 20 OPEN

The issue is missing information. What is the driver version for the 3070 Ti? rpmfusion?

Please provide the output from -d common when you start darktable from terminal.

FYI, I'm on Fedora 40 KDE with Nvidia without any issues.

from darktable.

Don't use -d common on 4.8.0, that will likely not work as there was a bug.

Better use '-d pipe -d opencl' or upgrade to 4.8.1

from darktable.

There has been one other issue with some connected pen devices. Could you check after removing everything but mouse, keyboard, display?

from darktable.

darktable_bt_C42SR2.txt

Log with -d pipe -d opencl attached.

Oh, wasn't aware 4.8.1 is out. I checked the homepage before opening this issue, not checking here. I'll try that now.

from darktable.

4.8.1 crashes too. I counted while moving the mouse over the lighttable. It got unresponsive after about 10s and terminated after another 5 or so.

Log like above, but with the 4.8.1 appimage here from the github release:

@gi-man yes, drivers are from rpmfusion, followed their install page.
Can I provide anything else or is all the information about the driver included in the debug log?

darktable_bt_BE2IR2.txt

from darktable.

Oh, just noticed that the -d something outputs much more than what's written into the log.

Here's the missing console output for both 480 and 481:

pipe-opencl-481.log
pipe-opencl.log

from darktable.

Interesting log as it shows that dt crashes right after compiling the opencl stuff . I guess everything works correctly if you disable opencl?

from darktable.

Interesting log as it shows that dt crashes right after compiling the opencl stuff . I guess everything works correctly if you disable opencl?

Nope. See first bullet point in the entry post above.

Logs attached for ./darktable-4.8.1-x86_64.AppImage -d pipe -d opencl --disable-opencl | tee no-opencl-481.log

no-opencl-481.log
darktable_bt_RXSPR2.txt

from darktable.

Using 4.8.1 and no opencl, can you post the logfile from -d common and then from -d all? It doesnt appear to be an opencl issue.

from darktable.

Using 4.8.1 and no opencl, can you post the logfile from -d common and then from -d all? It doesnt appear to be an opencl issue.

-d common:
481-common.log
darktable_bt_LN3FR2.txt

-d all
481-all.log
darktable_bt_6A8NR2.txt

from darktable.

Have you tried on X11 ? BTW the logs still show opencl bein on :-)

from darktable.

Do you have LUA scripts? Did you recently modified a shortcut?

from darktable.

Have you tried on X11 ? BTW the logs still show opencl bein on :-)

You're probably looking at the latest log, which I posted on request of gi-man. Directly below your request is the "no-opencl.log", where you find this:

 0.1276 [opencl_init] opencl disabled due to explicit user request
 0.1276 [opencl_init] FINALLY: opencl PREFERENCE=ON is NOT AVAILABLE and NOT ENABLED.

Re X11: Nope. I have 2 additional displays plugged into my dock, and they don't work correctly with X11.

from darktable.

Do you have LUA scripts? Did you recently modified a shortcut?

All tests with you guys have been done after nuking .config/darktable, to make sure it's not a corrupted database or config file. So no, no LUA even downloaded, since it's not staying up long enough.

After the remark, that it looks as if the crash happened during opencl compile, I also removed various things from
.cache/

from darktable.

@dterrahe Ok, I created a fresh user and logged into a x11 session. Crash still happens.
Log created with -d all:

x11-dall.log
darktable_bt_NHFSR2.txt

Also, GDK_BACKEND=wayland is not set in my normal account. No, not running Xwayland

Also: How would an undefined key press trigger a crash? I'd not consider that a wayland issue, even if it would be responsible for sending phantasy keys. Shouldn't the keyboard handling code just ignore key events that are unassigned to an action?

But doing the x11 test on a fresh user IMO also rules out that it's some weird GDK setting or some other side effect just from configuration.

from darktable.

There has been one other issue with some connected pen devices. Could you check after removing everything but mouse, keyboard, display?

Whoa, that solved it, but in a weird way.
I first pulled just the XP-Pen, still crashed.
Then I did a power cycle and started without the dock and the additional displays disconnected, just the notebook on its own, and no crash. I then introduced the displays, then the USB dock back with no crash on any step. Finally I plugged the XP-Pen back in, and it still doesn't crash.

Now I did again a full power cycle with all devices back in as it was all the time, and it doesn't crash anymore.

So I guess the issue is solved, but in a pretty unsatisfactory way, because I have no idea what difference pulling all the plugs and replugging them would make, in contrast to the frequent power cycles I was doing anyways.

But at least I know what to try next time it happens (if).

There also was a kernel update this morning, so in theory this also could have made a difference, but I did a powercycle and darktable test right after that as well, and the crash still was there.

In hindsight, I should have removed the devices from the usb dock one by one, with a power cycle and test inbetween each, to safely narrow it down.

It's now running, even with my old config folder and database. Thanks all for your time.
If anybody still wants to analyze anything because there still might be an issue in dt, I'm happy to try things and provide logs.

from darktable.

Good to hear you can use dt again :-)

@dterrahe i am absolutely sure i saw you commenting here but can't find that any more ???

@DickerDackel you might want to change title and initial description for others to spot this issue...

BTW #17004 was the issue i remembered as a cross-reference

from darktable.

I think you should look at journalctl to see if you can identify the issue with the XP Pen.

from darktable.

Or maybe dbus?

from darktable.

Dug through journalctl, XP-Pen (or PenDev) was only mentioned during boot and without an error.

No idea about dbus, where (and if) it logs, ...

from darktable.