Bug 1655

* creating: `uname -n`;1378584682;742270;16597_TIME0:
(where uname -n is actually the hostname of the machine)

Regarding "tdeio (tdeioslave): WARNING: Can't communicate with kded_kpasswdserver!" that likely is resolved somewhere in tdeioslave, but I can repeatedly invoke the message by starting akregator. Perhaps that information will help with debugging.

Another new message:

* Xlib XKB extension major=1 minor=0

I'm preparing some patches to help identify from where some of these new messages are generated.

* tdecore (KLibLoader): WARNING: KLibrary: symbol not found

I can invoke that message by starting kmail.

* tdesu: WARNING: unknown super user command

Fixed in GIT hash 11b5fd8f.

Patches mentioned in Comment 1 pushed to git in commits:

tdelibs:
7f26e9d0
e4f16abb

tdebase:
f123d99f

Updated message strings with module name:

* [tdecore-tdeapplication] Found visual with alpha support

* [kcontrol-access] Xlib XKB extension major=1 minor=0

* [tdecore-tdestartupinfo] creating: `uname -n`;1378603393;768750;15758_TIME0:


A new previously unseen message (I have no idea how to invoke):

* undecodable token: \001b(hex)[?1015h
* undecodable token: \001b(hex)[?1015l

Possible patch?:

https://bugs.kde.org/show_bug.cgi?id=138740


And another:

* [dcopserver] Corrupt data!

* tdecore (TDEConfigDialogManager): WARNING: A widget named 'kcfg_ConfirmArticleDelete' was found but there is no setting named 'ConfirmArticleDelete'

To cause this message:

1. Start akregator.
2. Read at least one article.
3. Delete all fetched articles.
4. Close akregator to the system tray.
5. Open akregator.

Notice the view pane still shows the last read article but the article no longer exists in the fetched feeds.

Regarding:

tdepowersave: WARNING: Couldn't request charge_level.unit for udi: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/

This message repeats about once per second and results in a seriouslylarge xsession-error log.

> * tdesu: WARNING: unknown super user command
> Fixed in GIT hash 11b5fd8f.
Yes, fixed. :-)

Regarding the following messages:

* [tdecore-tdeapplication] Found visual with alpha support
* [kcontrol-access] Xlib XKB extension major=1 minor=0
* [tdecore-tdestartupinfo] creating: `uname -n`;1378603393;768750;15758_TIME0:
* tdecore (TDEProcess): WARNING: _attachPty() XX

Possibly at one time these messages were useful to somebody for debugging, but these messages now seem like nothing more than noise. Either the kdebug redirect should be to a specific kdebug item number ( kdebug(xxx) rather than kdebug() ), which would allow users to disable in kdebugdialog, or the messages should be deleted or commented out.

Of the messages cited in this report, the following seem important for R14 RC1:

* tdepowersave: WARNING: Couldn't request charge_level.unit for udi: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00 /PNP0C0A:00/power_supply/BAT0/

* tdeio (tdeioslave): WARNING: Can't communicate with kded_kpasswdserver!

* tdeio (TDEIOConnection): ERROR: Header read failed, errno=104

* tdeio (TDEIOConnection): ERROR: Header has invalid size (-1)

* tdeio (TDEIOConnection): ERROR: Could not write data

* tdeio (TDELauncher): ERROR: SlavePool: No communication with slave.

* [dcopserver] Corrupt data!

* tdecore (KLibLoader): WARNING: KLibrary: symbol not found

* tdeparts: WARNING: StatusBarExtension::removeStatusBarItem. Widget not found : [KPushButton pointer (0x8b670c0) to widget CancelButton, geometry=100x30+0+0]

* TQColor::setRgb: RGB parameter(s) out of range

* TQClipboard::setData: Cannot set X11 selection owner for CLIPBOARD


In comment 10 I proposed a fix for some of the messages. If the solution is redirecting to a specific kdebug item number, then those item numbers should be disabled by default.

Regarding comment 2:

* tdeio (tdeioslave): WARNING: Can't communicate with kded_kpasswdserver!

I'm guessing, but I don't use tdewallet. Purely a wild guess.

Created attachment 1531 [details]
tdepowersave : fix warning in getting charge level units

Power supply energy informations in sysfs are always in µWh.
https://www.kernel.org/doc/Documentation/power/power_supply_class.txt

TDE hardware library internally uses Wh.
Since charge level unit are always Wh.

I think that the warning is therefore unnecessary.

Created attachment 1532 [details]
tdepowersave : more accurate reporting failure while acquire org.freedesktop.Policy.Power

The patch does not fix failure while acquire interface org.freedesktop.Policy.Power only extends the warning report.

By the way, I get the following:

tdepowersave: WARNING: Acquire org.freedesktop.Policy.Power interface failed with error: Connection ":1.24" is not allowed to own the service "org.freedesktop.Policy.Power" due to security policies in the configuration file

With the patches I no longer see the "charge_level.unit" messages. That keeps the xsession-error log smaller rather than growing at a rate of one message every second. :-)

