| Summary: | tdecontrolcenter crashes instantly by one click on "Autostartmanager" menu entry | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Stefan Krusche <linux> |
| Component: | tdebase | Assignee: | Michele Calgaro <michele.calgaro> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | bugwatch, jlturriff, linux, michele.calgaro |
| Priority: | P5 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | amd64 | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 3085 | ||
|
Description
Stefan Krusche
2018-12-06 10:01:29 CST
Hi Stefan, TDE control center works fine here. A few questions: 1) can you try with a different (new) user and see if it has the same problem? 2) can you add a crash report of the crash? (possibly with debug symbols installed). Alternatively submit the crash report when asked and paste the id here. 3) does kcontrol crash when you launch it normally (without accessing the manager tab)? 4) do you have any program in the autostart manager? 5) was it working in the past? Dear Michele, thanks for looking into this. Summary Starting Autostart Manager crashes in my regular user account (German) and in a pristine test user account with default (English/"C") language settings. TDE Crash manager reports the application caused signal 11 (SIGSEGV). There's a slight difference in behaviour between the two, though. See below. (In reply to Michele Calgaro from comment #1) > Hi Stefan, > TDE control center works fine here. > A few questions: > 1) can you try with a different (new) user and see if it has the same > problem? A new pristine user account shows the same erratic behaviour either with german or english GUI language settings. > 2) can you add a crash report of the crash? (possibly with debug symbols > installed). Alternatively submit the crash report when asked and paste the > id here. I'm new to bugreporting / debugging etc. but I will try. Someone has to do it, right? ;-) > 3) does kcontrol crash when you launch it normally (without accessing the > manager tab)? I'm not sure about what you mean by "normally". There's three ways to start I'm aware of: a) Start Tcontrol Center by Kmenu, go to Autostart Manager (in TCC): - Kmenu -> Trinity Control Center - in tree view click "TDE Resources" (last item). From here I see two ways to launch "Autostart Manager": - one item in the tree - one item in the other panel which shows the same entries as in the tree. Both crash TCC immediately when clicked on. b) Click through Kmenu to the "Autostart Manager" entry: - Kmenu -> Trinity Control Center -> TDE Components -> Autostart Manager When this item is clicked on, it behaves differently depending on the language settings, it seems. - English (default, i.e. "C") language settings: TCC crashes immediately - German language settings: opens the expected dialog window, where there is one entry in my regular user account (see below). When "OK" or "Cancel" is clicked or "Esc" keyboard button pushed it also crashes TCC immediately. c) Start from konsole/terminal: $ tdecmshell autostart [kcrash] TDECrash: Application 'tdecmshell' crashing... This is the same in both my regular (German) and the test user (English) account. > 4) do you have any program in the autostart manager? There's one entry only: Name Command Run on gtk-qt-engine.rc.sh gtk-qt-engine.rc.sh ENV The file gtk-qt-engine.rc.sh exists in ~/.trinity/env/ with this somewhat insanely looking content: #!/bin/bash # Make sure our customised gtkrc file is loaded. export GTK2_RC_FILES=$HOME/.gtkrc-2.0-kde4 #!/bin/bash # Make sure our customised gtkrc file is loaded. export GTK2_RC_FILES=$HOME/.gtkrc-2.0-kde-kde4 On my system are two GTK* environment variables: $ env | grep GTK GTK2_RC_FILES=/home/stekru/.gtkrc-2.0-kde-kde4:/home/stekru/.trinity/share/config/gtkrc-2.0 GTK_RC_FILES=/etc/gtk/gtkrc:/home/stekru/.gtkrc:/home/stekru/.trinity/share/config/gtkrc The same file in the pristine test user's (english/default language setting) home dir contains only the first instance of exporting GTK2_RC_FILES: #!/bin/bash # Make sure our customised gtkrc file is loaded. export GTK2_RC_FILES=$HOME/.gtkrc-2.0-kde4 > 5) was it working in the past? I don't know. There may be more differences between the regular and test user's account settings I'm not aware of. I'm carrying my regular user settings with me from system to system for several years. Feel free to guide me through more testing as your time and motivation allows. Thanks. Kind regards, Stefan Hi Michele, produced a crash report with debug symbols with ID: TDECRSH-35d74d9-a1ee952-477fffb-e936327-185d8d6-9c65db8-a415cbf I sent it via the crash manager. Kind regards, Stefan Hi Stefan, thanks for the detailed feedback and sorry for the late reply (very busy week). Point 4) is quite interesting. Are you able to clear your autostart list and see if the crash is still happening? I would like to understand if the crash is in TCC or if it is a consequence of the program that is lauched. FYI, sometime ago there was a similar problem where for example adding Konsole to autostart would cause a crash of the autostart manager. That problem was fix, but maybe you are experiencing a similar issue? A quick look at the crash report and code, indicates that the crash is probably caused by an invalid pointer in a call. I have tried adding the same script to autostart, but no crash here (although I am on R14.1.0-dev). For reference, the previous bug was bug 2734. I am also experiencing this bug on my OpenSuSE Leap 15.1 x86_64 system. It happens if I launch Autostart Manager from Trinity Control Center or directly from the TDE Menu. I am also experiencing this bug on my OpenSuSE Leap 15.1 x86_64 system. It happens if I launch Autostart Manager from Trinity Control Center, directly from the TDE Menu, or via tdecmshell. I am closing this bug since it is the same issue currently being discussed in bug 3105.The crash report points to the same line of code. Let's discuss in that bug. *** This bug has been marked as a duplicate of bug 3105 *** This has been fixed in commit 7524af2 (R14.1) and cb6772b (R14.0). If any of you is on PSB, could you plase confirm? confirmed fixed on Bug 3105. |