Re: Is the chromium debuginfo package exists?

[Frank Ch. Eigler]

Samuel Sieb  writes:

> On 2021-07-25 2:38 p.m., Mikhail Gavrilov wrote:
>> Is the chromium debuginfo package exists?
>> Quick searching in repos didn't find any debuginfo packages for chromium.
>
> There haven't been any debuginfo packages for chromium for at least a
> very long time.  I assume it's disabled for some reason.

chromium.spec sez:

# Debuginfo packages aren't very useful here. If you need to debug
# you should do a proper debug build (not implemented in this spec yet)
%global debug_package %{nil}

People calling for it suggests the assertion of being "not very useful"
may be mistaken.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is the chromium debuginfo package exists?

[Samuel Sieb]

On 2021-07-25 2:38 p.m., Mikhail Gavrilov wrote:

Is the chromium debuginfo package exists?
Quick searching in repos didn't find any debuginfo packages for chromium.


There haven't been any debuginfo packages for chromium for at least a 
very long time.  I assume it's disabled for some reason.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Is the chromium debuginfo package exists?

[Mikhail Gavrilov]

Hi folks!
Is the chromium debuginfo package exists?
Quick searching in repos didn't find any debuginfo packages for chromium.

# dnf search chromium | grep debuginfo
Last metadata expiration check: 0:08:12 ago on Mon 26 Jul 2021 02:25:19 AM +05.
chromium-bsu-debuginfo.x86_64 : Debug information for package chromium-bsu
lightspark-chromium-plugin-debuginfo.x86_64 : Debug information for package 
lightspark-chromium-plugin

And of course I enabled "rawhide-debuginfo" repo.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1027305] pTk/ *.t files in debuginfo package differ in mode on each architecture

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1027305

Fedora End Of Life  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |EOL
Last Closed||2016-07-19 06:34:05



--- Comment #2 from Fedora End Of Life  ---
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: gcc build with -O0 results in corrupted -debuginfo package

[Kevin Kofler]

Simo Sorce wrote:
 Kevin, have you ever debugged with -O2 ?

Yes. In fact, almost always.

 It's more than reasonable to want -O0.
 At -O2 some code becomes really annoying to follow because gcc will
 optimize away way too much of it into registers (and gdb will not print
 you the values you need to see) or will make stepping a nightmare with
 gdb jumping in an out of the function as it gets inlined and then some
 stuff moved out of the original function and things like that.

I know the mad jumping and value optimized out problems very well. You 
learn to deal with those after the initial annoyance, and it's much better 
than debugging totally different machine code from the production one.

 I've been more than once in gdb with -O2, it is *not* pretty, nor
 useful.

Strange, me too (in fact, as I wrote above, that's how I normally use GDB), 
but I find it very useful.

 debug symbols at -O2 are mostly useful to get backtraces, but if you
 need to really step through with gdb in some complicated, highly
 optimizable code, often it does not cut it, you have to rebuild with -O0
 to regain debuggability and sanity.

You just need to get used to the jumping around. After a bunch of times, it 
stops bothering you.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gcc build with -O0 results in corrupted -debuginfo package

[Petr Spacek]

On 25.4.2014 20:03, Adam Jackson wrote:

Maybe think
about how to diagnose what's going wrong and fix the bug instead of
philosophizing.

It seems that
/usr/lib/rpm/find-debuginfo.sh
experts don't read this thread so I have filled bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1091989

--
Petr^2 Spacek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

gcc build with -O0 results in corrupted -debuginfo package

[Petr Spacek]

Hello list,

I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
CFLAGS=$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb.

I did the simplest possible thing - edited the original spec file (see 
spec.diff) and built the package:

$ rpmbuild -ba bind.spec

The package builds and BIND itself seems to work. The problem is that new 
debuginfo package is missing 118 out of 283 header files in 
/usr/src/debug/bind-9.9.4-P2.


It seems that -O0 alone (instead of -O0 -ggdb) causes the same problem.

I would be glad if anyone can give me advice how to debug this.

Original packages from Fedora 20 (with all headers in /usr/src/debug):
http://koji.fedoraproject.org/koji/buildinfo?buildID=502596

Packages built with -O0 -ggdb (scratch build):
http://koji.fedoraproject.org/koji/taskinfo?taskID=6778483

Thank you for your time!

--
Petr^2 Spacek
--- bind.orig.spec	2014-03-05 14:59:20.0 +0100
+++ bind.spec	2014-04-25 15:52:59.666055748 +0200
@@ -29,3 +29,3 @@
 Version:  9.9.4
-Release:  12.%{?PATCHVER}%{?PREVER}%{?dist}
+Release:  12.%{?PATCHVER}%{?PREVER}.pspacek_O0%{?dist}
 Epoch:32
@@ -345,3 +345,3 @@
 %build
-export CFLAGS=$CFLAGS $RPM_OPT_FLAGS
+export CFLAGS=$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb
 export CPPFLAGS=$CPPFLAGS -DDIG_SIGCHASE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gcc build with -O0 results in corrupted -debuginfo package

[Reindl Harald]

Am 25.04.2014 16:10, schrieb Petr Spacek:
 I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
 CFLAGS=$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb.
 
 I did the simplest possible thing - edited the original spec file (see 
 spec.diff) and built the package:
 $ rpmbuild -ba bind.spec
 
 The package builds and BIND itself seems to work. The problem is that new 
 debuginfo package is missing 118 out of
 283 header files in /usr/src/debug/bind-9.9.4-P2.
 
 It seems that -O0 alone (instead of -O0 -ggdb) causes the same problem.
 
 I would be glad if anyone can give me advice how to debug this.
 
 Original packages from Fedora 20 (with all headers in /usr/src/debug):
 http://koji.fedoraproject.org/koji/buildinfo?buildID=502596
 
 Packages built with -O0 -ggdb (scratch build):
 http://koji.fedoraproject.org/koji/taskinfo?taskID=6778483

just don't do that and read compiler warnings
the debuginfo package is your smallest problem
you just kill security features like D_FORTIFY_SOURCE with -O0

warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) 
[-Wcpp]




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gcc build with -O0 results in corrupted -debuginfo package

[Petr Spacek]

On 25.4.2014 16:28, Reindl Harald wrote:


Am 25.04.2014 16:10, schrieb Petr Spacek:

I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
CFLAGS=$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb.

I did the simplest possible thing - edited the original spec file (see 
spec.diff) and built the package:
$ rpmbuild -ba bind.spec

The package builds and BIND itself seems to work. The problem is that new 
debuginfo package is missing 118 out of
283 header files in /usr/src/debug/bind-9.9.4-P2.

It seems that -O0 alone (instead of -O0 -ggdb) causes the same problem.

I would be glad if anyone can give me advice how to debug this.

Original packages from Fedora 20 (with all headers in /usr/src/debug):
http://koji.fedoraproject.org/koji/buildinfo?buildID=502596

Packages built with -O0 -ggdb (scratch build):
http://koji.fedoraproject.org/koji/taskinfo?taskID=6778483


just don't do that
I'm going to reproduce and debug issue in named. Do you see any specific 
reason why I should use -O2 for serious debugging/development sessions?


 and read compiler warnings
Thank you very much for your very helpful advice! :-)


the debuginfo package is your smallest problem

I'm afraid it is not.


you just kill security features like D_FORTIFY_SOURCE with -O0

warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) 
[-Wcpp]

I think my use case justifies it.

--
Petr^2 Spacek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gcc build with -O0 results in corrupted -debuginfo package

[Reindl Harald]

Am 25.04.2014 16:43, schrieb Petr Spacek:
 On 25.4.2014 16:28, Reindl Harald wrote:
 Am 25.04.2014 16:10, schrieb Petr Spacek:
 I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
 CFLAGS=$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb.

 I did the simplest possible thing - edited the original spec file (see 
 spec.diff) and built the package:
 $ rpmbuild -ba bind.spec

 The package builds and BIND itself seems to work. The problem is that new 
 debuginfo package is missing 118 out of
 283 header files in /usr/src/debug/bind-9.9.4-P2.

 It seems that -O0 alone (instead of -O0 -ggdb) causes the same problem.

 I would be glad if anyone can give me advice how to debug this.

 Original packages from Fedora 20 (with all headers in /usr/src/debug):
 http://koji.fedoraproject.org/koji/buildinfo?buildID=502596

 Packages built with -O0 -ggdb (scratch build):
 http://koji.fedoraproject.org/koji/taskinfo?taskID=6778483

 just don't do that
 I'm going to reproduce and debug issue in named. Do you see any specific 
 reason 
 why I should use -O2 for serious debugging/development sessions?

