You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(8) |
2
(10) |
|
3
|
4
|
5
(7) |
6
(12) |
7
(8) |
8
(3) |
9
|
|
10
|
11
(7) |
12
|
13
(2) |
14
(2) |
15
(10) |
16
(4) |
|
17
|
18
(14) |
19
(11) |
20
(12) |
21
(4) |
22
(2) |
23
(3) |
|
24
|
25
|
26
|
27
(8) |
28
(7) |
29
(3) |
30
(1) |
|
From: Tim M. <ti...@se...> - 2005-04-15 09:19:12
|
Jeremy Fitzhardinge said: > Tim Martin wrote: >>It happens with memcheck, addrcheck and tool=none. It happened with >>valgrind 2.2.0, which is why I tried upgrading to 2.4. >> > What happened with 2.2.0? It didn't print that particular message > because it is new with 2.4. It appears that the same thing happens with a different message - certainly the process dies with a segfault. [timm@timm uas]$ valgrind --tool=none ./test ==24996== Nulgrind, a binary JIT-compiler for x86-linux. ==24996== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote. ==24996== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==24996== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==24996== For more details, rerun with: -v ==24996== ==24996== ==24996== Process terminating with default action of signal 11 (SIGSEGV) ==24996== at 0x80483F1: main (in /home/timm/build/linux/products/servers/uas/test) ==24996== Segmentation fault > I think the problem is exactly as the message says: > > ==13765== This may be because one of your programs has consumed your > ==13765== ration of siginfo structures. > > The last time this problem was reported, it was with SuSE 9.2; in > particular, something in KDE has a lot of signals sent to it, but it > blocks them so they are never delivered and so remain pending forever. > This eats up your per-user limit of pending signals, so Valgrind's use > of signals is twarted. The thing that initially led me to discount that message was that it happened with such a trivial test program, which isn't doing any special signal handling at all. By the results of the tests below, I guess I was wrong. > This can be confirmed in several ways: > > 1. try running your test program under Valgrind as another user, or > root Running as root, it works fine on 2.2.0 and 2.4.0. > 2. try running it just after logging in > 3. run the test program "none/tests/faultstatus" natively (not under > Valgrind); if it reports failures, there's a basic problem with > signal delivery This reports Test 1: FAIL: expected si_code==1, not 0 Test 2: FAIL: expected si_code==2, not 0 Test 3: FAIL: expected si_code==2, not 0 Test 4: FAIL: expected si_code==1, not 0 Test 5: FAIL: expected si_code==2, not 0 Test 6: FAIL: expected si_code==128, not 0 Test 7: FAIL: expected si_code==128, not 0 Test 8: FAIL: expected si_code==128, not 0 Test 9: FAIL: expected si_code==128, not 0 which I guess counts as a problem. :-) > 4. run "grep '^...Pnd:' /proc/*/status|grep -v 0000000000000000" and > see what comes up This returns /proc/3084/status:SigPnd: 0000010000000000 /proc/3165/status:SigPnd: 0000010000000000 /proc/8256/status:SigPnd: 0000010000000000 /proc/8258/status:SigPnd: 0000010000000000 > Newer versions of 2.6 kernels don't have this problem and make it easier > to diagnose pending signal exhaustion. Unfortunately this problem is > outside of Valgrind's scope, and there isn't any way to make Valgrind > avoid this case (the best we can do is report when it happens, rather > than silently dying or going into an infinite loop as it used to). Is this a genuine bug in the kernel then? If so, I'll either upgrade or live with it. Thanks for your help. Tim |
|
From: Christian P. <tr...@ge...> - 2005-04-15 06:04:04
|
Hi all, I'm just getting this error when running valgrind on my fresh app. error while loading shared libraries: libgcrypt.so.11: cannot enable=20 executable stack as shared object requires: Invalid argument I know I once ran in as well, but can't remember how I fixed it. So, how do I fix this / work around this? Regards, Christian Parpart. =2D-=20 Netiquette: http://www.ietf.org/rfc/rfc1855.txt 08:02:34 up 22 days, 21:08, 0 users, load average: 0.03, 0.04, 0.00 |
|
From: Dhinakar K <k.d...@sa...> - 2005-04-15 00:56:39
|
Hi, There is a requirement in our company, to use a tool for checking the memory leak, corruption, allocation errors etc. on an embedded linux system on chip for C++ programs. The system details are given below:- 1.ATI Xilleon 226B processor 2.OS -> Linux Kernel 2.4.6 3.C++ compiler -> GCC 2.9 I would like to know if Valgrind could be used to test the target systems such as the above. Thanks & Regards, Dhinakar |
|
From: Nicholas N. <nj...@cs...> - 2005-04-14 18:53:18
|
On Thu, 14 Apr 2005, Mike Grass wrote: > I have a program that uses the smsw instruction (for the curious, I want to > test if FXSAVE is emulated by the processor). Valgrind quits with the following > message when it hits this instruction: > > "disInstr: unhandled instruction bytes: 0x66 0xF 0x1 0xE0". > > Those instruction bytes are equivalent to "smsw ax" in assembly. What does 'smsw' do? Is it like 'fstsw ax' ? Can you provide the assembly sequence that this is part of? Thanks. N |
|
From: Mike G. <mi...@ac...> - 2005-04-14 18:14:55
|
Hi, I have a program that uses the smsw instruction (for the curious, I want to test if FXSAVE is emulated by the processor). Valgrind quits with the following message when it hits this instruction: "disInstr: unhandled instruction bytes: 0x66 0xF 0x1 0xE0". Those instruction bytes are equivalent to "smsw ax" in assembly. Cheers, --Mike |
|
From: Jeremy F. <je...@go...> - 2005-04-13 22:14:35
|
Tim Martin wrote:
>==13765== Signal 11 (SIGSEGV) appears to have lost its siginfo; I can't go
>on.
>==13765== This may be because one of your programs has consumed your
>==13765== ration of siginfo structures.
>==13765==
>Segmentation fault
>[timm@timm uas]$
>
>It happens with memcheck, addrcheck and tool=none. It happened with
>valgrind 2.2.0, which is why I tried upgrading to 2.4.
>
>
What happened with 2.2.0? It didn't print that particular message
because it is new with 2.4.
>If I reduce the size of the stack array to 3000 it seems to work.
>
>
The problem seems to be with the SIGSEGV Valgrind needs to grow the
stack. If the stack is small enough, then it doesn't need to be grown.
I think the problem is exactly as the message says:
==13765== This may be because one of your programs has consumed your
==13765== ration of siginfo structures.
The last time this problem was reported, it was with SuSE 9.2; in
particular, something in KDE has a lot of signals sent to it, but it
blocks them so they are never delivered and so remain pending forever.
This eats up your per-user limit of pending signals, so Valgrind's use
of signals is twarted.
This can be confirmed in several ways:
1. try running your test program under Valgrind as another user, or root
2. try running it just after logging in
3. run the test program "none/tests/faultstatus" natively (not under
Valgrind); if it reports failures, there's a basic problem with
signal delivery
4. run "grep '^...Pnd:' /proc/*/status|grep -v 0000000000000000" and
see what comes up
Newer versions of 2.6 kernels don't have this problem and make it easier
to diagnose pending signal exhaustion. Unfortunately this problem is
outside of Valgrind's scope, and there isn't any way to make Valgrind
avoid this case (the best we can do is report when it happens, rather
than silently dying or going into an infinite loop as it used to).
J
|
|
From: Steven B. <ba...@ep...> - 2005-04-13 21:27:57
|
My program is crashing and using valgrind I get the following errors. There is no code at line 1758 of makeped.c so can you tell me how to figure out which variable isn't initialized? I'm on red hat linux using the latest valgrind and gcc. Thanks, Steve =948== Use of uninitialised value of size 4 ==948== at 0x804B67E: main (makeped.c:1758) trc=31 jump to 0xB00673BA from 0x804B67A ==948== ==948== Jump to the invalid address stated on the next line ==948== at 0xB00673BA: vgSkinInternal_free (vg_toolint.c:538) ==948== Address 0xB00673BA is not stack'd, malloc'd or (recently) free'd ==948== ==948== Invalid read of size 4 ==948== at 0xB00673CD: vgSkinInternal_free (vg_toolint.c:539) ==948== by 0x1BA5A1B7: ??? ==948== Address 0xB009E3E4 is not stack'd, malloc'd or (recently) free'd ==948== Process terminating with default action of signal 11 (SIGSEGV) ==948== GPF (Pointer out of bounds?) ==948== at 0xB00673CD: vgSkinInternal_free (vg_toolint.c:539) ==948== by 0x1BA5A1B7: ??? trc=0 jump to 0xB00673CD from 0xB00673BA |
|
From: Christian P. <tr...@ge...> - 2005-04-11 23:45:32
|
On Monday 11 April 2005 6:36 pm, Tim Martin wrote: > Hi all, > > I've just come across a curious segfault when using valgrind, which > doesn't happen without it. It appears to be caused by declaring an array > on the stack. [....] I cannot confirm this. My test environment was x86 chroot environment withi= ng=20 true amd64 on Gentoo Linux testing branch. hmm.... maybe your valgrind install fsck'd up? Christian. =2D-=20 Netiquette: http://www.ietf.org/rfc/rfc1855.txt 01:27:26 up 19 days, 14:33, 6 users, load average: 0.15, 0.23, 0.27 |
|
From: Jeremy F. <je...@go...> - 2005-04-11 21:53:13
|
Qin Zhao wrote:
>It can load the stage2 source code, but still cannot map eip to the source code
>
It's easier if you configure with --disable-pie.
J
|
|
From: Tim M. <ti...@se...> - 2005-04-11 16:36:27
|
Hi all,
I've just come across a curious segfault when using valgrind, which
doesn't happen without it. It appears to be caused by declaring an array
on the stack.
I have the following small test file:
---test.c---
#include <stdio.h>
int main(void)
{
char szVar[4000] = {0};
printf("Hello world!\n");
return 0;
}
---End test.c---
Compiling it with gcc:
[timm@timm uas]$ gcc test.c -o test
[timm@timm uas]$ valgrind --tool=none ./test
==13765== Nulgrind, a binary JIT-compiler for x86-linux.
==13765== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote.
==13765== Using valgrind-2.4.0, a program supervision framework for
x86-linux.
==13765== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==13765== For more details, rerun with: -v
==13765==
==13765== Signal 11 (SIGSEGV) appears to have lost its siginfo; I can't go
on.
==13765== This may be because one of your programs has consumed your
==13765== ration of siginfo structures.
==13765==
Segmentation fault
[timm@timm uas]$
It happens with memcheck, addrcheck and tool=none. It happened with
valgrind 2.2.0, which is why I tried upgrading to 2.4.
If I reduce the size of the stack array to 3000 it seems to work.
I'm slightly suspicious that this is a gcc problem, since the same process
works on another box with a different gcc. My gcc is
[timm@timm .autotest.uas]$ gcc --version
gcc (GCC) 3.3.4 (pre 3.3.5 20040809)
(standard gcc with SuSE 9.2)
Tim
|
|
From: Qin Z.
|
It can load the stage2 source code, but still cannot map eip to the source code Quoting Tom Hughes <to...@co...>: > In message <111...@we...> > Qin Zhao <zhaoqin@MIT.EDU> wrote: > > > I am interested in how valgrind 2.4.0 starts up using it is own loader. > > I can trace its execution in the stage1, but in stage2, the source code is > not > > linked to gdb, might because stage2 is loaded by stage1, and GDB does not > know > > how to link the binary code to the source code. Can anyone tell me how to > link > > the source code to the executed program? > > The README_DEVELOPERS file explains how to debug stage2. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Nicholas N. <nj...@cs...> - 2005-04-11 15:46:21
|
On Mon, 11 Apr 2005, Qin Zhao wrote: > I am interested in how valgrind 2.4.0 starts up using it is own loader. > I can trace its execution in the stage1, but in stage2, the source code is not > linked to gdb, might because stage2 is loaded by stage1, and GDB does not know > how to link the binary code to the source code. Can anyone tell me how to link > the source code to the executed program? Section 2.3.4 of http://www.valgrind.org/docs/phd2004.pdf has a brief explanation which might be useful. N |
|
From: Tom H. <to...@co...> - 2005-04-11 15:40:48
|
In message <111...@we...>
Qin Zhao <zhaoqin@MIT.EDU> wrote:
> I am interested in how valgrind 2.4.0 starts up using it is own loader.
> I can trace its execution in the stage1, but in stage2, the source code is not
> linked to gdb, might because stage2 is loaded by stage1, and GDB does not know
> how to link the binary code to the source code. Can anyone tell me how to link
> the source code to the executed program?
The README_DEVELOPERS file explains how to debug stage2.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Qin Z.
|
Hi: I am interested in how valgrind 2.4.0 starts up using it is own loader. I can trace its execution in the stage1, but in stage2, the source code is not linked to gdb, might because stage2 is loaded by stage1, and GDB does not know how to link the binary code to the source code. Can anyone tell me how to link the source code to the executed program? Best Regards Qin |
|
From: Tom H. <to...@co...> - 2005-04-08 15:29:10
|
In message <625...@sn...>
mfy...@sn... wrote:
> When calling "times(NULL)", valgrind (2.4.22) reports:
There is no valgrind 2.4.22... I assume that is actually the
version of your kernel?
> ==798== Syscall param times(buf) points to unaddressable byte(s)
> ==798== at 0x1BB5439D: times (in /lib/libc-2.3.2.so)
> ...
> ==798== Address 0x0 is not stack'd, malloc'd or (recently) free'd
>
> I'm using times under linux, and it appears to be valid to pass it
> NULL, if you are only interested in the return code (the clock ticks
> since boot), not the updates stored in the parameter. However, on
> other unix OS's (Solaris, for example), I understand this is unsafe --
> you need to always pass in a pointer to a dummy "struct tms", even if
> you never set it or look at the contents.
You would appear to be correct - the linux manual page doesn't
actually mention allowing null but it doesn't list EFAULT as an
error either which Solaris does.
> I could just change our call to times to pass in a dummy struct, but
> I'm not sure that's really the right thing to do. I suspect that if
> you pass in NULL, times will optimize out collecting all the unneeded
> information. Should valgrind really complain about this?
The kernel does indeed optimise by skipping about two dozen lines
of code and just doing the last line ;-)
Please raise a bug for this on the bug tracker.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: snelling <mfy...@sn...> - 2005-04-08 15:15:23
|
When calling "times(NULL)", valgrind (2.4.22) reports: ==798== Syscall param times(buf) points to unaddressable byte(s) ==798== at 0x1BB5439D: times (in /lib/libc-2.3.2.so) ... ==798== Address 0x0 is not stack'd, malloc'd or (recently) free'd I'm using times under linux, and it appears to be valid to pass it NULL, if you are only interested in the return code (the clock ticks since boot), not the updates stored in the parameter. However, on other unix OS's (Solaris, for example), I understand this is unsafe -- you need to always pass in a pointer to a dummy "struct tms", even if you never set it or look at the contents. (It's difficult to do a web search for "times", because it's such a common word. I'm talking about TIMES(2), from "#include <sys/times.h>", with the signature "clock_t times(struct tms *buf);") I could just change our call to times to pass in a dummy struct, but I'm not sure that's really the right thing to do. I suspect that if you pass in NULL, times will optimize out collecting all the unneeded information. Should valgrind really complain about this? -- Peter Snelling |
|
From: <jp...@mu...> - 2005-04-08 01:33:39
|
It seems to work on plain executables, but not on dynamic libraries. I'm not really sure how it would. Is this the expected behavior? -- Jason Weber On Thu, April 7, 2005 12:32 pm, Crispin Flowerday said: > On Thu, 2005-04-07 at 10:17 -0700, jp...@mu... wrote: >> Is there a way to get the full file/line info without valgrind running? >> >> I added the gnu backtrace functions to my exception, assert, and >> segv, but it's only of limited utility with just function names. > > You should be able to get the file and line number using the 'addr2line' > program (in binutils). > > Crispin > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Crispin F. <val...@fl...> - 2005-04-07 19:30:24
|
On Thu, 2005-04-07 at 10:17 -0700, jp...@mu... wrote: > Is there a way to get the full file/line info without valgrind running? > > I added the gnu backtrace functions to my exception, assert, and > segv, but it's only of limited utility with just function names. You should be able to get the file and line number using the 'addr2line' program (in binutils). Crispin |
|
From: Avery P. <ape...@ni...> - 2005-04-07 18:09:07
|
On Thu, Apr 07, 2005 at 10:17:07AM -0700, jp...@mu... wrote: > Is there a way to get the full file/line info without valgrind running? > > I added the gnu backtrace functions to my exception, assert, and > segv, but it's only of limited utility with just function names. We have a gdb script that does a file/line lookup of the gnu backtrace output: http://open.nit.ca/wiki/?AnonymousCvs The file you want from CVS is wvstreams/utils/wvcrashread.sh. Have fun, Avery |
|
From: Robert W. <rj...@du...> - 2005-04-07 17:32:23
|
> Is there a way to get the full file/line info without valgrind running? Yes, assuming you're using DWARF. Look at libdwarf - you can use the code in there to do a reverse map from symbol+offset to file+line. It's not super trivial to do, but it is doable: http://reality.sgi.com/davea Another similar package is the DWARF library that comes with elfutils. It's called libdw, and the advantages over libdwarf is that it comes with Fedora (and probably earlier releases) and already has a function to do this. The disadvantage with this is that I can't find a web page or documentation, so the only way I could learn how to use it was to download the spec file, extract the sources and read through the test cases it came with. libdw is OSL'd, if I remember correctly. libdwarf is LGPL'd. If you're using COFF or stabs, you're on your own - I don't know anything that can help you there. Regards, Robert. |
|
From: <jp...@mu...> - 2005-04-07 17:18:28
|
Is there a way to get the full file/line info without valgrind running? I added the gnu backtrace functions to my exception, assert, and segv, but it's only of limited utility with just function names. -- Jason Weber On Wed, April 6, 2005 11:12 am, Robert Walsh said: > As well as the glibc stuff, there's also VALGRIND_PRINTF_BACKTRACE, > which only gets invoked when you're running under Valgrind and converts > backtrace information to source file/line number information, if it can. > > Regards, > Robert. > > -- > Robert Walsh > Amalgamated Durables, Inc. - "We don't make the things you buy." > Email: rj...@du... > |
|
From: Tom H. <to...@co...> - 2005-04-07 16:35:07
|
In message <200...@ma...>
erg...@pc... wrote:
>> In message <200...@ma...>
>> erg...@pc... wrote:
>>
>> > disInstr: unhandled instruction bytes: 0xF4 0xB8 0x7 0x0
>> > at 0x1BACAEC1: abort (in /lib/i686/libc.so.6)
>>
>> Umm.. That's a HLT instruction, which seems a bit odd...
>>
>> I assume abort is using it because it non-privileged mode it will
>> normally raise a fault and cause the program to terminate. As I recall
>> that is glibc's last resort way of stopping the program if everything
>> else fails.
>>
>> Not hugely interesting anyway if it only happens when your program
>> asserts.
>
> So you're saying that my program raised the assert (from down inside the
> glibc localtime function)?
Well that's what it says...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <erg...@pc...> - 2005-04-07 16:23:26
|
> In message <200...@ma...> > erg...@pc... wrote: > > > I'm a bit confused as to whether this error is mine or Valgrinds?? > > If it's Valgrinds, then this serves as a bug report, although it may not be > > of interest on 2.2 (cluster nodes haven't been upgraded yet). > > Thanks > > Eric > > > > (FWIW - GCC 3.3.1, SuSe kernel 2.4.21-273-smp) > > > > ==17160== Memcheck, a memory error detector for x86-linux. > > ==17160== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. > > ==17160== Using valgrind-2.2.0, a program supervision framework for x86-linux. > > ==17160== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. > > ==17160== > > ==17160== My PID = 17160, parent PID = 17158. Prog and args are: > > ==17160== /home/erg25994/CSieve_PVM_S/sieve_pvm > > ==17160== For more details, rerun with: -v > > > > <snipped some uninteresting library errors> > > > > disInstr: unhandled instruction bytes: 0xF4 0xB8 0x7 0x0 > > at 0x1BACAEC1: abort (in /lib/i686/libc.so.6) > > Umm.. That's a HLT instruction, which seems a bit odd... > > I assume abort is using it because it non-privileged mode it will > normally raise a fault and cause the program to terminate. As I recall > that is glibc's last resort way of stopping the program if everything > else fails. > > Not hugely interesting anyway if it only happens when your program > asserts. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > So you're saying that my program raised the assert (from down inside the glibc localtime function)? Thanks Eric --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/ |
|
From: Tom H. <to...@co...> - 2005-04-07 16:15:06
|
In message <200...@ma...>
erg...@pc... wrote:
> I'm a bit confused as to whether this error is mine or Valgrinds??
> If it's Valgrinds, then this serves as a bug report, although it may not be
> of interest on 2.2 (cluster nodes haven't been upgraded yet).
> Thanks
> Eric
>
> (FWIW - GCC 3.3.1, SuSe kernel 2.4.21-273-smp)
>
> ==17160== Memcheck, a memory error detector for x86-linux.
> ==17160== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
> ==17160== Using valgrind-2.2.0, a program supervision framework for x86-linux.
> ==17160== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
> ==17160==
> ==17160== My PID = 17160, parent PID = 17158. Prog and args are:
> ==17160== /home/erg25994/CSieve_PVM_S/sieve_pvm
> ==17160== For more details, rerun with: -v
>
> <snipped some uninteresting library errors>
>
> disInstr: unhandled instruction bytes: 0xF4 0xB8 0x7 0x0
> at 0x1BACAEC1: abort (in /lib/i686/libc.so.6)
Umm.. That's a HLT instruction, which seems a bit odd...
I assume abort is using it because it non-privileged mode it will
normally raise a fault and cause the program to terminate. As I recall
that is glibc's last resort way of stopping the program if everything
else fails.
Not hugely interesting anyway if it only happens when your program
asserts.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <erg...@pc...> - 2005-04-07 15:50:04
|
I'm a bit confused as to whether this error is mine or Valgrinds??
If it's Valgrinds, then this serves as a bug report, although it may not be
of interest on 2.2 (cluster nodes haven't been upgraded yet).
Thanks
Eric
(FWIW - GCC 3.3.1, SuSe kernel 2.4.21-273-smp)
==17160== Memcheck, a memory error detector for x86-linux.
==17160== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==17160== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==17160== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==17160==
==17160== My PID = 17160, parent PID = 17158. Prog and args are:
==17160== /home/erg25994/CSieve_PVM_S/sieve_pvm
==17160== For more details, rerun with: -v
<snipped some uninteresting library errors>
disInstr: unhandled instruction bytes: 0xF4 0xB8 0x7 0x0
at 0x1BACAEC1: abort (in /lib/i686/libc.so.6)
==17160==
==17160== Process terminating with default action of signal 4 (SIGILL):
dumping core
==17160== Illegal operand at address 0xB00225E0
==17160== at 0x1BACAEC1: abort (in /lib/i686/libc.so.6)
==17160== by 0x1BAC2E83: __GI___assert_fail (in /lib/i686/libc.so.6)
==17160== by 0x1BB37FC9: __tzfile_compute (in /lib/i686/libc.so.6)
==17160== by 0x1BB37136: __tz_convert (in /lib/i686/libc.so.6)
==17160== by 0x1BB3569E: localtime (in /lib/i686/libc.so.6)
==17160== by 0x804E633: JulianDate::init() (jdate.h:192)
==17160== by 0x804DD88: JulianDate::JulianDate() (jdate.h:201)
==17160== by 0x806D299: SGP4_Sat::SGP4_Sat(SGP4_Sat const&) (sgp4_cc.h:66)
==17160== by 0x806D4E3: CatObject::orbit() const (cat_object.h:127)
==17160== by 0x806A820: find_close_approach(CatObject const*, CatObject
const*, double, ConjunctObj&, bool) (sieve.cc:370)
==17160== by 0x806A145: finish(void*) (sieve.cc:249)
==17160== by 0x80542FA: thread_pool_loop(void*) (pool.cc:27)
==17160== by 0x1B90EA90: thread_wrapper (vg_libpthread.c:867)
==17160== by 0xB000EFED: do__quit (vg_scheduler.c:1872)
valgrind: vg_memory.c:839 (vgPlain_init_shadow_range): Assertion
`vgPlain_defined_init_shadow_page()' failed.
==17160== at 0xB002B6BA: vgPlain_skin_assert_fail (vg_mylibc.c:1137)
==17160== by 0xB002B6B9: assert_fail (vg_mylibc.c:1133)
==17160== by 0xB002B6F7: vgPlain_core_assert_fail (vg_mylibc.c:1144)
==17160== by 0xB0029A11: vgPlain_init_shadow_range (vg_memory.c:839)
==17160== by 0xB003194C: vg_sync_signalhandler (vg_signals.c:2133)
==17160== by 0xB0045C45: (within
/home/erg25994/usr/local/lib/valgrind/stage2)
sched status:
Thread 1: status = WaitCV, associated_mx = 0x80C6998, associated_cv = 0x80C69E0
==17160== at 0x1B90FF96: pthread_cond_wait (vg_libpthread.c:1454)
==17160== by 0x805185B: ThreadPool::wait_for_work_finish() (pool.h:139)
==17160== by 0x805032D: slave() (slave.cc:296)
==17160== by 0x804BA9D: main (main2.cc:59)
Thread 2: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==17160== at 0x1BACAEC1: abort (in /lib/i686/libc.so.6)
==17160== by 0x1BAC2E83: __GI___assert_fail (in /lib/i686/libc.so.6)
==17160== by 0x1BB37FC9: __tzfile_compute (in /lib/i686/libc.so.6)
==17160== by 0x1BB37136: __tz_convert (in /lib/i686/libc.so.6)
==17160== by 0x1BB3569E: localtime (in /lib/i686/libc.so.6)
==17160== by 0x804E633: JulianDate::init() (jdate.h:192)
==17160== by 0x804DD88: JulianDate::JulianDate() (jdate.h:201)
==17160== by 0x806D299: SGP4_Sat::SGP4_Sat(SGP4_Sat const&) (sgp4_cc.h:66)
==17160== by 0x806D4E3: CatObject::orbit() const (cat_object.h:127)
==17160== by 0x806A820: find_close_approach(CatObject const*, CatObject
const*, double, ConjunctObj&, bool) (sieve.cc:370)
==17160== by 0x806A145: finish(void*) (sieve.cc:249)
==17160== by 0x80542FA: thread_pool_loop(void*) (pool.cc:27)
==17160== by 0x1B90EA90: thread_wrapper (vg_libpthread.c:867)
==17160== by 0xB000EFED: do__quit (vg_scheduler.c:1872)
Thread 3: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==17160== at 0x8081293: transpose(Array const&) (Array.cc:830)
==17160== by 0x8070BDF: CovgenCov::eci_covariance(JulianDate const&,
JulianDate const&, Vector const&, Vector const&) const (covgen.h:220)
==17160== by 0x806FE56: CovgenCov::eci_covariance(JulianDate const&,
JulianDate const&, Vector const&) const (covgen.h:231)
==17160== by 0x806F2D1: SGP4_Sat::covariance() (sgp4_cc.h:202)
==17160== by 0x806D710: ConjunctObj::init(unsigned, unsigned, SGP4_Sat&,
unsigned, unsigned, SGP4_Sat&) (conj_object.h:118)
==17160== by 0x806B37E: find_close_approach(CatObject const*, CatObject
const*, double, ConjunctObj&, bool) (sieve.cc:426)
==17160== by 0x806A145: finish(void*) (sieve.cc:249)
==17160== by 0x80542FA: thread_pool_loop(void*) (pool.cc:27)
==17160== by 0x1B90EA90: thread_wrapper (vg_libpthread.c:867)
==17160== by 0xB000EFED: do__quit (vg_scheduler.c:1872)
Thread 4: status = WaitCV, associated_mx = 0x80C6998, associated_cv = 0x80C69B0
==17160== at 0x1B90FF96: pthread_cond_wait (vg_libpthread.c:1454)
==17160== by 0x80544FD: ThreadPool::get_work() (pool.h:101)
==17160== by 0x80542DC: thread_pool_loop(void*) (pool.cc:23)
==17160== by 0x1B90EA90: thread_wrapper (vg_libpthread.c:867)
==17160== by 0xB000EFED: do__quit (vg_scheduler.c:1872)
Thread 5: status = WaitCV, associated_mx = 0x80C68C8, associated_cv = 0x80BA020
==17160== at 0x1B90FF96: pthread_cond_wait (vg_libpthread.c:1454)
==17160== by 0x806C391: send_conjunct(void*) (sieve.cc:592)
==17160== by 0x1B90EA90: thread_wrapper (vg_libpthread.c:867)
==17160== by 0xB000EFED: do__quit (vg_scheduler.c:1872)
Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.
If that doesn't help, please report this bug to: valgrind.kde.org
In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using. Thanks.
---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/
|