BadAccess (attempt to access private resource denied) - not starting

[elandorr]

Steps to reproduce the problem

Try to start the program.

What's going on? Describe the problem in as much detail as possible.

It won't start, failing with some X error that a user can't hope to debug:

log

<all the included plugins listing>
starting plugin FFMPEG audio player
selected output plugin: PulseAudio output plugin
INFO: from file /home/FOOOO/.config/deadbeef/playlists/0.dbpl
convgui: gtkui plugin not found
shellexecui: can't find gtkui plugin
gtkui plugin compiled for gtk version: 2.16.0
The program 'deadbeef' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAccess (attempt to access private resource denied)'.
  (Details: serial 8 error_code 10 request_code 33 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Information about the software:

Deadbeef version: latest stable from your website, deadbeef 1.9.6 [static] [portable]
OS: linux 6.8.2

Every imaginable piece of GTK is installed: https://privatebin.net/?61b593b7734d10cb#WrWtei2xGcV7zzvnNz9xSd6kagTyiMgmuYncb7N94RT

[Oleksiy-Yakovenko]

Which OS?

[elandorr]

OS: linux 6.8.2

If you mean distribution: That is merely a list of packages with a branding. All gtk related packages can be found in the list above. (tldr all are installed up to gtk4)
If you need any specific version numbers, please let me know. I don't know what I'm looking for based on that error.

(But if you must know, plain Debian.)

[Oleksiy-Yakovenko]

I need to know specific version / build of your installed OS, so that I can install it in a VM and try reproducing your problem.
Just "Debian" would not cut it -- I know for sure that deadbeef works fine on Debian.
Also I need to see the full deadbeef start log, including the plugin list.

[Oleksiy-Yakovenko]

One thing that you can try is fully delete ~/.config/deadbeef folder, and delete any non-bundled deadbeef plugins.
Then see if it works after that.
If it does -- it may indicate that the problem was caused either by some plugin, or by using some configuration option.

[elandorr]

Already had removed external plugins so this is not going to look new to you:

https://privatebin.net/?26b067f7a1b77d2b#HnhH6z5cCWVVLBopsYGDiBidjj8kFEA43U39J3547bmd
full log

Recreating the entire system in a VM is not so easy: it's a "minimal" (well, until the programs pulled in 1000 deps) Debian with a custom 6.8.2.

But your latest comment did the trick:

Somehow a fresh config works!

I'll diff it and see if I can figure out what caused it and get back to you.

[elandorr]

As soon as this is removed, it starts again:

playback.loop 1

playback.volume.normalized 0.9857143
playlist.current 0
playlist.cursor.0 -1
playlist.cursor.1 7
playlist.cursor.2 0
playlist.scroll.0 -3
playlist.scroll.1 0
playlist.scroll.2 0
playlist.scroll.cursorfollowplayback 1
playlist.tab.00000 Default

resume.paused 0
resume.playlist -1
resume.position -1.000000
resume.track -1
resume_last_session 0

Not sure it can be narrowed down even further but I'll try.

[Oleksiy-Yakovenko]

So in order to trigger the problem, you are removing all these lines from the config file?

[Oleksiy-Yakovenko]

I tried doing this, and nothing happened, deadbeef still runs as usual.

[elandorr]

No, in order to fix the problem.

Original config: broken
New config: works
Original config with these lines removed: works

I diffed and started removing lines to see what causes the bug.

If I remove all these lines, db starts again with the original config no problem.

[elandorr]

Okay, it only worked once. After closing deadbeef and starting it again, the same bug reappears.

It modified the config.

If I remove the following lines, it starts again:

playback.volume.normalized 1.0000000
playlist.cursor.0 0
playlist.scroll.0 0
playlist.tab.00000 Default

As soon as I close+reopen it breaks again.

[Oleksiy-Yakovenko]

So let me confirm whether I understand the repro steps :

1. start deadbeef with empty config
2. quit, and delete those 4 lines from the freshly generated config
3. start deadbeef again, and get a crash

is this correct?
do you even need to delete any lines?

[Oleksiy-Yakovenko]

nvm, I think I understand. You mean that when you delete those lines -- deadbeef starts again, not the crash.

[elandorr]

Yes, sorry ambiguous. "original" config meant the one that did not work.

1. started deadbeef today, didn't work
2. removed lines from the config, worked again
3. closed deadbeef, reopened, didn't work

A completely new config works:

1. delete everything
2. start, works
3. close, reopen, works

Not sure why it does not like the config. I'll try making my settings from scratch later and closing/reopening every time.

[Oleksiy-Yakovenko]

It may theoretically be caused by some UI layout configuration, which would produce a weird combination of positions or sizes, which in turn breaks GTK/X11 expectations. Hard to tell without seeing how your UI looks like.

[elandorr]

It worked fine until today :)