no but then don't include $CFLAGS $RPM_OPT_FLAGS

 and read compiler warnings
 Thank you very much for your very helpful advice! :-)
 
 the debuginfo package is your smallest problem
 I'm afraid it is not

please look at the whole picture of the FLAGS you are using

 you just kill security features like D_FORTIFY_SOURCE with -O0

 warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) 
 [-Wcpp]
 I think my use case justifies it

but it don't justify incompatible flags
IMHO you enter the area of undefined behavior with that

-D_FORTIFY_SOURCE=2 is part of the Fedora default flags



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gcc build with -O0 results in corrupted -debuginfo package

[Petr Spacek]

On 25.4.2014 16:50, Reindl Harald wrote:


Am 25.04.2014 16:43, schrieb Petr Spacek:

On 25.4.2014 16:28, Reindl Harald wrote:

Am 25.04.2014 16:10, schrieb Petr Spacek:

I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
CFLAGS=$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb.

I did the simplest possible thing - edited the original spec file (see 
spec.diff) and built the package:
$ rpmbuild -ba bind.spec

The package builds and BIND itself seems to work. The problem is that new 
debuginfo package is missing 118 out of
283 header files in /usr/src/debug/bind-9.9.4-P2.

It seems that -O0 alone (instead of -O0 -ggdb) causes the same problem.

I would be glad if anyone can give me advice how to debug this.

Original packages from Fedora 20 (with all headers in /usr/src/debug):
http://koji.fedoraproject.org/koji/buildinfo?buildID=502596

Packages built with -O0 -ggdb (scratch build):
http://koji.fedoraproject.org/koji/taskinfo?taskID=6778483


just don't do that

I'm going to reproduce and debug issue in named. Do you see any specific reason
why I should use -O2 for serious debugging/development sessions?


no but then don't include $CFLAGS $RPM_OPT_FLAGS


and read compiler warnings

Thank you very much for your very helpful advice! :-)


the debuginfo package is your smallest problem

I'm afraid it is not


please look at the whole picture of the FLAGS you are using


you just kill security features like D_FORTIFY_SOURCE with -O0

warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) 
[-Wcpp]

I think my use case justifies it


but it don't justify incompatible flags
IMHO you enter the area of undefined behavior with that

-D_FORTIFY_SOURCE=2 is part of the Fedora default flags


For the record, replacing

export CFLAGS=$CFLAGS $RPM_OPT_FLAGS

with

export CFLAGS=-O0 -g

doesn't fix the problem.

--
Petr^2 Spacek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gcc build with -O0 results in corrupted -debuginfo package

[Adam Jackson]

On Fri, 2014-04-25 at 16:50 +0200, Reindl Harald wrote:

 but it don't justify incompatible flags
 IMHO you enter the area of undefined behavior with that

Your humble opinion is misguided, building without _FORTIFY_SOURCE is an
entirely reasonable thing for an end developer to want to do on their
machine, and one we should support.  More importantly I can't think of
any way it would affect debuginfo construction at all.

My first instinct here would be to vary the compiler.  Can you mockbuild
this package against F19's toolchain?  Does that produce working
debuginfo?

- ajax

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gcc build with -O0 results in corrupted -debuginfo package

[Reindl Harald]

Am 25.04.2014 17:10, schrieb Adam Jackson:
 On Fri, 2014-04-25 at 16:50 +0200, Reindl Harald wrote:
 
 but it don't justify incompatible flags
 IMHO you enter the area of undefined behavior with that
 
 Your humble opinion is misguided, building without _FORTIFY_SOURCE is an
 entirely reasonable thing for an end developer to want to do on their
 machine, and one we should support

sorry, but you misunderstood me

what i said was the combination of -O0 *and* -D_FORTIFY_SOURCE=2
or specifically $CFLAGS $RPM_OPT_FLAGS -O0at the same time feels
like undefined behavior because that contains a lot of default
flags including -D_FORTIFY_SOURCE=2



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gcc build with -O0 results in corrupted -debuginfo package

[Kevin Kofler]

Petr Spacek wrote:
 I'm going to reproduce and debug issue in named. Do you see any specific
 reason why I should use -O2 for serious debugging/development sessions?

IMHO, you should always debug with optimization enabled. GDB can cope quite 
well with it, and it is the only way to actually debug the real code that 
gets executed. -O0 makes the code very different from production code, e.g., 
you can get away with more abuse of undefined behavior (and thus, if that 
was the cause of the crashes, you won't find them when debugging under -O0). 
Often, broken code only actually breaks under optimized compilation. This is 
all the more the case for issues triggered by an updated GCC. Even in those 
rare cases where the bug really is in GCC, it is often in an optimization 
pass and thus won't happen under -O0 either.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gcc build with -O0 results in corrupted -debuginfo package

[Adam Jackson]

On Fri, 2014-04-25 at 18:10 +0200, Kevin Kofler wrote:
 Petr Spacek wrote:
  I'm going to reproduce and debug issue in named. Do you see any specific
  reason why I should use -O2 for serious debugging/development sessions?
 
 IMHO, you should always debug with optimization enabled. GDB can cope quite 
 well with it,

ha ha ha ha ha ha ha ha ha ha

No, seriously, he's trying something completely reasonable.  Maybe think
about how to diagnose what's going wrong and fix the bug instead of
philosophizing.

- ajax

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gcc build with -O0 results in corrupted -debuginfo package

[Simo Sorce]

On Fri, 2014-04-25 at 14:03 -0400, Adam Jackson wrote:
 On Fri, 2014-04-25 at 18:10 +0200, Kevin Kofler wrote:
  Petr Spacek wrote:
   I'm going to reproduce and debug issue in named. Do you see any specific
   reason why I should use -O2 for serious debugging/development sessions?
  
  IMHO, you should always debug with optimization enabled. GDB can cope quite 
  well with it,
 
 ha ha ha ha ha ha ha ha ha ha

Sorry I think you missed a few, I'll add my part.

HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA
HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA 


Kevin, have you ever debugged with -O2 ?

It's more than reasonable to want -O0.
At -O2 some code becomes really annoying to follow because gcc will
optimize away way too much of it into registers (and gdb will not print
you the values you need to see) or will make stepping a nightmare with
gdb jumping in an out of the function as it gets inlined and then some
stuff moved out of the original function and things like that.

I've been more than once in gdb with -O2, it is *not* pretty, nor
useful.

debug symbols at -O2 are mostly useful to get backtraces, but if you
need to really step through with gdb in some complicated, highly
optimizable code, often it does not cut it, you have to rebuild with -O0
to regain debuggability and sanity.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gcc build with -O0 results in corrupted -debuginfo package

[Andrew Price]

On 25/04/14 20:10, Simo Sorce wrote:

On Fri, 2014-04-25 at 14:03 -0400, Adam Jackson wrote:

On Fri, 2014-04-25 at 18:10 +0200, Kevin Kofler wrote:

Petr Spacek wrote:

I'm going to reproduce and debug issue in named. Do you see any specific
reason why I should use -O2 for serious debugging/development sessions?


IMHO, you should always debug with optimization enabled.


s/debug/test/ IMHO.


Kevin, have you ever debugged with -O2 ?

It's more than reasonable to want -O0.
At -O2 some code becomes really annoying to follow because gcc will
optimize away way too much of it into registers (and gdb will not print
you the values you need to see) or will make stepping a nightmare with
gdb jumping in an out of the function as it gets inlined and then some
stuff moved out of the original function and things like that.

I've been more than once in gdb with -O2, it is *not* pretty, nor
useful.


+1


debug symbols at -O2 are mostly useful to get backtraces, but if you
need to really step through with gdb in some complicated, highly
optimizable code, often it does not cut it, you have to rebuild with -O0
to regain debuggability and sanity.


-Og (new in gcc 4.8) is meant to enable only optimizations which won't 
confuse gdb but I've not found a need to optimize my code just a little 
bit while debugging yet, so -O0 is still my --enable-debug flag.


Andy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1027305] New: pTk/*.t files in debuginfo package differ in mode on each architecture

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1027305

Bug ID: 1027305
   Summary: pTk/*.t files in debuginfo package differ in mode on
each architecture
   Product: Fedora
   Version: rawhide
 Component: perl-Tk
  Assignee: andreas.bierf...@lowlatency.de
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: andreas.bierf...@lowlatency.de,
perl-devel@lists.fedoraproject.org



Created attachment 820390
  -- https://bugzilla.redhat.com/attachment.cgi?id=820390action=edit
Fix

perl-Tk-debuginfo files not consistent in file mode across all architectures.
This caused by build script regenerating some files based on external
dependencies and features supported on each architecture. This even causes file
mode changes across time.

Attached patch fixes this issue. Please consider applying this patch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=DZLMtyzYzxa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

debuginfo package

[Peter Hatina]

Hi,

can you, please, help me fix these warnings in wireshark package? I get
plenty of warnings when creating debuginfo package, that look like this:

...
cpio: wireshark-1.2.15/asn1/x509if/packet-x509if-dis-tab.c: Cannot stat:
No such file or directory
cpio: wireshark-1.2.15/asn1/x509if/packet-x509if-ett.c: Cannot stat: No
such file or directory
cpio: wireshark-1.2.15/asn1/x509if/packet-x509if-exp.h: Cannot stat: No
such file or directory
...

Does find-debuginfo.sh get confused, or where do those non-existing
files come from?

Thank you in advance.

-- 
Peter Hatina
ENG Server Experience, System Management
Red Hat Czech, Brno
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: debuginfo package

[Jan Kratochvil]

On Tue, 11 Jun 2013 13:37:09 +0200, Peter Hatina wrote:
 cpio: wireshark-1.2.15/asn1/x509if/packet-x509if-dis-tab.c: Cannot stat:
 No such file or directory
[...]
 Does find-debuginfo.sh get confused, or where do those non-existing
 files come from?

They come from #line cpp directives which get compiled into .debug_line DWARF
section (readelf -wl or readelf -wL) and rpmbuild extracts them using:

$ /usr/lib/rpm/debugedit --help
  -l, --list-file=STRING file where to put list of source and header file 
names

In your package:
$ grep -r packet-x509if-ett.c .
./wireshark-1.8.6/asn1/x509if/packet-x509if-template.c:#include 
packet-x509if-ett.c
./wireshark-1.8.6/epan/dissectors/packet-x509if.c:/*--- Included file: 
packet-x509if-ett.c ---*/
./wireshark-1.8.6/epan/dissectors/packet-x509if.c:#line 1 
../../asn1/x509if/packet-x509if-ett.c
./wireshark-1.8.6/epan/dissectors/packet-x509if.c:/*--- End of included file: 
packet-x509if-ett.c ---*/
$ find -name packet-x509if-ett.c 
$ _

