| Summary: | Crash on startup running Kdenlive without pulseaudio | ||
|---|---|---|---|
| Product: | [Applications] kdenlive | Reporter: | jerome |
| Component: | User Interface & Miscellaneous | Assignee: | Jean-Baptiste Mardelle <jb> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | CC: | fritzibaby, info, jerome, snd.noise, vi0oss |
| Priority: | NOR | Flags: | fritzibaby:
timeline_corruption+
|
| Version First Reported In: | 19.12.1 | ||
| Target Milestone: | --- | ||
| Platform: | Mint (Ubuntu based) | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
jerome
2020-01-11 20:53:55 UTC
As it has been a while since this was reported, can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. Please try with the current Kdenlive AppImage version 20.12.2 https://download.kde.org/stable/kdenlive/20.12/linux/ Very happy to report that KDEnlive seems to be working without PulseAudio again! Tried with kdenlive-20.12.2-x86_64.appimage. Thank you! I will be trying to use this newer version to produce videos later this month, previously had to stick to a 2018 version before of this bug. Thank you for the feedback and contribution. Glad to hear it works. We close this bug. If it still appears in the latest version, please feel free to re-open it and update the affected version number. Sorry to report that although things work once the [SDL] section is added to the rc file, starting kdenlive without a setting file still crashes without one has the chance to open the settings dialog and select SDL / ALSA as the audio driver. kdenlive-master-208-linux-64-gcc.AppImage or /opt/kdenlive-22.04.0-1-x86_x64.AppImage crash when I try to start after "chmod -x /usr/bin/pulseaudio". Sometimes it shows "Could not initialize preview" before crashing, sometimes main window only briefly blinks. I see in dmesg: [1367303.177761] SDLHotplugALSA[3978]: segfault at 0 ip 00007fa010cdc5fe sp 00007f9fd49f6c10 error 4 in libSDL2-2.0.so.0[7fa010c1f000+12a000] [1367303.177803] Code: 68 67 fa ff 48 85 db 75 e3 48 83 c4 78 31 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 90 48 c7 44 24 68 00 00 00 00 4c 8b 44 24 60 <49> 8b 38 48 85 ff 0f 84 df 04 00 00 48 c7 44 24 18 00 00 00 00 45 [1368115.019694] AppRun.wrapped[6297]: segfault at 0 ip 00007fdb859c31e0 sp 00007ffe4564ffd8 error 4 in libmlt++-7.so.7[7fdb859a6000+29000] [1368115.019719] Code: 54 24 08 48 89 34 24 ff d0 48 8b 54 24 08 48 8b 34 24 48 83 c4 18 48 89 c7 e9 cc 89 ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 90 <48> 8b 07 48 8d 0d d6 f8 ff ff 48 8b 40 10 48 39 c8 75 0d 48 8b 7f With /usr/bin/pulseaudio enabled it starts successfully from one user account but crashes from another one (before even displaying a message about preview pane being unavailable). Typically the crash happens after second instance of the following console messages: ALSA lib /home/appimage/Craft/BC/linux-64-gcc/build/libs/libasound2/work/alsa-lib-1.2.5.1/src/conf.c:4499:(snd_config_update_r) Cannot access file /home/appimage/Craft/BC/linux-64-gcc/share/alsa/alsa.conf (it crashes instead of outputting "no alsa devices available") Workaround: explicitly and manually start PulseAudio for that user: `pulseaudio --daemonize=false --exit-idle-time=-1 --disallow-exit=true`. Kdenlive then starts properly. Here's an update on multiple related issues around this error, and some findings that might help to locate and remove its causes. This has two parts: a technical, and a philosophical one. You may not like the 2nd part, but it may be the more important one. With kdenlive 20.xx and later (details see below), all as AppImage, the same error may occured on my system even *with* some pulseaudio packages at least installed (maybe not properly running though). It also happened when I used the asound wrapper. I found that it depends on the availability of a kdenliverc (or kdenlive-appimagerc) file, whether this contained a [sdl] with the line audiodrivername=alsa or audiodrivername=dsp as described below. The error always occured when that config file or this section+line were missing, or when that parameter hat a differnt value. The creation of such a config file with a suitable entry in [sdl] was the sole, immediate and perfectly reproducible way to convert a constantly crashing kdenlive 20.xx .. 21.12.2 back into a usable one. And the use of a value other than alsa or dsp, or the removal of the paramter [sdl] audiodrivername=..., or of the complete config file, was an immediate and perfectly reproducible way to make the error come back. -------------------------- Actual observations (and related errors actually leading to this one): On my system, after an attempted upgrade to kdenlive 22.x AppImage, this error dialog appeared: --- Unable to create KIO worker. Can not find a KIO worker for protocol 'tags'. [OK] --- This is probably a consequence of a separate bug or new, unknown and unmet dependency on my system (even when using an AppImage to avoid exactly such dependencies). Then it said in the konsole (terminal) log: --- ALSA lib /home/appimage/Craft/BC/linux-64-gcc/build/libs/libasound2/work/alsa-lib-1.2.5.1/src/conf.c:4499:(snd_config_update_r) Cannot access file /home/appimage/Craft/BC/linux-64-gcc/share/alsa/alsa.conf Speicherzugriffsfehler --- And crashed. On the next attempt to start kdenlive, this crash was noted and kdenlive suggested to delete (or reset) the config files - sadly, with the focus already on the "yes" / "ok" / "Zurücksetzen" button. This detail by itself is a very bad idea, and therefore a separate bug, because: After the missing config file(s), all tested kdenlive versions > 18.x (both AppImage and FlatPak) would now permanently crash forever, with these lines in the konsole output, and this different error dialog (=error 416139): --- Fehler - Kdenlive Video-Vorschau-Fenster kann nicht erstellt werden. Es stimmt etwas mit Ihrer Kdenlive-Installation oder den Treiber-Einstellungen nicht. Bitte beheben Sie dieses Problem. [OK] --- This error message is misleading, because it directs the user towards a video related problem. The actual cause is, however, audio related. Im quoting the German dialog here in addition to the English text from the original error, because I found this reported by multiple puzzled users in various forums without a definitve resolution or remedy. And it took myself a night to find a specific and reliable workaround: The user actually needs to PRODUCE a kdenlive-appimagerc (or, probably, kdenliverc for non-AppImage-Setups) which MUST have at least this section - and it is completely sufficient to have only a single line in this section: --- [sdl] audiodrivername=alsa --- or -- [sdl] audiodrivername=dsp --- Actually, I tried different entries for this parameter: The following ones, which kdenlive can write after selecting differnt options from its settings dialog, will make the program crash after applying the settings, or on the next restart: audiodrivername=pulseaudio audiodrivername=esd audiodrivername=artsc The same happens, when "Automatic" or "Automatisch" is selected in the dialog: That will produce an [sdl] section which has ONLY the (unrelated) line "blackmagic_output_device=-1", but NO entry for audiodrivername (=the same situation as without any kdenliverc or kdenlive-appimagerc file). And that will invariably cause a crash with the above error dialog on startup. Only the following entries will allow kdenlive to come up and work WITHOUT the above error dialog: audiodrivername=alsa audiodrivername=dsp When I manually put another illegal entry to that parameter (e.g. "oss", which is NOT valid, even thought the entry in the pull-down menu is "OSS"), then kdenlive will ALSO crash with the same error dialog. There might other entries in the other lines of the same section that might be able to cause the same crash (unsure, I don't want to review the notes from my testing any further). But the parameter and values noted above should be the central clue to find the cause of this error and remove it. Also noteworthy, related to the other error (noted at the beginning) which lead me into this one: Versions kdenlive-20.12.3a-x86_64.appimage, 21.04.2, 21.08.3a, 21.12.2 can run on my system when [sdl] audiodrivername=alsa or =dsp. 22Versions 21.12.3 and 22.xx always show the error message noted at the beginning of this report, and WITHOUT [sdl] audiodrivername=alsa or =dsp, they crash exactly like the older versions do (related to this error report) - and WITH [sdl] audiodrivername=alsa, they crash in their own way as described above (for which I haven't found any cure yet). This difference was introduced between 21.12.2 and 21.12.3. The only version available to me which is completely resilient and shows NONE of these errors is: kdenlive 18.12.3-1 (the last one included with Devuan beowulf, i.e. NOT and AppImage version, therefore using kdenliverc and not kdenlive-appimagerc). I hope that with this precise information, it should be feasible to locate the cause of these (multiple errors). ------ Some vague and adventurous speculations on the origin of these errors: As others have pointed into this direction, I'm afraid these errors might all be an offspring of some overly-optimistic (or: careless) introduction of dependencies on pulseaudio somewhere between versions 18.xx and 20.xx. And therefore, they're just another perfect example for how the (merely perceived?, or actively prepared?) urge to include pulseaudio, combined with a failure to ensure the continued usability of your product *without* pulseaudio, produces quite some propulsion (=free benefit) for pulseaudio - but at the same time, produces many cases of dissappointment or extreme fault isolation workloads (=disadvantage) for kdenlive users and developers. And this is just one more example for why I dislike pulseaudio, systemd, and their underlying marketing strategy: Both of these have caused applications that once worked very well without them - to now completely fail, whenever pulseaudio or systemd are missing (say, Devuan Linux or Mozilla Firefox - i.e. NO small victims). - Similar damage occurs even for AppImage based deployment here. This strategy also manifests itself when users who want to remove a simple unwanted sound server or init system - faces the package manager to removing large scale environmets like all of KDE, or even the ability to use a previously mainstream distribution, due to such intentionally promoted, but factually unnecessary dependencies. Or else: The user must accept a product he doesn't want, to use a product that he wants. For pulseaudio, in my own experience, this means more overhead, more audio latency, maybe audio data changes, complexity and constant uncertainty about what's actually happening in the audio system. Additionally complicated by "modern" widget "designs" (e.g. to define preferred audio devices) where you can't easily say whether some colour shade means that a given device is now activated or not. And even as a proficient computer user, even in a dedicated error isolation quest: Once again, I cannot tell whether pulseaudio does currently run (and run as intended), or whether there are merely some of its (unwanted, partly unavoidable) packages installed. In any case, it seems to be dysfunctional, for whatever reason I don't (even want to) understand. So, in my opinion TL; DR: Any hard dependency on pulseaudio is a bug exactly as severe as any hard dependency on systemd. I may be wrong (and misguided, because I don't want to spend more time on basic research after having spent unplanned 10+ hours on error isolation repeatedly) - but once again exemplified today, both of these products follow the same traits, and their names and effects repeatedly observed by myself have significantly contributed to bringing the all too well known "MS Windows user-experience" into the Linux world. Communications of their makers quoted by others have indicated this is intentional (=first, making promises and dependencies easy, then breaking products when users don't want to follow them). It's also classical Microsoft strategy (see: html vs. MS Windows Explorer, or MS Office Formats support etc.) So developers of actually useful software might be very well adviced to keep their own products working both with, and, much more importantly, without such not-so-healthy dependencies. But well, whatdoyaknow, and what do I know... (Sorry for some typos, missing words and one Devuan <-> Debian mix once above. Result of a whole night of unplanned fault isolation.) Anyway: I can also confirm now that $ kdenlive-22.12.3-x86_64.AppImage starts without crashing, AFTER (in a different konsole window) $ pulseaudio --daemonize=false --exit-idle-time=-1 --disallow-exit=true That seems to be necessary even after I installed some (actually unwanted) pulseaudio packages, and even though I restarted the system before. This is true after I've had set the Audiotreiber = Automatisch in the kdenlive settings dialog. Suggestion: In the settings dialog, the warning: "Achtung: Änderungen an Treibern und Geräten können Kdenlive instabil machen. Verändern Sie diese Einstellungen nur, wenn Sie wissen, was Sie tun." might be enhanced by the sentence: "Bitte machen Sie vor dem Ausprobieren neuer Einstellungen eine Sicherheitskopie der alten Konfigurationsdatei ./config/kdenliverc oder ./config/kdenlive-appimagerc" (Because in my case, I would hardly ever have found any way back if I hadn't had a working old config file at hand: NO config file does NOT let kdenlive start and generate an new one, as long as pulseaudio is not running.) The other error message probably newly introduced in 21.12.3 ... 22.xx does still appear (but I don't mind so far, because that doesn't cause a crash): Unable to create KIO worker. Can not find a KIO worker for protocol 'tags'. [OK] So as assumed before, there's a really unhealthy dependency onto pulseaudio - resulting in an immediate crash, after a misleading error message - spawning multiple users asking for help as turned up by google, some at least months without resolution, at least one mentioning they couldn't continue their video project because of this... Well, /certain/ Greeks, and their gifts... :-) :-) In 22.12.3, I saw that I couldn't select and audio device any more (even after changing Audiotreiber von PulseAudio to ALSA). But, after that change, it crashed almost immediately. And both, 22.12.3 and 21.12.3, DO crash, even with pulseaudio running, after setting the Audio Driver to ALSA. And both crashing on restart attempts, until manually changing in the config file: [sdl] audiodrivername=alsa to [sdl] audiodrivername=pulseaudio Well, the pulseaudio support seems to be pretty decided in these ones... Can you still reproduce in latest version? Thank you farid for your update. I haven't done much editing recently; so I'm not very familiar with my current setups. On the machine in front of me just now, installed and working with ALSA is kdenlive-21.04.2-x86_64.appimage When I try to run kdenlive-23.08.2-x86_64.AppImage, I get a series of errrs like GLIBC_2.29 not found, GLIBCXX_3.4.29 not found etc. I may test it later on a more recently set up machine. (None of my machines, however, will probably run the latest versions of Devuan/Debian Linux (and thus, of glibc), because distributions constantly dropped software I prefer to newer, much less beautiful and much less usable replacements. So my abilities to test may be limited.) Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |