Bug 409792

Summary:	[drkonqi]: debugger *rc file search algorithm flaky?
Product:	[Applications] drkonqi	Reporter:	RJVB <rjvbertin>
Component:	general	Assignee:	Unassigned bugs mailing-list <unassigned-bugs>
Status:	CONFIRMED ---
Severity:	minor	CC:	sitter
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	All
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description RJVB 2019-07-14 15:26:11 UTC

SUMMARY
DrKonqi finds its available debuggers via `foorc` files in the location retrieved by

QStandardPaths::locate(QStandardPaths::AppDataLocation, path, QStandardPaths::LocateDirectory)

This means that the system profiles in $prefix/share/drkonqi/debuggers will be ignored if the user creates a ~/.local/share/drkonqi/debuggers directory (on regular Unix, read the corresponding paths on Mac and MSWin).

I'm not entirely certain how bad this is, given that DrKonqi doesn't allow a choice of the debugger used to generate a crash report. It does mean that the built-in default will be used if the user leaves the directory empty, and that default might not be correct on a given install.

Comment 1 Harald Sitter 2019-07-16 09:13:56 UTC

What is the problem?

Also, what is a "built-in default"?
Also, why would the *user* do anything to any directory pertaining to drkonqi debuggers?

Comment 2 RJVB 2019-07-16 12:54:44 UTC

> What is the problem?

The user can break a distro- or install-specific configuration of the debugger backend, simply by creating an empty directory.

> Also, what is a "built-in default"?

A default (setting) that's hardcoded and used as a fallback.
```
DebuggerManager *KCrashBackend::constructDebuggerManager()
{
    QList<Debugger> internalDebuggers = Debugger::availableInternalDebuggers(QStringLiteral("KCrash"));
    KConfigGroup config(KSharedConfig::openConfig(), "DrKonqi");
#if defined(__MAC_OS_X_VERSION_MAX_ALLOWED) && __MAC_OS_X_VERSION_MAX_ALLOWED > 1070
    QString defaultDebuggerName = config.readEntry("Debugger", QStringLiteral("lldb"));
#elif !defined(Q_OS_WIN)
    QString defaultDebuggerName = config.readEntry("Debugger", QStringLiteral("gdb"));
#else
    QString defaultDebuggerName = config.readEntry("Debugger", QStringLiteral("cdb"));
#endif
```

> Also, why would the *user* do anything to any directory pertaining to
> drkonqi debuggers?

S/he may want to select a specific lldb version (LLVM executables are typically installed with the major version appended to their name), a self-built gdb. S/he could also have symbol cache files that would speed up the backtrace generation.
Even if the user is an admin s/he may still prefer to install the customised debugger profile in a personal and not a system-wide location - and in that case the profile should ideally be an addition to the system-defined profiles.

When looking up resources in multi-valued QSP locations one would normally obtain the list of all possible locations and then check them in an additional loop.

Comment 3 Harald Sitter 2019-07-16 13:12:53 UTC

(In reply to RJVB from comment #2)
> > What is the problem?
> 
> The user can break a distro- or install-specific configuration of the
> debugger backend, simply by creating an empty directory.

Please give a list of commands that demonstrate this.

Comment 4 Harald Sitter 2019-07-16 13:15:23 UTC

Actually nevermind. I see the problem

>        QStandardPaths::locate(QStandardPaths::AppDataLocation, path, QStandardPaths::LocateDirectory)

the lookup code in Debugger::availableDebuggers searches for one directory, when it should in fact look at all of them and assemble all debuggers from all dirs

Comment 5 RJVB 2019-07-16 13:55:02 UTC

(In reply to Harald Sitter from comment #4)

> the lookup code in Debugger::availableDebuggers searches for one directory,
> when it should in fact look at all of them and assemble all debuggers from
> all dirs

Yes, maybe I should have said explicitly that QSP::locate() returns the 1st hit; `QStandardPaths::locateAll()` should return the list of all matching files (or directories). Sorry, I thought this was common knowledge (it becomes that after you run into the difference a few times yourself ;))