I did not check how to generate asn1/x509if/packet-x509if-ett.c and/or how to
regenerate epan/dissectors/packet-x509if.c , that is up to you as the package
maintainer.


Regards,
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: debuginfo package

[Richard W.M. Jones]

On Tue, Jun 11, 2013 at 03:24:51PM +0200, Jan Kratochvil wrote:
 On Tue, 11 Jun 2013 13:37:09 +0200, Peter Hatina wrote:
  cpio: wireshark-1.2.15/asn1/x509if/packet-x509if-dis-tab.c: Cannot stat:
  No such file or directory
 [...]
  Does find-debuginfo.sh get confused, or where do those non-existing
  files come from?
 
 They come from #line cpp directives which get compiled into .debug_line DWARF
 section (readelf -wl or readelf -wL) and rpmbuild extracts them using:
 
 $ /usr/lib/rpm/debugedit --help
   -l, --list-file=STRING file where to put list of source and header file 
 names

Interesting .. that explains a bug in OCaml builds too:

[source: 
http://kojipkgs.fedoraproject.org//packages/libguestfs/1.23.3/1.fc20/data/logs/x86_64/build.log]

| cpio: libguestfs-1.23.3/resize/list.ml: Cannot stat: No such file or directory
| cpio: libguestfs-1.23.3/resize/str.ml: Cannot stat: No such file or directory
| cpio: libguestfs-1.23.3/resize/string.ml: Cannot stat: No such file or 
directory

This is probably incorrect DWARF information.  Modules like 'list.ml'
are actually from the OCaml stdlib, so the paths should refer to
%{_libdir}/ocaml/list.ml etc.  However we don't in fact ship those
files at all in the OCaml compiler binary package.

BTW, `eu-readelf -w /usr/bin/virt-resize' didn't show anything
suspicious.

| cpio: ocaml-4.00.1/stdlib: Cannot stat: No such file or directory
| cpio: ocaml-4.00.1/stdlib/std_exit.ml: Cannot stat: No such file or directory

These paths are very strange.  They are source paths inside the OCaml
compiler source package.  I've no idea how they end up being displayed
during the build of something unrelated.

Note that the OCaml compiler generates its own DWARF.  It's got
nothing to do with gcc.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: debuginfo package

[Jan Kratochvil]

On Tue, 11 Jun 2013 15:59:15 +0200, Richard W.M. Jones wrote:
 Interesting .. that explains a bug in OCaml builds too:

In fact this bug is very common across packages, there was an attempt to check
all the debuginfos and possibly file Bugs but it has never been finished:
Bugs in debuginfo packages

https://lists.fedoraproject.org/pipermail/devel/2011-February/149022.html

I sometimes file a Bug for this or that debuginfo deficiency I see but sure
that does not scale.


 BTW, `eu-readelf -w /usr/bin/virt-resize' didn't show anything
 suspicious.

This will print you only .eh_frame which is present in the main binary.
.eh_frame contains no source files information.
.debug_line is present only in the separate .debug file:
eu-readelf -w /usr/lib/debug/usr/bin/virt-resize.debug

For eu-readelf the interesting part (readelf -wl equivalent) is: -wline
eu-readelf AFAIK does not have readelf -wL equivalent (decoded line info).


Regards,
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)

[Kevin Kofler]

Mark Wielaard wrote:
 Aha, thanks. Yes using DWARF might help getting more user
 friendly/recognizable names.
 
 Though note that the name we were really looking for was
 setsockcreatecon, since that is what was called from main. I think that
 one is doing a tail-call to setprocattrcon.constprop.2 so might not
 easily be available in the backtrace. If you compile and run Richard's
 reproducer from https://bugzilla.redhat.com/show_bug.cgi?id=918572 and
 break at the strdup call, can you get a backtrace from gdb with
 setsockcreatecon in it?
 
 Also using DWARF .debug_info will only work if it is available. By
 default valgrind doesn't require DWARF, it uses only the symbol table. I
 can look in extending valgrind to use the DWARF info when available for
 matching suppressions, but that might mean a suppression only works when
 the debuginfo is installed (and it might make valgrind even slower).

To go from setprocattrcon.constprop.2 (the ELF symbol name) to 
setprocattrcon (the name in DWARF), you don't need the DWARF at all, just a 
s/\.constprop\.[0-9]+$//g. :-)

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)

[Jan Kratochvil]

On Wed, 06 Mar 2013 16:13:47 +0100, Mark Wielaard wrote:
 On Wed, 2013-03-06 at 14:38 +, Richard W.M. Jones wrote:
[...]
  ==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6
  ==11843==at 0x4A06409: malloc (in 
  /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==11843==by 0x38EAC861F9: strdup (strdup.c:42)
  ==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3 
  (procattr.c:241)
  ==11843==by 0x38EC8099B7: setprocattrcon.constprop.2 (procattr.c:274)
  ==11843==by 0x400955: main (in /tmp/test)
[...]
 It looks like you will have to use the setprocattrcon[.constprop]
 function name in your suppression file. I am not exactly sure how the
 linker ends up pointing directly to that one for setsockcreatecon (),
 but it apparently is. And so valgrind will only know it by that name.

Symbol table '.symtab' contains 770 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
70: 999062 FUNCLOCAL  DEFAULT   11 
setprocattrcon.constprop.2

Contents of the .debug_info section:
 162c6: Abbrev Number: 58 (DW_TAG_subprogram)
62c7   DW_AT_name: (indirect string, offset: 0x3eb4): 
setprocattrcon
62d2   DW_AT_inline  : 1  (inlined)
 16791: Abbrev Number: 40 (DW_TAG_subprogram)
6792   DW_AT_abstract_origin: 0x62c6
6794   DW_AT_low_pc  : 0x9990
679c   DW_AT_high_pc : 62

Valgrind apparently used the ELF symbol name.  But in DWARF there is the real
function name (and it is even marked as 'inlined' - although it is a standalone
function).

GDB also knows the real name from DWARF:

(gdb) disas 'setprocattrcon.constprop.2'
Dump of assembler code for function setprocattrcon:
   0x9990 +0: push   %rbx
[...]
   0x99cd +61:retq   
End of assembler dump.

So it is possible to fix it in Valgrind.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)