I see the following in the xsession-error log:

tdepowersave: WARNING: Acquire org.freedesktop.Policy.Power interface failed with error: Connection ":1.24" is not allowed to own the service "org.freedesktop.Policy.Power" due to security policies in the configuration file

The message seems to make sense, but what is the remedy to fix? Is there an option in TDEPowersave?

The following message appears, but I probably never noticed before:

tdepowersave: ERROR: Could not set CPU Freq, this not the needed privileges.

The English is awkward and why is TDEPowersave trying to change the CPU frequency? I believe that requires superuser privileges?

Created attachment 1534 [details]
Debugging patch for kpasswdserver message

I created a debugging patch for the message 'tdeio (tdeioslave): WARNING: Can't communicate with kded_kpasswdserver!'.

In tdelibs/tdeio/tdeio/slavebase.cpp, there are two places that invoke that warning message. The patch isolates from which part of the code. The message now can be isolated:

tdeio (tdeioslave): WARNING: Can't communicate with kded_kpasswdserver (checkCachedAuthentication)!

Thus the message is created from calling SlaveBase::checkCachedAuthentication.

Would seem the cause is either checkAuthInfo(TDEIO::AuthInfo) or dcopclient?

A wee bit embarrassing. :-)

The cause of the kpasswdserver messages was me and is related to bug report 1470. I had created my own respective kpasswdserver.desktop, stored in my TDEDIRS directory, and had set X-TDE-Kded-load-on-demand=false. The only role commit 5354555 had with this message is actually allowing the message to print.

That said, the debugging patch I created might prove useful in the long term. I'll push to git if somebody agrees.

Created attachment 1535 [details]
tdepowersave : fix setting cpu frequence without sufficient privileges

I added a condition to not been adjusted frequency when changed schema or handling resume signal and user not have sufficient privileges.

Please, test it.