I might upload the entire config on a temporary link later for you. (don't want it here forever)

Even compiled plugins work fine if these lines are removed, until restart.

The layout was nothing crazy, just a few tabs. A twm (i3) is used, but that was never a problem.

If the lines are removed it works. Seems related to previous playback position. The playlist was empty save for 1 test file.

Not sure I have time to recreate what does not really matter. For audio processing/verifying I use fb2k. For native linux listening an almost default fresh db config works. (supports RG for my opus files which is nice)

What is weird is that it broke suddenly, with no change to db. Only kernel changed, regular system updates, but nothing major. Boring reliable x11 system.

[Oleksiy-Yakovenko]

It does look like something broke outside of deadbeef. It's impossible to know what did break without replicating the same system build, and using debugger. You could try following gdb instructions on the wiki, and produce a backtrace. But there's a high chance it would not help, since this is an X11 error, which occurs asynchronously (just as the error message says). So in order to get to the bottom of it - you would need to modify deadbeef code to switch GTK into a synchronous X11 mode, and then MAYBE something could be figured out (but it may also break something else).

[elandorr]

I don't understand how a "simple" gtk issue can be so hard to debug, but that's probably too much work to bother.

Just tried the same config on an older Debian VM and it started. Might be a random gtk update problem that fixes itself over time.

At least now you know these lines can cause issues in some configurations.

Might try replacing the line for gtk version and see if gtk3 does any better. I forgot why I picked gtk2, something was off in gtk3 afair.

[Oleksiy-Yakovenko]

It's simple to debug when it's reproducible, but I can't repro -- so I can't debug :)

[elandorr]

Not having ANY usable errors unless you change code and compile a special version is new to me. Normally you flip a debug log on to get something to work with.

You can't realistically replicate someone's system. At least not without full packagelist/configs/insane efforts.

qed.: I tried the config from earlier again, and it works.....! ZERO changes! Right after I set up a VM for testing, ugh.

Literally the only thing left I can think of is the spawning position/size. But I tried wrapping it in a bunch of terminals and it still works.

These errors still show up:

convgui: gtkui plugin not found
shellexecui: can't find gtkui plugin
gtkui plugin compiled for gtk version: 2.16.0

Having it break and then continue working without any indication why is super annoying :>

If it breaks again I'll post - but since we don't have any useful errors, no real point.

[Oleksiy-Yakovenko]

Normally you flip a debug log on to get something to work with.

This only works when it's an anticipated error condition, which is handled/logged by the app.
Which is not the situation that you're experiencing.

The issue that you encountered occurs in either GTK or X11 (not in deadbeef code),
and obviously deadbeef code can't anticipate and handle it.

However, it's quite likely that you can find some GTK or X11 logging options to get something to work with.

[elandorr]

I'm aware of that, but often the program has a way of toggling a toolkit's debugging.

Found G_MESSAGES_DEBUG=all but that didn't cause new messages. Don't have time to dig through gtk/x11 which is a lifetime of study itself :P.

The usual x11 log has nothing.

If it happens again I'll just try another workspace. If it's related to positioning weirdness that's faster than wasting time on this.