[Mark Wielaard]

On Thu, 2013-03-07 at 09:42 +0100, Jan Kratochvil wrote:
 On Wed, 06 Mar 2013 16:13:47 +0100, Mark Wielaard wrote:
  On Wed, 2013-03-06 at 14:38 +, Richard W.M. Jones wrote:
 [...]
   ==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6
   ==11843==at 0x4A06409: malloc (in 
   /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
   ==11843==by 0x38EAC861F9: strdup (strdup.c:42)
   ==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3 
   (procattr.c:241)
   ==11843==by 0x38EC8099B7: setprocattrcon.constprop.2 (procattr.c:274)
   ==11843==by 0x400955: main (in /tmp/test)
 [...]
  It looks like you will have to use the setprocattrcon[.constprop]
  function name in your suppression file. I am not exactly sure how the
  linker ends up pointing directly to that one for setsockcreatecon (),
  but it apparently is. And so valgrind will only know it by that name.
 
 Symbol table '.symtab' contains 770 entries:
Num:Value  Size TypeBind   Vis  Ndx Name
 70: 999062 FUNCLOCAL  DEFAULT   11 
 setprocattrcon.constprop.2
 
 Contents of the .debug_info section:
  162c6: Abbrev Number: 58 (DW_TAG_subprogram)
 62c7   DW_AT_name: (indirect string, offset: 0x3eb4): 
 setprocattrcon
 62d2   DW_AT_inline  : 1  (inlined)
  16791: Abbrev Number: 40 (DW_TAG_subprogram)
 6792   DW_AT_abstract_origin: 0x62c6
 6794   DW_AT_low_pc  : 0x9990
 679c   DW_AT_high_pc : 62
 
 Valgrind apparently used the ELF symbol name.  But in DWARF there is the real
 function name (and it is even marked as 'inlined' - although it is a 
 standalone
 function).
 
 GDB also knows the real name from DWARF:
 
 (gdb) disas 'setprocattrcon.constprop.2'
 Dump of assembler code for function setprocattrcon:
0x9990 +0:   push   %rbx
 [...]
0x99cd +61:  retq   
 End of assembler dump.
 
 So it is possible to fix it in Valgrind.

Aha, thanks. Yes using DWARF might help getting more user
friendly/recognizable names.

Though note that the name we were really looking for was
setsockcreatecon, since that is what was called from main. I think that
one is doing a tail-call to setprocattrcon.constprop.2 so might not
easily be available in the backtrace. If you compile and run Richard's
reproducer from https://bugzilla.redhat.com/show_bug.cgi?id=918572 and
break at the strdup call, can you get a backtrace from gdb with
setsockcreatecon in it?

Also using DWARF .debug_info will only work if it is available. By
default valgrind doesn't require DWARF, it uses only the symbol table. I
can look in extending valgrind to use the DWARF info when available for
matching suppressions, but that might mean a suppression only works when
the debuginfo is installed (and it might make valgrind even slower).

Cheers,

Mark

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)

[Richard W.M. Jones]

On Thu, Mar 07, 2013 at 10:10:56AM +0100, Mark Wielaard wrote:
 On Thu, 2013-03-07 at 09:42 +0100, Jan Kratochvil wrote:
  On Wed, 06 Mar 2013 16:13:47 +0100, Mark Wielaard wrote:
   On Wed, 2013-03-06 at 14:38 +, Richard W.M. Jones wrote:
  [...]
==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6
==11843==at 0x4A06409: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==11843==by 0x38EAC861F9: strdup (strdup.c:42)
==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3 
(procattr.c:241)
==11843==by 0x38EC8099B7: setprocattrcon.constprop.2 
(procattr.c:274)
==11843==by 0x400955: main (in /tmp/test)
  [...]
   It looks like you will have to use the setprocattrcon[.constprop]
   function name in your suppression file. I am not exactly sure how the
   linker ends up pointing directly to that one for setsockcreatecon (),
   but it apparently is. And so valgrind will only know it by that name.
  
  Symbol table '.symtab' contains 770 entries:
 Num:Value  Size TypeBind   Vis  Ndx Name
  70: 999062 FUNCLOCAL  DEFAULT   11 
  setprocattrcon.constprop.2
  
  Contents of the .debug_info section:
   162c6: Abbrev Number: 58 (DW_TAG_subprogram)
  62c7   DW_AT_name: (indirect string, offset: 0x3eb4): 
  setprocattrcon
  62d2   DW_AT_inline  : 1  (inlined)
   16791: Abbrev Number: 40 (DW_TAG_subprogram)
  6792   DW_AT_abstract_origin: 0x62c6
  6794   DW_AT_low_pc  : 0x9990
  679c   DW_AT_high_pc : 62
  
  Valgrind apparently used the ELF symbol name.  But in DWARF there is the 
  real
  function name (and it is even marked as 'inlined' - although it is a 
  standalone
  function).
  
  GDB also knows the real name from DWARF:
  
  (gdb) disas 'setprocattrcon.constprop.2'
  Dump of assembler code for function setprocattrcon:
 0x9990 +0: push   %rbx
  [...]
 0x99cd +61:retq   
  End of assembler dump.
  
  So it is possible to fix it in Valgrind.
 
 Aha, thanks. Yes using DWARF might help getting more user
 friendly/recognizable names.
 
 Though note that the name we were really looking for was
 setsockcreatecon, since that is what was called from main. I think that
 one is doing a tail-call to setprocattrcon.constprop.2 so might not
 easily be available in the backtrace. If you compile and run Richard's
 reproducer from https://bugzilla.redhat.com/show_bug.cgi?id=918572 and
 break at the strdup call, can you get a backtrace from gdb with
 setsockcreatecon in it?

The answer seems to be no.  This is on a very up to date Rawhide:

Breakpoint 2, __GI___strdup (
s=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023)
at strdup.c:40
40  {
(gdb) bt
#0  __GI___strdup (
s=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023)
at strdup.c:40
#1  0x0038ec8097ca in setprocattrcon_raw (
context=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023, 
attr=attr@entry=0x38ec8181f6 sockcreate, pid=0) at procattr.c:241
#2  0x0038ec8099b8 in setprocattrcon (context=optimized out, 
attr=0x38ec8181f6 sockcreate, pid=0) at procattr.c:274
#3  0x00400956 in main () at test.c:33

 Also using DWARF .debug_info will only work if it is available. By
 default valgrind doesn't require DWARF, it uses only the symbol table. I
 can look in extending valgrind to use the DWARF info when available for
 matching suppressions, but that might mean a suppression only works when
 the debuginfo is installed (and it might make valgrind even slower).

Actually we found that our suppressions only work properly when we're
careful to install debuginfo packages.  Otherwise some of the patterns
don't match and we get false positives.

Here's our suppressions file FWIW:

https://github.com/libguestfs/libguestfs/blob/master/valgrind-suppressions

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)

[Richard W.M. Jones]

On Thu, Mar 07, 2013 at 10:55:58AM +, Richard W.M. Jones wrote:
 The answer seems to be no.  This is on a very up to date Rawhide:
 
 Breakpoint 2, __GI___strdup (
 s=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023)
 at strdup.c:40
 40  {
 (gdb) bt
 #0  __GI___strdup (
 s=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023)
 at strdup.c:40
 #1  0x0038ec8097ca in setprocattrcon_raw (
 context=0x6021e0 
 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023, 
 attr=attr@entry=0x38ec8181f6 sockcreate, pid=0) at procattr.c:241
 #2  0x0038ec8099b8 in setprocattrcon (context=optimized out, 
 attr=0x38ec8181f6 sockcreate, pid=0) at procattr.c:274
 #3  0x00400956 in main () at test.c:33

Note: libselinux-debuginfo-2.1.13-6.fc19.x86_64 is installed.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)

[Jan Kratochvil]

On Wed, 06 Mar 2013 15:38:54 +0100, Richard W.M. Jones wrote:
 ==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6
 ==11843==at 0x4A06409: malloc (in 
 /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
 ==11843==by 0x38EAC861F9: strdup (strdup.c:42)
 ==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3 (procattr.c:241)
 ==11843==by 0x38EC8099B7: setprocattrcon.constprop.2 (procattr.c:274)
 ==11843==by 0x400955: main (in /tmp/test)
 
 The symbol we're actually calling is 'setsockcreatecon'.  It's not a
 macro.  There is no public function called 'setprocattrcon'
[...]
On Thu, 07 Mar 2013 10:10:56 +0100, Mark Wielaard wrote:
 Though note that the name we were really looking for was
 setsockcreatecon, since that is what was called from main. I think that
 one is doing a tail-call to setprocattrcon.constprop.2 so might not
 easily be available in the backtrace. If you compile and run Richard's
 reproducer from https://bugzilla.redhat.com/show_bug.cgi?id=918572 and
 break at the strdup call, can you get a backtrace from gdb with
 setsockcreatecon in it?

Yes:

(gdb) bt
#0  __GI___strdup (s=0x6021e0 
unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023) at strdup.c:40
#1  0x77bc27ca in setprocattrcon_raw (context=0x6021e0 
unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023, 
attr=attr@entry=0x77bd11f6 sockcreate, pid=0) at procattr.c:241
#2  0x77bc29b8 in setprocattrcon (context=optimized out, 
attr=attr@entry=0x77bd11f6 sockcreate, pid=0) at procattr.c:274
#3  0x77bc2ddc in setsockcreatecon (c=optimized out) at procattr.c:320
#4  0x00400818 in main () at constprop.c:33
(gdb) info frame 3
Stack frame at 0x7fffe130:
 rip = 0x77bc2ddc in setsockcreatecon (procattr.c:320); saved rip 
0x7781ab75
 tail call frame, caller of frame at 0x7fffe130
 ^^^
 source language c.
 Arglist at unknown address.
 Locals at unknown address, Previous frame's sp is 0x7fffe130

But one has to compile the main program with -O2 -g so that it has the needed
call site debug information:
gcc -Wall constprop.c -o constprop -lselinux -g -O2

 237e: Abbrev Number: 21 (DW_TAG_GNU_call_site)
37f   DW_AT_low_pc  : 0x400818
387   DW_AT_abstract_origin: 0x515
 1515: Abbrev Number: 24 (DW_TAG_subprogram)
516   DW_AT_name: (indirect string, offset: 0x11): 
setsockcreatecon
520   DW_AT_declaration : 1


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)

[Mark Wielaard]

On Thu, 2013-03-07 at 13:42 +0100, Jan Kratochvil wrote:
 On Wed, 06 Mar 2013 15:38:54 +0100, Richard W.M. Jones wrote:
  ==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6
  ==11843==at 0x4A06409: malloc (in 
  /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==11843==by 0x38EAC861F9: strdup (strdup.c:42)
  ==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3 
  (procattr.c:241)
  ==11843==by 0x38EC8099B7: setprocattrcon.constprop.2 (procattr.c:274)
  ==11843==by 0x400955: main (in /tmp/test)
  
  The symbol we're actually calling is 'setsockcreatecon'.  It's not a
  macro.  There is no public function called 'setprocattrcon'
 [...]
 On Thu, 07 Mar 2013 10:10:56 +0100, Mark Wielaard wrote:
  Though note that the name we were really looking for was
  setsockcreatecon, since that is what was called from main. I think that
  one is doing a tail-call to setprocattrcon.constprop.2 so might not
  easily be available in the backtrace. If you compile and run Richard's
  reproducer from https://bugzilla.redhat.com/show_bug.cgi?id=918572 and
  break at the strdup call, can you get a backtrace from gdb with
  setsockcreatecon in it?
 
 Yes:
 
 (gdb) bt
 #0  __GI___strdup (s=0x6021e0 
 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023) at strdup.c:40
 #1  0x77bc27ca in setprocattrcon_raw (context=0x6021e0 
 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023, 
 attr=attr@entry=0x77bd11f6 sockcreate, pid=0) at procattr.c:241
 #2  0x77bc29b8 in setprocattrcon (context=optimized out, 
 attr=attr@entry=0x77bd11f6 sockcreate, pid=0) at procattr.c:274
 #3  0x77bc2ddc in setsockcreatecon (c=optimized out) at 
 procattr.c:320
 #4  0x00400818 in main () at constprop.c:33
 (gdb) info frame 3
 Stack frame at 0x7fffe130:
  rip = 0x77bc2ddc in setsockcreatecon (procattr.c:320); saved rip 
 0x7781ab75
  tail call frame, caller of frame at 0x7fffe130
  ^^^
  source language c.
  Arglist at unknown address.
  Locals at unknown address, Previous frame's sp is 0x7fffe130
 
 But one has to compile the main program with -O2 -g so that it has the needed
 call site debug information:
   gcc -Wall constprop.c -o constprop -lselinux -g -O2

O, very nice! It is kind of funny that gcc generates better/fuller
debuginfo with higher optimizations these days.

Currently valgrind doesn't handle DW_TAG_GNU_call_site at all. But if
people install debuginfo anyway to get better backtraces and/or symbol
resolution it might make sense to teach valgrind about it.

Thanks,

Mark

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)

[Jan Kratochvil]

On Thu, 07 Mar 2013 14:20:40 +0100, Mark Wielaard wrote:
 It is kind of funny that gcc generates better/fuller
 debuginfo with higher optimizations these days.

There is even -Og for debugging as the best of -O0 and -O2 but I do not have
much practical experience with it yet.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)

[Richard W.M. Jones]

On Thu, Mar 07, 2013 at 02:20:40PM +0100, Mark Wielaard wrote:
 On Thu, 2013-03-07 at 13:42 +0100, Jan Kratochvil wrote:
  On Wed, 06 Mar 2013 15:38:54 +0100, Richard W.M. Jones wrote:
   ==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6
   ==11843==at 0x4A06409: malloc (in 
   /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
   ==11843==by 0x38EAC861F9: strdup (strdup.c:42)
   ==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3 
   (procattr.c:241)
   ==11843==by 0x38EC8099B7: setprocattrcon.constprop.2 (procattr.c:274)
   ==11843==by 0x400955: main (in /tmp/test)
   
   The symbol we're actually calling is 'setsockcreatecon'.  It's not a
   macro.  There is no public function called 'setprocattrcon'
  [...]
  On Thu, 07 Mar 2013 10:10:56 +0100, Mark Wielaard wrote:
   Though note that the name we were really looking for was
   setsockcreatecon, since that is what was called from main. I think that
   one is doing a tail-call to setprocattrcon.constprop.2 so might not
   easily be available in the backtrace. If you compile and run Richard's
   reproducer from https://bugzilla.redhat.com/show_bug.cgi?id=918572 and
   break at the strdup call, can you get a backtrace from gdb with
   setsockcreatecon in it?
  
  Yes:
  
  (gdb) bt
  #0  __GI___strdup (s=0x6021e0 
  unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023) at strdup.c:40
  #1  0x77bc27ca in setprocattrcon_raw (context=0x6021e0 
  unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023, 
  attr=attr@entry=0x77bd11f6 sockcreate, pid=0) at procattr.c:241
  #2  0x77bc29b8 in setprocattrcon (context=optimized out, 
  attr=attr@entry=0x77bd11f6 sockcreate, pid=0) at procattr.c:274
  #3  0x77bc2ddc in setsockcreatecon (c=optimized out) at 
  procattr.c:320
  #4  0x00400818 in main () at constprop.c:33
  (gdb) info frame 3
  Stack frame at 0x7fffe130:
   rip = 0x77bc2ddc in setsockcreatecon (procattr.c:320); saved rip 
  0x7781ab75
   tail call frame, caller of frame at 0x7fffe130
   ^^^
   source language c.
   Arglist at unknown address.
   Locals at unknown address, Previous frame's sp is 0x7fffe130
  
  But one has to compile the main program with -O2 -g so that it has the 
  needed
  call site debug information:
  gcc -Wall constprop.c -o constprop -lselinux -g -O2
 
 O, very nice! It is kind of funny that gcc generates better/fuller
 debuginfo with higher optimizations these days.
 
 Currently valgrind doesn't handle DW_TAG_GNU_call_site at all. But if
 people install debuginfo anyway to get better backtraces and/or symbol
 resolution it might make sense to teach valgrind about it.

I can also confirm that with -O2 the correct symbol is shown in the
gdb stack trace on Rawhide.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)

[Richard W.M. Jones]

On Mon, Mar 04, 2013 at 02:15:30PM +0100, Mark Wielaard wrote:
 Hi,
 
 I am looking for some valgrind users that want to try out the latest
 valgrind package in rawhide.
 
 If you use valgrind please try out the new valgrind-3.8.1-10.fc19
 version in rawhide. It is the first version that puts the debuginfo in a
 separate valgrind-debuginfo package (this saves ~35MB from the main
 packages). http://koji.fedoraproject.org/koji/buildinfo?buildID=399059
 
 Upstream used to recommend against stripping debuginfo from the valgrind
 vg preload libraries because it produced less usable warning/error
 messages. But since a long time now valgrind intercepts are done in a
 different way and just having the dynsym symbols around should be
 enough.
 
 Please let me know (or file a bug report) if using the new valgrind
 package from rawhide gives less useful warnings/errors (and whether
 installing valgrind-debuginfo solves any of such issues).

