valgrind and glibc-debug

[archwndas]

Dear all,

it has been more than 2 years since I had submitted this bug (it is not a bug, it is a feature). Ubuntu when somebody installs valgrind automatically installs the glibc6 and glibc6-dbg. On Sabayon however this doesn't happen and so:

$ aptitude show valgrind

Package: valgrind
New: yes
State: installed
Automatically installed: no
Version: 1:3.6.1-0ubuntu3
Priority: optional
Section: devel
Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
Uncompressed Size: 164 M
Depends: libc6 (>= 2.3.4), libc6-dbg
Recommends: gdb
Suggests: kcachegrind, alleyoop, valkyrie (> 1.3.0)
Conflicts: valgrind-callgrind, valgrind-callgrind, valgrind
Provides: valgrind-callgrind
Description: A memory debugger and profiler
Valgrind is a GPL'd tool to help you find memory-management problems in your programs. When a program is
run under Valgrind's supervision, all reads and writes of memory are checked, and calls to
malloc/new/free/delete are intercepted.

Valgrind can debug more or less any dynamically-linked ELF x86/Linux, amd64/Linux and ppc/Linux
executables, without modification, recompilation, or anything.

Valgrind provides a generic infrastructure for supervising the execution of programs called "tools". This
is done by providing a way to instrument programs in very precise ways, making it relatively easy to
support activities such as dynamic error detection and profiling. The Valgrind distribution currently
includes three tools: a memory error detectors, a cache (time) profiler and a heap (space) profiler.


However in Sabayon ...

Code: Select all

$ valgrind ls


==30502== Memcheck, a memory error detector
==30502== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==30502== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==30502== Command: ls
==30502==

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind: 
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strlen
valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind: 
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.
valgrind: 
valgrind:  Cannot continue -- exiting now.  Sorry.

Could you please include the debug-info for glibc6 in the entropy and have it being installed as a dependency of valgrind?

[Edit by micia 16-oct-2011] adding code tags around command output, please use code tags for long outputs to make your post more readable.

[micia]

You can install debug symbols for valgrind as follows:

1) enable entropy splitdebug feature, open /etc/entropy/client.conf as root, you will notice this lines:

Code: Select all

# Enable the installation of debug files
# Also known as "splitdebug" support
# Valid parameters: disable, enable, true, false, disabled, enabled, 0, 1
# Default parameter if unset: disable
# splitdebug = disable
# HOW SPLITDEBUG WORKS with Entropy
# Once you enable the "splitdebug" feature
# you just need to (re)install packages in order to
# get /usr/lib/debug metadata files installed. That's it.
# You can safely remove /usr/lib/debug without affecting
# Operating System functionality, at any time.


Change this line:

Code: Select all

# splitdebug = disable


like this:

Code: Select all

splitdebug = enable


from now on every package you will install will have debug symbols included.

2) install glibc:
(as root)

Code: Select all

equo install glibc


3) since you will most likely not need anymore debug symbols for any package, change back /etc/entropy/client,conf to splitdebug=disable.

[archwndas]

Thanks now it works. But why shouldn't that process be automated somehow?

[micia]

Because it currently isn't
You could reply to this bug report:
https://bugs.sabayon.org/show_bug.cgi?id=2712
with some comments and suggestions.

[King_DuckZ]

Nice, I'm having the exact same problem.
I also thought I could emerge libc with the appropriate use flags, but it would also carry in os-headers. Both of those packages are low level, so do you think emerging those would be dangerous?
I'll try the splitdebug solution for now.

[wintux]

The information above is outdated.
The "bug" (feature request) linked above is already RESOLVED.

In order to install debug information for a certain package -- let's say "kde-base/kwrite" -- do in a terminal as root:

Code: Select all

# cp /etc/entropy/packages/package.splitdebug.example /etc/entropy/packages/package.splitdebug

Then append a line like "kde-base/kwrite" (without the quotes) for every package you need debug information for at the end of /etc/entropy/packages/package.splitdebug with an editor of your choice.

[wintux]

But what to do then?
How to force entropy to read it's config files again?
( Just reinstalling the packages obviously had no effect.)

I've had crashes of kdevelop and kwrite.
The respective "KDE crash handler/handling"-windows ("KDE-Absturzbehandlung" in German) are open yet.
If you now open the tab "developer information" in such a window and click at "list files" or "file list" ("Dateiliste")
you can see the list of programs and libraries for which debug information is needed in order to produce useful information about the crash.
You can find out which packages those libraries belong to when typing in a terminal:

Code: Select all

equo query belongs /usr/lib64/libkatepartinterfaces.so.4

Here, for library "libkatepartinterfaces.so.4" the result is:

Code: Select all

>>  @@ Suche nach Zugehörigkeit
>>      @@ Paket: kde-base/katepart-4.10.1 Branch: 5, [__system__]
>>         Installiert:    Version: 4.10.1 ~ tag: NoTag ~ Version: 0
>>         Slot:           4
>>         Homepage:       http://www.kde.org/
>>         Beschreibung:   KDE Editor KPart
>>         Lizenz:         GPL-2
>>  Schlüsselwort:  /usr/lib64/libkatepartinterfaces.so.4
>>  Gefunden:       1 Eintrag


In my case I appended

Code: Select all

dev-util/kdevelop
dev-qt/qtcore
dev-qt/qtgui
www-client/rekonq
kde-base/kwrite
kde-base/kdelibs
kde-base/katepart

at the end of entropy's config file "/etc/entropy/packages/package.splitdebug".

But when I reinstalled the above packages then by executing

Code: Select all

equo i kdevelop qtcore qtgui rekonq kwrite kdelibs katepart

there was no hint in the output that debug information is now included.

I also tried to reload the collected crash information in the "KDE crash handler"-window without success.
Here is the result for the kdevelop crash:

Code: Select all

Application: KDevelop (kdevelop), signal: Segmentation fault
To enable execution of this file add
   add-auto-load-safe-path /lib64/libthread_db-1.0.so
line to your configuration file "/home/winni/.gdbinit".
To completely disable this security protection add
   set auto-load safe-path /
line to your configuration file "/home/winni/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
   info "(gdb)Auto-loading safe path"
[Current thread is 1 (process 11304)]

Thread 1 (process 11304):
#0  0x00007f586a710dcc in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x00007f586bd177bb in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/qt4/libQtCore.so.4
#2  0x00007f586bd0a18e in ?? () from /usr/lib64/qt4/libQtCore.so.4
#3  0x00007f586bd0bbb4 in QThreadPool::~QThreadPool() () from /usr/lib64/qt4/libQtCore.so.4
#4  0x00007f586bd0bbf9 in QThreadPool::~QThreadPool() () from /usr/lib64/qt4/libQtCore.so.4
#5  0x00007f586bd0bc25 in ?? () from /usr/lib64/qt4/libQtCore.so.4
#6  0x00007f586a95b681 in ?? () from /lib64/libc.so.6
#7  0x00007f586a95b705 in exit () from /lib64/libc.so.6
#8  0x00007f586b22c758 in ?? () from /usr/lib64/qt4/libQtGui.so.4
#9  0x00007f586c654ec8 in KApplication::xioErrhandler(_XDisplay*) () from /usr/lib64/libkdeui.so.5
#10 0x00007f58662d265e in _XIOError () from /usr/lib64/libX11.so.6
#11 0x00007f58662d00ad in _XEventsQueued () from /usr/lib64/libX11.so.6
#12 0x00007f58662c168f in XEventsQueued () from /usr/lib64/libX11.so.6
#13 0x00007f586b2638dc in ?? () from /usr/lib64/qt4/libQtGui.so.4
#14 0x00007f5864db95fc in g_main_context_check () from /usr/lib64/libglib-2.0.so.0
#15 0x00007f5864db9a86 in ?? () from /usr/lib64/libglib-2.0.so.0
#16 0x00007f5864db9c14 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#17 0x00007f586be45edf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#18 0x00007f586b263a9e in ?? () from /usr/lib64/qt4/libQtGui.so.4
#19 0x00007f586be158f2 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#20 0x00007f586be15b47 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#21 0x00007f586be1a965 in QCoreApplication::exec() () from /usr/lib64/qt4/libQtCore.so.4
#22 0x00000000004104fa in ?? ()
#23 0x00007f586a9455dd in __libc_start_main () from /lib64/libc.so.6
#24 0x0000000000410c61 in _start ()