(Odpověď na komentář #16)
> Vytvořena příloha 1534
> Debugging patch for kpasswdserver message
> 
> I created a debugging patch for the message 'tdeio (tdeioslave): WARNING: Can't
> communicate with kded_kpasswdserver!'.
> 
> In tdelibs/tdeio/tdeio/slavebase.cpp, there are two places that invoke that
> warning message. The patch isolates from which part of the code. The message
> now can be isolated:
> 
> tdeio (tdeioslave): WARNING: Can't communicate with kded_kpasswdserver
> (checkCachedAuthentication)!
> 
> Thus the message is created from calling SlaveBase::checkCachedAuthentication.
> 
> Would seem the cause is either checkAuthInfo(TDEIO::AuthInfo) or dcopclient?

I think it is a good idea to be able to recognize individual messages.
For me: go ahead and push it.

Debugging patch pushed to in commit c9e64428.

I rebuilt tdepowersave with the cpu frequency patch. I no longer see any messages in my xsession-errors log.

Comment on attachment 1531 [details]
tdepowersave : fix warning in getting charge level units

Pushed to GIT in hash 10c13fde.

Comment on attachment 1532 [details]
tdepowersave : more accurate reporting failure while acquire org.freedesktop.Policy.Power

Pushed to GIT in hash d36ef501 (tdepowersave) and 95b83ac2 (kpowersave).

Comment on attachment 1535 [details]
tdepowersave : fix setting cpu frequence without sufficient privileges

Pushed to GIT in hash 03857a55 (tdepowersave) and 055857b2 (kpowersave).

If I follow correctly, the following messages remain to be addressed for R14 RC1:

* tdeio (TDEIOConnection): ERROR: Header read failed, errno=104

* tdeio (TDEIOConnection): ERROR: Header has invalid size (-1)

* tdeio (TDEIOConnection): ERROR: Could not write data

* tdeio (TDELauncher): ERROR: SlavePool: No communication with slave.

* [dcopserver] Corrupt data!

* tdecore (KLibLoader): WARNING: KLibrary: symbol not found

* tdeparts: WARNING: StatusBarExtension::removeStatusBarItem. Widget not found
: [KPushButton pointer (0x8b670c0) to widget CancelButton, geometry=100x30+0+0]

* TQColor::setRgb: RGB parameter(s) out of range

* TQClipboard::setData: Cannot set X11 selection owner for CLIPBOARD

Of these messages, the ones that concern me most are these, as they are likely indicative of a strange user-visible failure occurring somewhere:
* [dcopserver] Corrupt data!
* tdecore (KLibLoader): WARNING: KLibrary: symbol not found

I'd like to see that last message expanded to include at least the mangled C++ symbol name and library file name, and possibly the demangled symbol name instead.

Tim

There probably are additional messages we have not added to this list but the messages you listed would seem to warrant concern. The messages themselves indicates something awry. I'm not seeing anything obvious in the way of crashes or lock-ups, but we have many paper cut bug reports that might be related to these now-visible messages.

When we resolve those messages I'll open individual reports for any remaining messages, which will help tracking and debugging.

> I'd like to see that last message expanded to include at least the mangled C++
> symbol name and library file name, and possibly the demangled symbol name instead.

If you push a patch to git I'll start testing. I have seen the message in xsession-errors from other causes too, although I have not taken time to note how the message is generated in those instances.

(In reply to comment #25)
> There probably are additional messages we have not added to this list but the
> messages you listed would seem to warrant concern. The messages themselves
> indicates something awry. I'm not seeing anything obvious in the way of crashes
> or lock-ups, but we have many paper cut bug reports that might be related to
> these now-visible messages.
> 
> When we resolve those messages I'll open individual reports for any remaining
> messages, which will help tracking and debugging.
> 
> > I'd like to see that last message expanded to include at least the mangled C++
> > symbol name and library file name, and possibly the demangled symbol name instead.
> 
> If you push a patch to git I'll start testing. I have seen the message in
> xsession-errors from other causes too, although I have not taken time to note
> how the message is generated in those instances.

On further investigation it looks like the library loader prints detailed error information one line after the "symbol not found" message.  Can you post the line after the warning message so I can track down the problem?

Thanks!

> Can you post the line after the warning message so I
> can track down the problem?
I don't see any such follow-up messages. :-( Here is what I did if you want to confirm:

* Open konsole
* tail -f ~/.xsession-errors
* Start KMail
* Watch the output of konsole

(In reply to comment #27)
> > Can you post the line after the warning message so I
> > can track down the problem?
> I don't see any such follow-up messages. :-( Here is what I did if you want to
> confirm:
> 
> * Open konsole
> * tail -f ~/.xsession-errors
> * Start KMail
> * Watch the output of konsole

Thanks for the instructions; I easily replicated the problem and fixed both the vague error message and the WARNING spew.  The latter was related to the SSL library attempting to resolve symbols without first checking if the existed, and is fixed in GIT hash e757d3d.

I can't seem to replicate this message:
[dcopserver] Corrupt data!

Can you give instructions on how to generate it?

Thanks!

Tim

>Thanks for the instructions; I easily replicated the problem and fixed both
I'll test today.

>Can you give instructions on how to generate it?
Nope. :-( I see that message occasionally. Likewise with some of the other messages. They don't always appear. I will write a nominal watchdog script in the hope of capturing some of these messages.

>Thanks for the instructions; I easily replicated the problem and fixed both
Yes, the error message is now gone when using KMail. :-)

Tim, I am able to trigger two of the reported messages with repeatability.

========================================
main(): initialising

This is caused by starting KAlarm.

To view the message:

* If KAlarm is running, then terminate the app and kill the kalarmd process.

* Open Konsole and run: tail -f ~/.xsession-errors

* Open the mini-cli (Alt-F2) and run kalarm.

* Watch the Konsole output.

The message is generated from tdepim/kalarm/main.cpp:127.

This seems like a useless message. We can either delete the kdDebug output or change the message to something sane, such as "KAlarm: initialising."

Thoughts?

========================================
tdeio (TDEIOConnection): ERROR: Could not write data

This message could be generated by other triggers but here is one repeatable trigger.

This particular trigger could be related to bug 1382.

I can trigger the ERROR message only during the initial start of my Trinity session. Toggling the check box during the session has no effect on my system.

To view the message:

* "Right-click" on the desktop.

* From the popup menu select Configure Desktop.

* Select Behavior->Device Icons.

* Disable Show Device Icons.

* Restart the Trinity session.

* Open Konsole and run: tail -f ~/.xsession-errors

* Enable Show Device Icons.

* Watch the Konsole output.

Which device icons are enabled makes no difference on my system. I disabled all of them and saw the same result.

Tim, I am able to repeatedly trigger a third message reported in this bug report.

This message could be generated by other triggers but here is one repeatable trigger.

========================================
tdeparts: WARNING: StatusBarExtension::removeStatusBarItem. Widget not found : [KPushButton pointer (0x87a7838) to widget CancelButton, geometry=100x30+0+0]

* Open a compressed archive with Ark.

Either start Ark and then open the archive or open an archive in Ark by double-clicking on the archive file in Konqueror.

I found how to trigger another of the reported messages.

This message could be generated by other triggers but here is one repeatable trigger.

========================================
TQClipboard::setData: Cannot set X11 selection owner for CLIPBOARD

* Open Konsole and run: tail -f ~/.xsession-errors

* Open Konqueror

* Cut (not copy) a file from one directory to another.

* undecodable token: \001b(hex)[?1015h

I don't know explicitly how to trigger these messages, but I've narrowed the source of the messages to konsole. The only time I might see the messages is when using konsole.

After determining konsole was the cause, a little digging revealed the messages are generated from within tdebase/konsole/konsole/TEmuVt102.cpp.

Browsing the code indicates a likely cause is an escape sequence that is not recognized in the code.

As mentioned in comment 6, a possible fix:

Bug report:
https://bugs.kde.org/show_bug.cgi?id=138740

The actual patch:
(https://projects.kde.org/projects/kde/applications/konsole/repository/revisions/35e9cd847a236e4b495cb1c03347ee8f59a4d8e8/diff/src/ColorSchemeManager.cpp)

Trinity does not have ColorSchemeManager.cpp, but the bug report indicates a possible cause: supporting 24-bit color specifications in escape sequences.

For future users mystified by not knowing the source of these messages, I would like to patch the printf statement:

AS IS:
printf("undecodable "); scan_buffer_report();

CHANGE TO:
printf("[konsole TEmuVt102] Undecodable/unrecognized "); scan_buffer_report();

Can we add additional debugging text to the printf statement or scan_buffer_report function?

Regarding the "undecodable token: \001b(hex)[?1015h" messages:

I pushed a patch in commit 6409e490 to clarify the source of the message. The patch does not resolve the problem in any way.

Regarding the "main(): initialising" message:

I pushed a patch in commit 8289b3d2. This patch resolves the problem of revealing the source of the message.

I have commented out the KAlarm initialization message as I see no use for it unless kalarm is actively being debugged by a developer.

"tdeio (TDEIOConnection): ERROR: Could not write data" might be related to this line in tdebase/kcontrol/konq/desktopbehavior_impl.cpp:
kapp->dcopClient()->send( "menuapplet*", "menuapplet", "configure()", data );

>I have commented out the KAlarm initialization message as I see no use for it
Okeydokey!

>"tdeio (TDEIOConnection): ERROR: Could not write data" might be related to...
Does that mean you're thinking of a fix?

I've spent quite a bit of time attempting to track down the Konsole undecodable token warning, and while I don't have a fix, the sequences are being sent by vim (in my testing only with the inkpot color scheme) and appear to be invalid.  See the following two pages for my queries to Stack Overflow and the inkpot color scheme author:

http://stackoverflow.com/questions/20024211/strange-escape-sequence-sent-by-vim-to-terminal

https://github.com/ciaranm/inkpot/issues/8

Furthermore, the warning is only printed when Konsole is not compiled in release mode (i.e. when NDEBUG is not set), and is not related to the linked KDE4 Konsole patch, therefore I don't think I will spend much more time on this particular message unless someone can give a clear description of the escape codes being sent by vim.

I think the next thing to do is open new reports for each questionable message and close this bug report. That will allow easier tracking.

To facilitate debugging I'm closing this bug report, which has become too long to follow. For unresolved messages reported here, refer to bug reports 1713 through 1722.