I tested valgrind-3.8.1-10.fc19.x86_64 (without valgrind-debuginfo).
It appears to work fine.  There's no noticable difference between this
version and earlier versions.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)

[Richard W.M. Jones]

BTW can you clear up a peculiarity I've noticed in valgrind in
Rawhide?

The symbols reported in the stack traces seem to be mangled in a
strange way, eg:

==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6
==11843==at 0x4A06409: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==11843==by 0x38EAC861F9: strdup (strdup.c:42)
==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3 (procattr.c:241)
==11843==by 0x38EC8099B7: setprocattrcon.constprop.2 (procattr.c:274)
==11843==by 0x400955: main (in /tmp/test)

The symbol we're actually calling is 'setsockcreatecon'.  It's not a
macro.  There is no public function called 'setprocattrcon' (although
there is an internal function of that name and setsockcreatecon only
calls this internal functions so there could be some inlining going
on).  And what's with the '.constprop.2' suffix?

In any case, this is a problem because in my valgrind suppressions
file I have to list the mangled name, not the real name.

Test program is here if you want to try it:

https://bugzilla.redhat.com/show_bug.cgi?id=918572

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)

[Mark Wielaard]

On Wed, 2013-03-06 at 14:38 +, Richard W.M. Jones wrote:
 BTW can you clear up a peculiarity I've noticed in valgrind in
 Rawhide?
 
 The symbols reported in the stack traces seem to be mangled in a
 strange way, eg:
 
 ==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6
 ==11843==at 0x4A06409: malloc (in 
 /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
 ==11843==by 0x38EAC861F9: strdup (strdup.c:42)
 ==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3 (procattr.c:241)
 ==11843==by 0x38EC8099B7: setprocattrcon.constprop.2 (procattr.c:274)
 ==11843==by 0x400955: main (in /tmp/test)
 
 The symbol we're actually calling is 'setsockcreatecon'.  It's not a
 macro.  There is no public function called 'setprocattrcon' (although
 there is an internal function of that name and setsockcreatecon only
 calls this internal functions so there could be some inlining going
 on).  And what's with the '.constprop.2' suffix?

Right, there is something like inlining going on. Though not actual
inlining, more like calling specialied variants of the function. Some
GCC hacker might correct me if I get the details wrong. But I think this
is just caused by (better) optimization of GCC 4.8 in rawhide. As far as
I understand it GCC sees that setsockcreatecon (NULL) is really
setprocattrcon with some constant arguments call. The src/procattr.c
definition of all_selfattr_def(sockcreatecon, sockcreate) make it a
little hard to see exactly, but obviously GCC knows. For example the pid
argument will always be zero. Because of this GCC creates a specialized
constant propagation function based on setprocattrcon called
setprocattrcon.constprop.somenumber. And as far as I can see that is the
actual function that the setsockcreatecon function PLT entry points to.
(And this setprocattrcon.constprop.2 then calls a specialized constant
propagation function version of setprocattrcon_raw.)

 In any case, this is a problem because in my valgrind suppressions
 file I have to list the mangled name, not the real name.

It looks like you will have to use the setprocattrcon[.constprop]
function name in your suppression file. I am not exactly sure how the
linker ends up pointing directly to that one for setsockcreatecon (),
but it apparently is. And so valgrind will only know it by that name.
Sorry.

Note that you can let valgrind create the suppression for you with
--gen-suppressions=yes. And you can also use wildcards in suppressions
like fun:setprocattrcon.constprop.*.

Cheers,

Mark

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Testing valgrind in rawhide (separate valgrind-debuginfo package)

[Mark Wielaard]

Hi,

I am looking for some valgrind users that want to try out the latest
valgrind package in rawhide.

If you use valgrind please try out the new valgrind-3.8.1-10.fc19
version in rawhide. It is the first version that puts the debuginfo in a
separate valgrind-debuginfo package (this saves ~35MB from the main
packages). http://koji.fedoraproject.org/koji/buildinfo?buildID=399059

Upstream used to recommend against stripping debuginfo from the valgrind
vg preload libraries because it produced less usable warning/error
messages. But since a long time now valgrind intercepts are done in a
different way and just having the dynsym symbols around should be
enough.

Please let me know (or file a bug report) if using the new valgrind
package from rawhide gives less useful warnings/errors (and whether
installing valgrind-debuginfo solves any of such issues).

Thanks,

Mark

BTW. I also backported some issues that showed up with the new kernel
and glibc to the f18 valgrind package, but obviously not the debuginfo
separation. Testers for valgrind-3.8.1-9.fc18 currently in
updates-testing also welcome. But this update should just contains
benign bugfixes since it is targetted for stable.
https://admin.fedoraproject.org/updates/FEDORA-2013-3322/valgrind-3.8.1-9.fc18

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Problems when install kernel-debuginfo package

[xning]

Hi,
I want to install kernel-debuginfo package, and get the following msg,
[root@localhost pkger]# yum clean all;debuginfo-install kernel
Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit
Cleaning repos: fedora updates
Cleaning up Everything
No delta-package files removed by presto
Loaded plugins: auto-update-debuginfo, presto, refresh-packagekit
enabling fedora-debuginfo
enabling updates-debuginfo
fedora/18/x86_64/metalink| 8.6 kB 
00:00
fedora   | 4.2 kB 
00:00
updates/18/x86_64/metalink   | 5.9 kB 
00:00
updates  | 4.7 kB 
00:00
(1/2): updates/primary_db  | 7.4 MB 
00:16
(2/2): fedora/primary_db   |  17 MB 
00:36

Could not find debuginfo for main pkg: kernel-3.7.8-202.fc18.x86_64
Package yum-plugin-auto-update-debug-info-1.1.31-9.fc18.noarch already 
installed and latest version

-- Running transaction check
--- Package kernel-debuginfo.x86_64 0:3.6.10-4.fc18 will be installed
-- Processing Dependency: kernel-debuginfo-common-x86_64 = 
3.6.10-4.fc18 for package: kernel-debuginfo-3.6.10-4.fc18.x86_64

--- Package kernel-debuginfo.x86_64 0:3.7.9-201.fc18 will be installed
-- Finished Dependency Resolution
Error: Package: kernel-debuginfo-3.6.10-4.fc18.x86_64 (fedora-debuginfo)
   Requires: kernel-debuginfo-common-x86_64 = 3.6.10-4.fc18
   Installed: 
kernel-debuginfo-common-x86_64-3.7.9-201.fc18.x86_64 (@updates-debuginfo)

   kernel-debuginfo-common-x86_64 = 3.7.9-201.fc18
   Available: 
kernel-debuginfo-common-x86_64-3.6.10-4.fc18.x86_64 (fedora-debuginfo)

   kernel-debuginfo-common-x86_64 = 3.6.10-4.fc18
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
[root@localhost pkger]#


Thanks,
xning

--
Xibo Ning
Hosted and shared services
Red Hat Asia Pacific
IRC Account: xning at #hss #eng-china #libra
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?

[Jan Kratochvil]

On Fri, 16 Mar 2012 20:46:16 +0100, Martin Langhoff wrote:
 Argh, that could be. But our kernel is a custom built rpm,

You have a bug for Fedora there, in the core file by readelf -l:
Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
[...]
  LOAD  0x1933000 0xa7703000 0x 0x0 0x174000 R E 0x1000
^^^
There is normally 0x1000 on x86* Fedora kernels due to:
$ cat /proc/self/coredump_filter 
0033

/usr/share/doc/kernel-doc-*/Documentation/filesystems/proc.txt
  - (bit 4) ELF header pages in file-backed private memory areas (it is
effective only if the bit 2 is cleared)

This way build-id for the executable and shared libraries is dumped in the
core file but it is missing in this OLPC kernel.  Fedora GDB has not yet
upstreamed patch for build-id which did not expect such core files.

Going to push a fix for F-15+ but F-14 is EOLed, you can either use FSF GDB or
patch Fedora GDB by this patch or use F-15+ GDB etc.

That backtrace of core.522 FYI is at:
http://people.redhat.com/jkratoch/sandisk.bt


Thanks,
Jan
--- gdb-7.2/gdb/solib-svr4.c.orig   2012-03-17 09:39:54.874090162 +0100
+++ gdb-7.2/gdb/solib-svr4.c2012-03-17 09:42:12.561810807 +0100
@@ -1202,14 +1202,30 @@ svr4_current_sos (void)
}
  else
{
- struct build_id *build_id;
+ struct build_id *build_id = NULL;
 
  strncpy (new-so_original_name, buffer, SO_NAME_MAX_PATH_SIZE - 
1);
  new-so_original_name[SO_NAME_MAX_PATH_SIZE - 1] = '\0';
  /* May get overwritten below.  */
  strcpy (new-so_name, new-so_original_name);
 
- build_id = build_id_addr_get (LM_DYNAMIC_FROM_LINK_MAP (new));
+ /* In the case the main executable was found according to its
+build-id (from a core file) prevent loading a different build
+of a library with accidentally the same SO_NAME.
+
+It suppresses bogus backtraces (and prints ?? there instead)
+if the on-disk files no longer match the running program
+version.
+
+If the main executable was not loaded according to its
+build-id do not do any build-id checking of the libraries.
+There may be missing build-ids dumped in the core file and we
+would map all the libraries to the only existing file loaded
+that time - the executable.  */
+
+ if (symfile_objfile != NULL
+  (symfile_objfile-flags  OBJF_BUILD_ID_CORE_LOADED) != 0)
+   build_id = build_id_addr_get (LM_DYNAMIC_FROM_LINK_MAP (new));
  if (build_id != NULL)
{
  char *name, *build_id_filename;
@@ -1224,23 +1240,7 @@ svr4_current_sos (void)
  xfree (name);
}
  else
-   {
- debug_print_missing (new-so_name, build_id_filename);
-
- /* In the case the main executable was found according to
-its build-id (from a core file) prevent loading
-a different build of a library with accidentally the
-same SO_NAME.
-
-It suppresses bogus backtraces (and prints ?? there
-instead) if the on-disk files no longer match the
-running program version.  */
-
- if (symfile_objfile != NULL
-  (symfile_objfile-flags
-  OBJF_BUILD_ID_CORE_LOADED) != 0)
-   new-so_name[0] = 0;
-   }
+   debug_print_missing (new-so_name, build_id_filename);
 
  xfree (build_id_filename);
  xfree (build_id);
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?

[Martin Langhoff]

Hi Jan,

that's enormously useful -- thanks! I'll make sure we fix our kernel
options so this isn't an issue in the future.

And I'll patch my gdb so I can read the other stacktraces.

cheers -


m

On Sat, Mar 17, 2012 at 4:56 AM, Jan Kratochvil
jan.kratoch...@redhat.com wrote:
 On Fri, 16 Mar 2012 20:46:16 +0100, Martin Langhoff wrote:
 Argh, that could be. But our kernel is a custom built rpm,

 You have a bug for Fedora there, in the core file by readelf -l:
 Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
 [...]
  LOAD          0x1933000 0xa7703000 0x 0x0 0x174000 R E 0x1000
                                                ^^^
 There is normally 0x1000 on x86* Fedora kernels due to:
 $ cat /proc/self/coredump_filter
 0033

 /usr/share/doc/kernel-doc-*/Documentation/filesystems/proc.txt
  - (bit 4) ELF header pages in file-backed private memory areas (it is
            effective only if the bit 2 is cleared)

 This way build-id for the executable and shared libraries is dumped in the
 core file but it is missing in this OLPC kernel.  Fedora GDB has not yet
 upstreamed patch for build-id which did not expect such core files.

 Going to push a fix for F-15+ but F-14 is EOLed, you can either use FSF GDB or
 patch Fedora GDB by this patch or use F-15+ GDB etc.

 That backtrace of core.522 FYI is at:
        http://people.redhat.com/jkratoch/sandisk.bt


 Thanks,
 Jan

 --- gdb-7.2/gdb/solib-svr4.c.orig       2012-03-17 09:39:54.874090162 +0100
 +++ gdb-7.2/gdb/solib-svr4.c    2012-03-17 09:42:12.561810807 +0100
 @@ -1202,14 +1202,30 @@ svr4_current_sos (void)
            }
          else
            {
 -             struct build_id *build_id;
 +             struct build_id *build_id = NULL;

              strncpy (new-so_original_name, buffer, SO_NAME_MAX_PATH_SIZE - 
 1);
              new-so_original_name[SO_NAME_MAX_PATH_SIZE - 1] = '\0';
              /* May get overwritten below.  */
              strcpy (new-so_name, new-so_original_name);

 -             build_id = build_id_addr_get (LM_DYNAMIC_FROM_LINK_MAP (new));
 +             /* In the case the main executable was found according to its
 +                build-id (from a core file) prevent loading a different build
 +                of a library with accidentally the same SO_NAME.
 +
 +                It suppresses bogus backtraces (and prints ?? there 
 instead)
 +                if the on-disk files no longer match the running program
 +                version.
 +
 +                If the main executable was not loaded according to its
 +                build-id do not do any build-id checking of the libraries.
 +                There may be missing build-ids dumped in the core file and we
 +                would map all the libraries to the only existing file loaded
 +                that time - the executable.  */
 +
 +             if (symfile_objfile != NULL
 +                  (symfile_objfile-flags  OBJF_BUILD_ID_CORE_LOADED) != 
 0)
 +               build_id = build_id_addr_get (LM_DYNAMIC_FROM_LINK_MAP (new));
              if (build_id != NULL)
                {
                  char *name, *build_id_filename;
 @@ -1224,23 +1240,7 @@ svr4_current_sos (void)
                      xfree (name);
                    }
                  else
 -                   {
 -                     debug_print_missing (new-so_name, build_id_filename);
 -
 -                     /* In the case the main executable was found according 
 to
 -                        its build-id (from a core file) prevent loading
 -                        a different build of a library with accidentally the
 -                        same SO_NAME.
 -
 -                        It suppresses bogus backtraces (and prints ?? there
 -                        instead) if the on-disk files no longer match the
 -                        running program version.  */
 -
 -                     if (symfile_objfile != NULL
 -                          (symfile_objfile-flags
 -                              OBJF_BUILD_ID_CORE_LOADED) != 0)
 -                       new-so_name[0] = 0;
 -                   }
 +                   debug_print_missing (new-so_name, build_id_filename);

                  xfree (build_id_filename);
                  xfree (build_id);

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel



-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?

[Martin Langhoff]

On Fri, Mar 16, 2012 at 1:57 AM, Jan Kratochvil
jan.kratoch...@redhat.com wrote:
 And both machines pass rpm -Va just fine. So the binaries should, um,
 be the same.
 +
 It is a core from yesterday,

 There can be difference one of the machines has the files prelink-ed while the
 other one does not.  prelink runs nightly (/etc/cron.daily/prelink).  But it

Thanks!

Prelink is not involved -- I doublechecked. In OLPC builds, we
currently don't prelink due to http://dev.laptop.org/ticket/10898 , we
just don't install prelink and don't run it during OS image creation.
Even back then when we did, we disabled the cronjob :-)

 should be already fixed in your GDB version gdb-7.2-52.fc14,