There are still many "??". I'm sorry, I can't say if less than before.

How can I find out, if any debug information is installed at all or not?
I suppose, I have to force entropy to read it's config files again. But how to do that?

Can anybody help, please?

[micia]

Hi, the information above is not outdated, the procedure explained is still valid and works as expected, of course the bug is now solved, as this topic is ~2 years old.

The only thing that changed is that (as you noticed already) you can selectively enable debug symbols installation via packages.splitdebug, which makes the third step unnecessary if you take advantage of it.

There should be no need to ask entropy to read again its configuration files, it is done automatically, reinstalling the packages should be enough.
Did you enable the splitdebug option in /etc/entropy/client.conf?

[wintux]

Thank you for answering!

...as this topic is ~2 years old.

Yes, of course. But beat me if I'm wrong: I really tried hard to find documentation about how to install debug information for a package with entropy. It seems that there is nothing neither in the entropy wiki nor in the FAQs. The only place where I did find something useful about it in the end was this old thread.
If you could tell me where to find more, this would be great!

Hi, the information above is not outdated, the procedure explained is still valid and works as expected

Sorry, obviously I didn't express myself clearly here: Assumed, that one is interested to install debug information for a certain package (or more than one) in order to file useful bug reports. When a new version gets into the repository (together with other updates), it would be automaticly installed without debug information, when using the general method. So, I think the selective way gives you more control and flexibility and therefore might be the new standard way to do it. In this way I meant "outdated".

Did you enable the splitdebug option in /etc/entropy/client.conf?

No. As I understood, you needn't if you use the selective method.
Inbetween I noticed that
- a copy of the file /etc/entropy/packages/package.splitdebug, called #package.splitdebug#, has been made in the same directory,
- in the download directory new .tbz2.mtime-files were created for the reinstalled packages,
- I still don't have a directory /usr/lib/debug (do I have to manually create it?)
- after reboot several native KDE applications (KNotify, Policy-Kit, Plasma, rekonq) crashed and the KDE crash handler demanded debug information for "/usr/bin/kdeinit4 (deleted)" althouth it was definitely not deleted and in place.
Since I renamed package.splitdebug and then rebooted again the system doesn't have crash problems any more.

[micia]

No need apologize, I just thought I would make that clear.

Yes, you are correct, both on the fact that there is no other topic on the forums (as far as I'm aware) that explains the procedure and on the fact that with the method above on updates debug files would be deleted.
That is why packages.splitdebug was introduced.

The packages.splitdebug feature works on top of the above mentioned method, basically it works like this:

* If splitdebug feature is enabled in /etc/entropy/client.conf, then entropy looks for a file named /etc/entropy/packages/packages.splitdebug, if one is found then debug files are only installed for the specified packages, otherwise debug files are installed for any package.

* if splitdebug feature is not enabled in /etc/entropy/client.conf, then no debug file is installed.

So the possible combinations are:

* splitdebug enabled and /etc/entropy/packages/packages.splitdebug: selectively install debug files only for the packages listed in that file, as described in the /etc/entropy/packages/packages.splitdebug.example file .

* splitdebug enabled: install debug files for every package.

* splitdebug disabled: do not install debug files (regardless /etc/entropy/packages/packages.splitdebug being present).