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
(1) |
3
(3) |
4
(3) |
|
5
(2) |
6
(7) |
7
(1) |
8
(9) |
9
(7) |
10
(9) |
11
(2) |
|
12
(5) |
13
(8) |
14
(19) |
15
(8) |
16
(25) |
17
(9) |
18
(6) |
|
19
(11) |
20
(2) |
21
(10) |
22
(13) |
23
(7) |
24
(6) |
25
(3) |
|
26
|
27
(2) |
28
(1) |
29
(4) |
30
(7) |
31
(5) |
|
|
From: <aho...@es...> - 2003-10-16 16:38:13
|
I get the following log and segfault when running glxgears (or any other GL program it seems) with valgrind. My machine config is: AMD XP 1900 Radeon 9000 RH 9 with DRI from cvs Any suggestions where to start? Is there a convenient way to run gdb on valgrind while still using the 'valgrind' wrapper script? cheers, aaron wilder:~$ valgrind -v glxgears ==10543== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==10543== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==10543== Using valgrind-20031012, a program supervision framework for x86-linux. ==10543== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==10543== Command line: ==10543== glxgears ==10543== Startup, with flags: ==10543== --suppressions=/home/aholtzma/lib/valgrind/default.supp ==10543== -v ==10543== Reading syms from /usr/X11R6/bin/glxgears ==10543== object doesn't have a symbol table ==10543== object doesn't have any debug info ==10543== Reading syms from /lib/ld-2.3.2.so ==10543== object doesn't have any debug info ==10543== Reading syms from /home/aholtzma/lib/valgrind/vgskin_memcheck.so ==10543== Reading syms from /home/aholtzma/lib/valgrind/valgrind.so ==10543== Reading syms from /usr/X11R6/lib/libGL.so.1.2 ==10543== Reading syms from /usr/X11R6/lib/libXext.so.6.4 ==10543== object doesn't have a symbol table ==10543== object doesn't have any debug info ==10543== Reading syms from /usr/X11R6/lib/libX11.so.6.2 ==10543== object doesn't have a symbol table ==10543== object doesn't have any debug info ==10543== Reading syms from /home/aholtzma/lib/valgrind/libpthread.so ==10543== Reading syms from /lib/libm-2.3.2.so ==10543== object doesn't have any debug info ==10543== Reading syms from /lib/libc-2.3.2.so ==10543== object doesn't have any debug info ==10543== Reading syms from /lib/libdl-2.3.2.so ==10543== object doesn't have any debug info ==10543== Reading suppressions file: /home/aholtzma/lib/valgrind/default.supp ==10543== Estimated CPU clock rate is 1601 MHz ==10543== REPLACING libc(__GI___errno_location) with libpthread(__errno_location) ==10543== REPLACING libc(__GI___h_errno_location) with libpthread(__h_errno_location) ==10543== REPLACING libc(__GI___res_state) with libpthread(__res_state) ==10543== ==10543== TRANSLATE: 0x403F4CF0 redirected to 0x40387DC8 ==10543== Reading syms from /usr/X11R6/lib/modules/dri/r200_dri.so ==10543== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) ==10543== at 0x404BAD24: __GI___ioctl (in /lib/libc-2.3.2.so) ==10543== by 0x417C6B65: r200CreateScreen (r200_screen.c:185) ==10543== by 0x417C6E93: r200InitDriver (r200_screen.c:301) ==10543== by 0x416B2AF8: __driUtilCreateScreen (dri_util.c:1201) ==10543== Address 0xBFFFED94 is on thread 1's stack ==10543== ==10543== Use of uninitialised value of size 4 ==10543== at 0x417A9D4A: sigfpe_handler (common_x86.c:118) ==10543== by 0x4017EF2F: ??? (vg_hashtable.c:213) ==10543== by 0x417A9F6B: _mesa_init_all_x86_transform_asm (common_x86.c:275) ==10543== by 0x4172D95A: _math_init (m_xform.c:218) ==10543== ==10543== Invalid read of size 2 ==10543== at 0x417A9D4A: sigfpe_handler (common_x86.c:118) ==10543== by 0x4017EF2F: ??? (vg_hashtable.c:213) ==10543== by 0x417A9F6B: _mesa_init_all_x86_transform_asm (common_x86.c:275) ==10543== by 0x4172D95A: _math_init (m_xform.c:218) ==10543== Address 0x6E is not stack'd, malloc'd or free'd Segmentation fault wilder:~$ |
|
From: Philippe E. <ph...@wa...> - 2003-10-16 16:38:09
|
Nicholas Nethercote wrote: > On Tue, 14 Oct 2003, Steve G wrote: > > >>Aside from 2.5/2.6...will any of the new skins be rolled in? > > > No, it's from the stable branch, no new features. > > >>I know several developers using crocus, but they are maintaining >>their own patch set just to use it with a current copy of >>valgrind. > > > I'm looking at distributing crocus as an independent skin, like Josef W's > Calltree. But I haven't worked out all the relevant automakery, etc. > > Massif might be rolled into the CVS HEAD sometime, though. Or I could > distribute that separately too. Not sure. > > >>Annelid seems stable, too. > > > Hmm, I don't think so; I know about all the duct tape and paper clips > that are holding it together :) I'm not yet convinced Annelid is actually > useful; if anyone has used it to find bugs, I'd like to hear from you. I don't get problem with Annelid except from the missing mremap. It'll be more usefull if you implement debug info to handle segment in .data and .bss. I think http://developer.kde.org/~sewardj/ "Interesting variants" should list the existing skin. Most of the existing can't be found through google. Annelid search don't find your skin in the first 50 hit (15,900), Annelid and debugger don't find it at all. regards, Philippe Elie |
|
From: Joe V. A. <van...@at...> - 2003-10-16 15:23:02
|
Derick Rethans wrote: > On Thu, 16 Oct 2003, Joe Van Andel wrote: > > >>Using RH 9.0 and gcc 3.2.2, valgrind exits with an assertion failure: > > > The latest version (released yesterday) fixed this for me. I rebuilt valgrind from CVS, today, 2003/10/16. Valgrind works under the 2.4.22 kernel, but fails under 2.4.20 (as shipped by Redhat). I'm not sure why a newer kernel allows valgrind to work, but at least I can continue debugging. -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel at ucar dot edu |
|
From: Dirk M. <dm...@gm...> - 2003-10-16 14:24:28
|
On Thursday 16 October 2003 15:07, Dirk Mueller wrote: > We know about the problem, but there is no fix yet. As we play some nasty > tricks with the stack, it is "okay" that gdb feels confused. It worked > before because gdb wasn't able to correctly disassemble the method in older > versions. Now it can, and we cannot trick it into unwinding the stack > correctly anymore. Another solution has to be found. Ok, it was easier than I thought, and I committed this patch, which makes it work for me. let me know if you experience problems. |
|
From: Tom H. <th...@cy...> - 2003-10-16 13:52:46
|
In message <3F8...@at...>
Joe Van Andel <van...@at...> wrote:
> Using RH 9.0 and gcc 3.2.2, valgrind exits with an assertion failure:
>
> valgrind -v --gdb-attach=yes merge_beam -v
> ==16807== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
> ==16807== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
> ==16807== Using valgrind-20031012, a program supervision framework for x86-linux.
[ snipped details ]
> valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector & 7) == 7' failed.
That's an attempt to access the GDT which won't work, but it's
happening because you're using RedHat 9 which has NPTL and you've
somehow managed to bypass the code in valgrind that tries to set
LD_ASSUME_KERNEL to force old style threading.
Set LD_ASSUME_KERNEL to 2.4.1 in your environment and it should
work fine.
You might also like to check what nptl_threading is set to at the
top of the valgrind shell script - it should be "yes" for RH9 which
would then force LD_ASSUME_KERNEL to be set.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Joe V. A. <van...@at...> - 2003-10-16 13:22:22
|
Using RH 9.0 and gcc 3.2.2, valgrind exits with an assertion failure: valgrind -v --gdb-attach=yes merge_beam -v ==16807== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==16807== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==16807== Using valgrind-20031012, a program supervision framework for x86-linux. ==16807== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==16807== Command line: ==16807== merge_beam ==16807== -v ==16807== Startup, with flags: ==16807== --suppressions=/opt/local_rh90/lib/valgrind/default.supp ==16807== -v ==16807== --gdb-attach=yes ==16807== Reading syms from /code/vanandel/raddx/spol/merge_beam/merge_beam ==16807== Reading syms from /lib/ld-2.3.2.so ==16807== object doesn't have any debug info ==16807== Reading syms from /net/opt_lnx/local_rh90/lib/valgrind/vgskin_memcheck.so ==16807== Reading syms from /net/opt_lnx/local_rh90/lib/valgrind/valgrind.so ==16807== Reading syms from /net/opt_lnx/ACE-5.3/ace/libACE.so.5.3.0 ==16807== Reading syms from /net/opt_lnx/local_rh90/lib/libdb_cxx-4.1.so ==16807== Reading syms from /net/opt_lnx/local_rh90/lib/libdb-4.1.so ==16807== Reading syms from /net/local_lnx/gcc/3.2.2-redhat8.0/lib/liblog4cpp.so.3.1.3 ==16807== Reading syms from /usr/lib/libstdc++.so.5.0.3 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /lib/tls/libm-2.3.2.so ==16807== object doesn't have any debug info ==16807== Reading syms from /net/local_lnx/gcc/3.2.2-redhat8.0/lib/libgcc_s.so.1 ==16807== Reading syms from /net/opt_lnx/local_rh90/lib/valgrind/libpthread.so ==16807== Reading syms from /lib/libdl-2.3.2.so ==16807== object doesn't have any debug info ==16807== Reading syms from /lib/tls/librt-2.3.2.so ==16807== object doesn't have any debug info ==16807== Reading syms from /net/opt_lnx/qt-3.1.2/lib/libqt-mt.so.3.1.2 ==16807== Reading syms from /lib/libnsl-2.3.2.so ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libXft.so.2.1 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/lib/libfontconfig.so.1.0 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/lib/libpng12.so.0.1.2.2 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/lib/libz.so.1.1.4 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /net/opt_lnx/local_rh90/lib/libGL.so.1.4.501 ==16807== Reading syms from /usr/X11R6/lib/libXmu.so.6.2 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libXrender.so.1.2 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/lib/libfreetype.so.6.3.2 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libXext.so.6.4 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libX11.so.6.2 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libSM.so.6.0 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libICE.so.6.3 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/lib/libexpat.so.0.4.0 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libXi.so.6.0 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libXt.so.6.0 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /lib/tls/libc-2.3.2.so ==16807== object doesn't have any debug info ==16807== Reading suppressions file: /opt/local_rh90/lib/valgrind/default.supp ==16807== Estimated CPU clock rate is 2796 MHz ==16807== REPLACING libc(__GI___errno_location) with libpthread(__errno_location) ==16807== REPLACING libc(__GI___h_errno_location) with libpthread(__h_errno_location) ==16807== REPLACING libc(__GI___res_state) with libpthread(__res_state) ==16807== valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector & 7) == 7' failed. sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==16807== at 0x42029E51: __new_exitfn (in /lib/tls/libc-2.3.2.so) ==16807== by 0x42029E08: __cxa_atexit_internal (in /lib/tls/libc-2.3.2.so) ==16807== by 0x40611727: (within /usr/lib/libstdc++.so.5.0.3) ==16807== by 0x40611779: (within /usr/lib/libstdc++.so.5.0.3) 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: js...@ac... In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel at ucar dot edu |
|
From: Steve G <lin...@ya...> - 2003-10-16 13:12:49
|
>I'm looking at distributing crocus as an independent skin, >like Josef W's Calltree. That's a shame unless its your personal preference. The main valgrind homepage does not link to your homepage and a lot of people might not be able to find it (or other skins for that matter). It would be nice if there was a list of resources on the main homepage that pointed to these other skins. Then you have the problem of rolling a skin into whatever version of valgrind is on your system. Sometimes its easy, sometimes there's fixups. I think that developers will get the most benefit if some of these newer skins were rolled in so that they are getting more use. Then there's another scenario...I am co-maintainer of xinetd. Occassionally in the past someone would report a problem, perhaps a core dumper. I have asked people to run valgrind on their copy of xinetd on their system if I couldn't reproduce the problem. These people are not necessarily programmers and if they were faced with resolving diff's, I would not be able to get as high a quality of feedback. Granted, they do not have to do this with memcheck. But based on the problem, crocus might be a good one to have them to run. (Not all problems reported on the xinetd mail list are about xinetd. Sometimes they are having issues with the daemon that xinetd is supposed to be starting for them.) >Massif might be rolled into the CVS HEAD sometime, though. Or >I could distribute that separately too. Not sure. Out of curiosity, why is this a candidate for the main distribution? It has dependancies on other libraries which complicates things. I'm not trying to disparage the Massif skin, I think its a good thing. I'm just curious why a skin that complicates the build is more likely to get into the main distribution than one that doesn't. Just curious... :) I guess my point is that valgrind is now an essential tool in my research & projects. I'd like to see more tests and easier ways of pulling that all together for non-programmers. Thanks, -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com |
|
From: Dirk M. <dm...@gm...> - 2003-10-16 13:08:16
|
On Thursday 16 October 2003 14:49, Peter Seiderer wrote: > is the following problem really a valgrind problem (and maybe resolved in > the latest snapshot)? I did not read anything about it in the news section, > but had the same problem using the new gdb-6.0 > version. We know about the problem, but there is no fix yet. As we play some nasty tricks with the stack, it is "okay" that gdb feels confused. It worked before because gdb wasn't able to correctly disassemble the method in older versions. Now it can, and we cannot trick it into unwinding the stack correctly anymore. Another solution has to be found. |
|
From: Peter S. <Pet...@gm...> - 2003-10-16 12:52:00
|
Hello, is the following problem really a valgrind problem (and maybe resolved in the latest snapshot)? I did not read anything about it in the news section, but had the same problem using the new gdb-6.0 version. http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&user=guest&password=guest&cmd=query And then go to bug number 1406 (the direct link to bug entry was way to long). Peter gdb bug 1406: [...] Description: gdb 5.3 or gdb 6.0 won't display the stack frame [ "Previous frame identical to this frame (corrupt stack?)" ] when is has been invoked by valgrind --gdb-attach=yes. I did not have this problem with gdb 5.2, and it does not seem to be related to a particular valgrind version or gcc version. [...] From the answer As you probably realised, the duplicate frame check isn't the real probelm here. If you look at the backtrace you provided: (gdb) where #0 vg_do_syscall3 (syscallno=4294966784, arg1=3161, arg2=0, arg3=0) at vg_mylibc.c:92 #1 0x40191b7d in vgPlain_system (cmd=0xbffff040 "/usr/bin/gdb -nw /proc/3160/exe 3160") at vg_mylibc.c:1277 #2 0x4018d727 in vgPlain_start_GDB_whilst_on_client_stack () at vg_main.c:1821 #3 0x40194e48 in vgPlain_swizzle_esp_then_start_GDB() from /usr/lib/valgrind/valgrind.so #4 0xbffff0d8 in ?? () #5 0x08048401 in coin () at k.c:5 Previous frame identical to this frame (corrupt stack?) (gdb) There's something rather suspicious about frame #4; I doubt that you're really executing code on the stack. It's defenitely more likely that GDB is unable to properly unwind frame #3. I took a quick look at valgrind, and vgPlain_swizzle_esp_then_start_GDB() is hand-coded assembler that fiddles with the stack. I'm not surprised that GDB chockes on this, and teaching GDB to properly unwind this particular frame is very difficult. It's properly a better idea to ask the author of valgrind to add DWARF Call Frame Info (DWARF CFI) to this particular bit of code. -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ |
|
From: Daniel B. <dan...@gm...> - 2003-10-16 11:26:26
|
Crocus is good value, and since it is an additional skin to add, it looks reasonably safe to drop in this release. Just gets confusing on your webpage where you talk about 'signal handlers', then use 'interrupt handlers' instead, in the same context ;-) . Dan > On Tue, 14 Oct 2003, Steve G wrote: > > > Aside from 2.5/2.6...will any of the new skins be rolled in? > > No, it's from the stable branch, no new features. > > > I know several developers using crocus, but they are maintaining > > their own patch set just to use it with a current copy of > > valgrind. > > I'm looking at distributing crocus as an independent skin, like Josef W's > Calltree. But I haven't worked out all the relevant automakery, etc. > > Massif might be rolled into the CVS HEAD sometime, though. Or I could > distribute that separately too. Not sure. > > > Annelid seems stable, too. > > Hmm, I don't think so; I know about all the duct tape and paper clips > that are holding it together :) I'm not yet convinced Annelid is actually > useful; if anyone has used it to find bugs, I'd like to hear from you. > > Thanks. > > N > -- Daniel J Blueman NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ |
|
From: Nicholas N. <nj...@ca...> - 2003-10-16 11:17:38
|
On Tue, 14 Oct 2003, Steve G wrote: > Aside from 2.5/2.6...will any of the new skins be rolled in? No, it's from the stable branch, no new features. > I know several developers using crocus, but they are maintaining > their own patch set just to use it with a current copy of > valgrind. I'm looking at distributing crocus as an independent skin, like Josef W's Calltree. But I haven't worked out all the relevant automakery, etc. Massif might be rolled into the CVS HEAD sometime, though. Or I could distribute that separately too. Not sure. > Annelid seems stable, too. Hmm, I don't think so; I know about all the duct tape and paper clips that are holding it together :) I'm not yet convinced Annelid is actually useful; if anyone has used it to find bugs, I'd like to hear from you. Thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2003-10-15 20:17:50
|
On Wed, 15 Oct 2003, Dennis Lubert wrote: > Perhaps the valgrind startup script should issue a warning if stat -c > %A <EXECUTABLE> | grep s gives some output ?? Dirk Mueller committed such a change to CVS. Thanks for pointing this out. N |
|
From: Julian S. <js...@ac...> - 2003-10-15 20:08:35
|
Includes fixes for a few bugs found in the previous stable release (20030725), improved SSE/SSE2 support, and POSIX Pthread spinlock support. Mostly nothing of great excitement compared to 20030725. Source, and a detailed list of changes are available at the usual place, http://developer.kde.org/~sewardj Happy *grinding, J |
|
From: Nicholas N. <nj...@ca...> - 2003-10-15 17:25:19
|
On Wed, 15 Oct 2003, Owen O'Malley wrote: > After a little investigation I found the following brain hiccup in > helgrind: > > ! VG_(track_post_mutex_lock) (& eraser_pre_mutex_lock); > > ! VG_(track_pre_mutex_lock) (& eraser_pre_mutex_lock); Yikes! Thanks for spotting it, I've committed the change. N |
|
From: Owen O'M. <ow...@em...> - 2003-10-15 17:05:13
|
I tried helgrind on my dining philosopher example program and it
didn't find the bug. After a little investigation I found the
following brain hiccup in helgrind:
*** helgrind/hg_main.c~ Thu Jul 24 14:00:16 2003
--- helgrind/hg_main.c Wed Oct 15 09:51:24 2003
***************
*** 3253,3259 ****
VG_(track_post_thread_create) (& hg_thread_create);
VG_(track_post_thread_join) (& hg_thread_join);
! VG_(track_post_mutex_lock) (& eraser_pre_mutex_lock);
VG_(track_post_mutex_lock) (& eraser_post_mutex_lock);
VG_(track_post_mutex_unlock) (& eraser_post_mutex_unlock);
--- 3253,3259 ----
VG_(track_post_thread_create) (& hg_thread_create);
VG_(track_post_thread_join) (& hg_thread_join);
! VG_(track_pre_mutex_lock) (& eraser_pre_mutex_lock);
VG_(track_post_mutex_lock) (& eraser_post_mutex_lock);
VG_(track_post_mutex_unlock) (& eraser_post_mutex_unlock);
with the fix helgrind does find the locking order problem.
Owen
|
|
From: John R.
|
> The problem I ran in to was trying to work out to make valgrind > allocate the thread area on thread creation - working out it's size > and how to initialise it seems to be horribly complicated plus it > seems to involved cloning a thread descriptor in the same format as > the libpthread one because libc knows about that and goes through it > to find the TLS data as far as I can work out. Even under linuxthreads, the very first instruction executed in a new thread can be a signal handler with access to thread-local storage. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=104368 where linuxthreads signal handlers must be wrapped to check for such a case. Either the thread area (%gs region) must be setup no later than the clone syscall, or else the thread start function and all signal handlers must be wrapped to check for proper %gs. |
|
From: Russ F. <rus...@ho...> - 2003-10-15 12:01:40
|
I move that this be added to the FAQ. It might not be frequent, but it's a biggie when it happens. >< > Perhaps sendmail has some protection agains preloading libraries ?? >< > But >< > how does it work, or how can I disable it for my sendmail to debug it >< > ? >< >< Aha, setuid programs can't have preloads. chmod u-s /usr/sbin/sendmail. >< _________________________________________________________________ Never get a busy signal because you are always connected with high-speed Internet access. Click here to comparison-shop providers. https://broadband.msn.com |
|
From: Tom H. <th...@cy...> - 2003-10-15 09:46:25
|
In message <232...@ww...>
Daniel Blueman <dan...@gm...> wrote:
> Hi Andrés,
>
> Thank you for your reply. Is there a chance that you be a little more
> specific about what patches, or where Julian can get them from?
The patches were attached to his email... They were just minor patches
to configure to make it recognise a 2.6 kernel.
To be honest I'm not sure what it is you're after - are you looking
for patches to make valgrind build and work as now, using the hack to
force LD_ASSUME_KERNEL in the startup script, or are you looking for
patches to make valgrind cope with nptl?
If the latter then I'm not convinced that there's a sane way to do
it I'm afraid because libc and libpthread are so much in bed with each
other now it seems.
I have a patch to make valgrind emulate the kernel TLS support and
handle the GDT references, and it works fine for single threaded
programs run under nptl once you realise that ld.so sets up the thread
area for the first thread before valgrind gets control so you have to
use the get_thread_area system call to setup the initial TLS records
in valgrind.
The problem comes when you create a new thread - normally the pthread
library sets up the thread area for the new thread when it calls clone
to create it, but obviously the valgrind pthread simulation doesn't do
any of that.
The problem I ran in to was trying to work out to make valgrind
allocate the thread area on thread creation - working out it's size
and how to initialise it seems to be horribly complicated plus it
seems to involved cloning a thread descriptor in the same format as
the libpthread one because libc knows about that and goes through it
to find the TLS data as far as I can work out.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Daniel B. <dan...@gm...> - 2003-10-15 09:11:12
|
Hi Andrés, Thank you for your reply. Is there a chance that you be a little more specific about what patches, or where Julian can get them from? Many thanks, Dan > I did these patches to support compilation of 20030725 for 2.6 kernels on > Debian. > > I don't know if it's what you're looking for but there they are. > > "Daniel Blueman" <dan...@gm...> writes: > > > I've heard a new release of Valgrind will be made soon '20031012', and > > Julian is willing to integrate the patches to support 2.5/2.6 kernels. > > > > Does anyone have any idea what patches are required? Any help would be > mu > ch > > appreciated! > > > > Please CC myself and js...@ac.... Thanks! > > > > -- > > Daniel J Blueman > > > > NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... > > Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService > > > > Jetzt kostenlos anmelden unter http://www.gmx.net > > > > +++ GMX - die erste Adresse für Mail, Message, More! +++ > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > SourceForge.net hosts over 70,000 Open Source Projects. > > See the people who have HELPED US provide better services: > > Click here: http://sourceforge.net/supporters.php > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > -- Daniel J Blueman NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ |
|
From: Dennis L. <pla...@in...> - 2003-10-14 23:36:04
|
< At 00:28 15.10.2003, you wrote: < On Wed, Oct 15, 2003 at 12:22:13AM +0200, Dennis Lubert wrote: < < > Perhaps sendmail has some protection agains preloading libraries ?? < > But < > how does it work, or how can I disable it for my sendmail to debug it < > ? < < Aha, setuid programs can't have preloads. chmod u-s /usr/sbin/sendmail. < < Have fun, < < Avery < Ah, yes, that solved the thing, sendmail was installed suid. There are always some things to learn left ;) Perhaps the valgrind startup script should issue a warning if stat -c %A <EXECUTABLE> | grep s gives some output ?? greets Dennis |
|
From: Steve G <lin...@ya...> - 2003-10-14 23:15:43
|
>setuid programs can't have preloads.
That should be easy to detect at startup in valgrind proper.
stat() should have it in the st_mode variable:
stat(execname, &st);
if (st.st_mode & S_ISUID) {
puts("setuid programs cannot have LD_PRELOAD
libraries...aborting.");
exit(1);
}
-Steve Grubb
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
|
|
From: Avery P. <ape...@ni...> - 2003-10-14 22:28:48
|
On Wed, Oct 15, 2003 at 12:22:13AM +0200, Dennis Lubert wrote: > Perhaps sendmail has some protection agains preloading libraries ?? But > how does it work, or how can I disable it for my sendmail to debug it ? Aha, setuid programs can't have preloads. chmod u-s /usr/sbin/sendmail. Have fun, Avery |
|
From: Dennis L. <pla...@in...> - 2003-10-14 22:22:17
|
> > It dsimply does not run under valgrind. A "valgrind sendmail" does not
> > give any of the usual valgrind output, even options like -dD, -q etc.
> > do
> > not change anything. Looking at the speed, sendmail does really run
> > under the real cpu, not under valgrindized one.
>
> I guess static linking is to blame... seg FAQ #5.
>
> N
I don't think that sendmail is statically linked :
kermit:~ # ldd /usr/sbin/sendmail
libdb-4.0.so => /usr/lib/libdb-4.0.so (0x40019000)
libnsl.so.1 => /lib/libnsl.so.1 (0x400bf000)
libresolv.so.2 => /lib/libresolv.so.2 (0x400d5000)
libldap.so.2 => /usr/lib/libldap.so.2 (0x400e7000)
liblber.so.2 => /usr/lib/liblber.so.2 (0x40115000)
libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x40121000)
libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x40151000)
libsasl.so.7 => /usr/lib/libsasl.so.7 (0x40227000)
libc.so.6 => /lib/i686/libc.so.6 (0x4023a000)
libdl.so.2 => /lib/libdl.so.2 (0x40358000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4035c000)
libpam.so.0 => /lib/libpam.so.0 (0x4038d000)
libgssapi.so.1 => /usr/lib/libgssapi.so.1 (0x40395000)
libkrb5.so.17 => /usr/lib/libkrb5.so.17 (0x403a0000)
libasn1.so.5 => /usr/lib/libasn1.so.5 (0x403d7000)
libroken.so.9 => /usr/lib/libroken.so.9 (0x403f9000)
libcom_err.so.1 => /usr/lib/libcom_err.so.1 (0x4040b000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x4040f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Perhaps sendmail has some protection agains preloading libraries ?? But
how does it work, or how can I disable it for my sendmail to debug it ?
greets
Dennis
|
|
From: Nicholas N. <nj...@ca...> - 2003-10-14 21:47:42
|
On Tue, 14 Oct 2003, Dennis Lubert wrote: > It dsimply does not run under valgrind. A "valgrind sendmail" does not > give any of the usual valgrind output, even options like -dD, -q etc. do > not change anything. Looking at the speed, sendmail does really run > under the real cpu, not under valgrindized one. I guess static linking is to blame... seg FAQ #5. N |
|
From: Dennis L. <pla...@in...> - 2003-10-14 21:42:50
|
> I think you need to define in what way it failed to work... Did it > crash? Did valgrind assert? Did it run but report no errors? > > Tom It dsimply does not run under valgrind. A "valgrind sendmail" does not give any of the usual valgrind output, even options like -dD, -q etc. do not change anything. Looking at the speed, sendmail does really run under the real cpu, not under valgrindized one. Dennis |