You got that one right :-)

 If it helps please contact me off-list, with your disk image.  It assumes the
 system generating the core file was not prelinked.

Uploading at
http://dev.laptop.org/~martin/os5rw-brokenimg/Sandisk_1200908562DEN.img

Bear in mind - that'll contain 2 partitions. The 2nd partition is /
but our initrd mounts it, and then chroots into a subdirectory. So
when you mount it, you'll want too look into /versions/run/5/

(WTF is this? Root FS snapshots via hardlinked trees. Until we have
btrfs running on these puppies, it's the best update fail-proof
mechanism we have.)

 That missing file:
 Missing separate debuginfo for
 Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install 
 /usr/lib/debug/.build-id/63/420e48a2edbae61166c708ebd2ff1a5aed1054

 is probably for kernel vDSO (as its name is empty), therefore kernel rpm.

Argh, that could be. But our kernel is a custom built rpm, and we
don't build -debuginfo. Here, have a fistful of my freshly-torn-out
hair.

Now, at the time of this segfault, the dmesg reports a segfault in
python2.7, inside calls to glib... (1) why are we then in the kernel
and (2) why isn't gdb telling us anything about the python/glib part
of the callstack?

still confused -



martin
PS: On a different investigation track we think there may be some
subtle/odd disk corruption that _passes_ rpm -Va and our own
olpc-contents-verify, yet strikes at runtime. Could a subtly corrupt
binary (ie: vmlinuz) lead here?
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?

[Martin Langhoff]

Hi Fedorans,

we are facing a very strange Python segfault in an OLPC build, based
on F14, for XO-1.5 (I know, do you remember _that_ far ago?).

The state of the OS and disk is well known, but we cannot make it
happen at will. So I got my hands on a coredump, installed the exact
same OS (so exact matching disk state as the machine that segfaults,
same rpms, etc), and went for
http://fedoraproject.org/wiki/StackTraces#Obtaining_a_stack_trace_from_a_core_dump

I've yum-installed the matching -debuginfo packages for python, glibc
and glib (apparently the segfault is calling glib).

Running gdb over the core, it complains: the .dynamic section for
/usr/lib/python2.7 is not at the expected address, and suggests a
yum install (of /usr/lib/debug/.build-id/identifier) that fails.

Full error msg from gdb at http://fpaste.org/YqGv/

I can see that some packages have invalid debuginfo subpackages
(http://fedoraproject.org/wiki/Packaging:Debuginfo#Useless_or_incomplete_debuginfo_packages_due_to_packaging_issues)
, but given Python's importance to the Fedora stack, my bet is that
Python's debuginfo is fine, and there's a subtle user error in the
middle...

To be clear -- we don't suspect Python or the Fedora stack. But
something is rotten, and this segfault is the only clue we have.

This problem is fairly important for the OLPC team at this time, help
on this track appreciated.



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?

[Jan Kratochvil]

On Thu, 15 Mar 2012 21:18:16 +0100, Martin Langhoff wrote:
 we are facing a very strange Python segfault in an OLPC build, based
 on F14, for XO-1.5 (I know, do you remember _that_ far ago?).
[...]
 Full error msg from gdb at http://fpaste.org/YqGv/

All those GDB messages mean your system libraries do not match the core file.

Is it a fresh core file from last hours? Is it generated on the same machine
you run GDB on?

F-14 is EOLed, its repositories incl. debuginfos are out of date, I do not
think it matters to spend any time on F-14 at all.


Regards,
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?

[Martin Langhoff]

On Thu, Mar 15, 2012 at 4:58 PM, Jan Kratochvil
jan.kratoch...@redhat.com wrote:
 All those GDB messages mean your system libraries do not match the core file.

Well, that should just not be. The machine that fails, and my machine
have both been installed from the same disk image, which gets written
to disk with a process equivalent to dd.

And both machines pass rpm -Va just fine. So the binaries should, um,
be the same.

 Is it a fresh core file from last hours? Is it generated on the same machine
 you run GDB on?

It is a core from yesterday, on a machine installed from a 'dd' disk
image. The machine that fails is exactly on the opposite side of the
world. dd'ing the same OS image on my machine doesn't trigger the
failure. So there is something funny on the opposite side of the
world.

 F-14 is EOLed, its repositories incl. debuginfos are out of date

Not in this case, at least yumrpm claim that the debuginfos match.

 think it matters to spend any time on F-14 at all.

As I stated in my earlier email, I don't want anyone to fix F14, I
don't think F14 is to blame.

My questions are simpler:

 - Is python 2.7 debuginfo in F14 known to be good or bad?

 - If it's known to be good, are there any gotchas not documented in
the StackTraces wikipage that could be tripping me up?

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?

[John Reiser]

On 03/15/2012 01:58 PM, Jan Kratochvil wrote:
 On Thu, 15 Mar 2012 21:18:16 +0100, Martin Langhoff wrote:
 we are facing a very strange Python segfault in an OLPC build, based
 on F14, for XO-1.5 (I know, do you remember _that_ far ago?).
 [...]
 Full error msg from gdb at http://fpaste.org/YqGv/
 
 All those GDB messages mean your system libraries do not match the core file.

 
 F-14 is EOLed, its repositories incl. debuginfos are out of date, I do not
 think it matters to spend any time on F-14 at all.

Yes, F-14 is now 1.4 years old, but the situation should not be that bleak.
In particular, the mirrors should contain _matching_ packages and debuginfo,
and the ordinary install command for a particular debuginfo should succeed.
If not, then perhaps a by-hand search for the matching debuginfo will succeed.
Check the build-id by hand, too.  Search the net for any filename which
contains that string.  Look at several mirrors of F-14 for your CPU 
architecture.

If manual search fails, then get the source, rebuild the offending package
and its debuginfo, install them, re-create the crash, and analyze the new dumps.

-- 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?

[Martin Langhoff]

Hi John,

thanks for the reply - looping back devel@lfo and devel@llo...

On Thu, Mar 15, 2012 at 5:14 PM, John Gilmore g...@toad.com wrote:
 Irreproducible bugs are a real pain.

Indeed --

 Try typing info files to gdb and see what sections it sees in the
 core file and in the executable.

I can't make much sense of the output :-/ http://fpaste.org/R457/

 Also, you can run objdump -x on the core file, and on the Python
 library, and compare them to see how well the section listings match
 up.  If the various segments are differently sized, then you clearly
 have the wrong debug symbols.

 I also suggest cross-posting to the bug-gdb list, where you'll
 find the GDB developers who know how the separate-debug-symbol stuff
 works.  You might want to make that core file publicly accessible
 in case any other developers want to go digging in it.

I'll hunt those tracks tmw -- you can see the core file, logs from
failing units and more bg info at http://dev.laptop.org/ticket/11698

 Any local Fedora build wizards may know how to find a -debuginfo
 package via its build-id.

Well, yum should find it ;-) -- but the mystifying thing is yum/rpm
seem to have found the right debuginfo file. gdb disagrees. Who's
right?

 You could also try recompiling python2.7 from its package source, with
 debug symbols, ON the machine where you're debugging.  The catch...

Even if it was reproduceable... I can't make _my_ machine barf.
Faraway machines are barfing left and right in mysterious ways, and we
are trying to get remote access, etc.

But even if I get the remote access, I want to run the currently
failing python under gdb, and again we're going to be with mismatched
debuginfos.

 You may have to debug this without symbols.  It looks from your log
 like the program counter and/or stack is off in the weeds.  Did you
 try bt to see if any of the stack is accessible?

it doesn't look very useful

Core was generated by `python /usr/bin/sugar-session'.
Program terminated with signal 11, Segmentation fault.
#0  0xa7183e2e in ?? ()
(gdb) bt
#0  0xa7183e2e in ?? ()
#1  0x08f352d0 in ?? ()
#2  0xa6f0ae57 in ?? ()
#3  0x08cea354 in ?? ()
#4  0xa7771878 in ?? ()
#5  0x in ?? ()


 /usr/lib/python2.7 is not at the expected address, and suggests a

 btw, you mistyped there; the message is about /usr/bin/python2.7,
 not /usr/lib/python2.7 (which is a directory).

Sorry, you're right. The fpaste url has the actual output at
http://fpaste.org/YqGv/


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?

[Jan Kratochvil]

On Thu, 15 Mar 2012 22:31:58 +0100, Martin Langhoff wrote:
 Well, that should just not be. The machine that fails, and my machine
 have both been installed from the same disk image, which gets written
 to disk with a process equivalent to dd.
 
 And both machines pass rpm -Va just fine. So the binaries should, um,
 be the same.
+
 It is a core from yesterday,

There can be difference one of the machines has the files prelink-ed while the
other one does not.  prelink runs nightly (/etc/cron.daily/prelink).  But it
should be already fixed in your GDB version gdb-7.2-52.fc14, it was fixed in
gdb-7.2-45.fc14 by:
[patch] [i386] Fix {,un}prelinked libraries for attach/core-load
http://sourceware.org/ml/gdb-patches/2011-02/msg00630.html
Still I may have missed some case.

If one of the binaries is prelinked and one was not (or vice verse) the
message is not at the expected address (wrong library or version mismatch?)
is really printed (more in the mail above) but the backtrace should work OK.

You can try for the experiment:
/etc/sysconfig/prelink:
# Set this to no to disable prelinking altogether
# (if you change this from yes to no prelink -ua
# will be run next night to undo prelinking)
PRELINKING=no
   ^^
If it helps please contact me off-list, with your disk image.  It assumes the
system generating the core file was not prelinked.


That missing file:
Missing separate debuginfo for
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install 
/usr/lib/debug/.build-id/63/420e48a2edbae61166c708ebd2ff1a5aed1054

is probably for kernel vDSO (as its name is empty), therefore kernel rpm.  One
never knows what the build-id matches to until Darkserver gets deployed,
hopefully for F-17:
https://fedoraproject.org/wiki/Darkserver


Thanks,
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel