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
(3) |
2
(5) |
3
(7) |
4
(8) |
5
(3) |
|
6
(2) |
7
|
8
(2) |
9
(20) |
10
(2) |
11
(14) |
12
(21) |
|
13
(6) |
14
(9) |
15
(31) |
16
(7) |
17
(5) |
18
(14) |
19
(3) |
|
20
(6) |
21
(9) |
22
(19) |
23
(14) |
24
(16) |
25
(10) |
26
(3) |
|
27
(2) |
28
(1) |
29
(10) |
30
(6) |
31
(16) |
|
|
|
From: Jeremy F. <je...@go...> - 2005-03-12 08:28:57
|
Tom Hughes wrote:
>I put a patch u plast night, although I'm worried it might break
>with stabs from other compilers. I agree this probably shouldn't
>hold up the release.
>
>
Looks fine to me; I just checked it in. We'll see if it breaks someone
else. I'm not sure where the 3rd parameter to R came from.
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-12 08:22:53
|
The address 0xB1285EB0 is within the Valgrind part of the address space,
which suggests that somehow it leaked into the client state. What's
strange is that you appear to be using --pointercheck=yes (which is the
default, and you don't seem to be turning it off), so I wouldn't expect
to see that particular kind of SIGSEGV (I'd expect to see GPF rather
than bad permissions).
Hm, come to think of it, it is possible that --pointercheck isn't
completely implemented for FP instructions.
If possible, could you grab a copy of /proc/<pid>/maps for that process,
so I can see/guess what's at 0xB1285EB0.
Have you tried other tools; it would be interesting to know if it only
happens under memcheck, or if addrcheck/none also cause it.
Is it possible to isolate this in a smaller piece of code?
J
|
|
From: Tom H. <to...@co...> - 2005-03-12 07:36:09
|
In message <423...@go...>
Jeremy Fitzhardinge <je...@go...> wrote:
> Tom Hughes wrote:
>
> >In message <E0D...@pe...>
> > "Duane Griffin" <d.g...@ps...> wrote:
> >
> >>2.4.0.rc2 crashes trying to read the debugging symbols from one of our
> >>libraries. On the other hand, so does 2.2, so I doubt it is a regression
> >>:)
> >
> >Can you enter a bug for this please.
>
> Are you planning on looking at this? Given that this bug seems old and
> hasn't caused too many problems, I'm not inclined to hold up the 2.4
> release pending its resolution, but if there's a simple obviously
> correct fix (as much as anything in the stabs parser can be) it would be
> nice to get in.
I put a patch u plast night, although I'm worried it might break
with stabs from other compilers. I agree this probably shouldn't
hold up the release.
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Bob R. <bo...@br...> - 2005-03-12 04:57:43
|
On Fri, Mar 11, 2005 at 10:42:15PM -0600, Nicholas Nethercote wrote: > > Hi, > > The Valgrind website has been totally overhauled, and moved. The new > address is: > > http://www.valgrind.org Great job on the new site! Do you think it would be to much of a hassle to redirect valgrind.org->www.valgrind.org? Bob Rossi |
|
From: Nicholas N. <nj...@cs...> - 2005-03-12 04:42:19
|
Hi, The Valgrind website has been totally overhauled, and moved. The new address is: http://www.valgrind.org Thanks to Donna Robinson for her wonderful job with this. Also, a new mailing list, valgrind-announce, has been created. You can sign up for it at: http://lists.sourceforge.net/lists/listinfo/valgrind-announce It will be a low-volume list that is used only for announcing new versions of Valgrind. N |
|
From: Jeremy F. <je...@go...> - 2005-03-12 00:44:13
|
Tom Hughes wrote:
>In message <E0D...@pe...>
> "Duane Griffin" <d.g...@ps...> wrote:
>
>
>
>>2.4.0.rc2 crashes trying to read the debugging symbols from one of our
>>libraries. On the other hand, so does 2.2, so I doubt it is a regression
>>:)
>>
>>
>
>Can you enter a bug for this please.
>
Are you planning on looking at this? Given that this bug seems old and
hasn't caused too many problems, I'm not inclined to hold up the 2.4
release pending its resolution, but if there's a simple obviously
correct fix (as much as anything in the stabs parser can be) it would be
nice to get in.
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-12 00:42:06
|
Patrick Ohly wrote:
>FYI, valgrind 2.2.0's pthread implementation seems to have
>a problem with pthread_atfork(): it only calls the given
>child function in the first forked process, but not
>in following ones.
>
>This is probably irrelevant given the fact that 2.4.0 won't
>implement pthread calls itself any more. However, with
>2.4.0 rc2 I ran into another problem where creating
>threads in a forked process would lead to a valgrind
>assertion.
>
This should be fixed in CVS now. I'll probably put out rc3 later today,
depending on whether anything else serious turns up.
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-12 00:40:20
|
Tom Truscott wrote:
>valgrind-2.4.0.rc2 is quite nice but it (and rc1) sometimes glitches
>if I resize the window after it starts running:
>
> valgrind: vg_syscalls.c:6106 (vgPlain_client_syscall): Assertion `tst->sig_mask.sig[0] == tst->tmp_sig_mask.sig[0]' failed.
> ==9054== at 0xB002E2C9: ??? (vg_mylibc.c:1166)
> ==9054== by 0xB002E2C8: assert_fail (vg_mylibc.c:1166)
> ==9054== by 0xB002E307: vgPlain_core_assert_fail (vg_mylibc.c:1177)
> ==9054== by 0xB004C4AD: vgPlain_client_syscall (vg_syscalls.c:6194)
> ==9054== by 0xB00159B0: handle_syscall (vg_scheduler.c:632)
> ==9054== by 0xB0015C5A: vgPlain_scheduler (vg_scheduler.c:733)
> ==9054== by 0xB006EB3A: vgArch_thread_wrapper (core_os.c:69)
>[...]
>As a possible clue, I noticed that if one runs the following program
>and then changes the window size, it remains pause()d when run standalone
>but terminates when run under valgrind.
>
>
I've fixed the unexpected interrupted syscall problem, but the assertion
failure is still a concern; it shouldn't have happened either way. Can
you reproduce it with CVS HEAD?
J
|
|
From: Tom H. <to...@co...> - 2005-03-11 23:05:42
|
In message <200...@lo...>
Tom Truscott <tr...@un...> wrote:
> I did (try to) submit a bug report for the interrupted-pause() quirk,
> since that still happens on newer systems.
The bug came through a few hours ago.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom T. <tr...@un...> - 2005-03-11 21:28:25
|
The Assertion is on an old Red Hat system with an old pthreads library, and does not happen on newer ones. So forget that. I did (try to) submit a bug report for the interrupted-pause() quirk, since that still happens on newer systems. Tom Truscott |
|
From: Tom H. <to...@co...> - 2005-03-11 18:38:21
|
In message <E0D...@pe...>
"Duane Griffin" <d.g...@ps...> wrote:
> 2.4.0.rc2 crashes trying to read the debugging symbols from one of our
> libraries. On the other hand, so does 2.2, so I doubt it is a regression
> :)
Can you enter a bug for this please.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeremy F. <je...@go...> - 2005-03-11 17:02:39
|
Tom Truscott wrote:
>valgrind-2.4.0.rc2 is quite nice but it (and rc1) sometimes glitches
>if I resize the window after it starts running:
>
> valgrind: vg_syscalls.c:6106 (vgPlain_client_syscall): Assertion `tst->sig_mask.sig[0] == tst->tmp_sig_mask.sig[0]' failed.
> ==9054== at 0xB002E2C9: ??? (vg_mylibc.c:1166)
> ==9054== by 0xB002E2C8: assert_fail (vg_mylibc.c:1166)
> ==9054== by 0xB002E307: vgPlain_core_assert_fail (vg_mylibc.c:1177)
> ==9054== by 0xB004C4AD: vgPlain_client_syscall (vg_syscalls.c:6194)
> ==9054== by 0xB00159B0: handle_syscall (vg_scheduler.c:632)
> ==9054== by 0xB0015C5A: vgPlain_scheduler (vg_scheduler.c:733)
> ==9054== by 0xB006EB3A: vgArch_thread_wrapper (core_os.c:69)
>
> sched status:
> running_tid=1
>
> Thread 1: status = VgTs_Runnable
> ==9054== at 0x42028D69: sigsuspend (in /lib/i686/libc-2.2.93.so)
> ==9054== by 0x1B91D107: __pthread_wait_for_restart_signal (in /lib/i686/libpthread-0.10.so)
> ==9054== by 0x1B91A04A: pthread_cond_wait (in /lib/i686/libpthread-0.10.so)
> ==9054== by 0x1BAABF59: bktWait (/sas/dev/mva/TKLNX/src/TKLNXbktWait.c:110)
> ==9054== by 0x1BAAAD9B: sktWait (/sas/dev/mva/tkp/src/sktWait.c:124)
> ==9054== by 0x815EEFE: tkWait (/sas/dev/mva/tkp/src/tkwait.c:57)
> ==9054== by 0x8062A67: main (/sas/dev/mva/dsup/src/hamain.c:94)
>
>
> Thread 2: status = VgTs_WaitSys
> ==9054== at 0x420D224B: poll (in /lib/i686/libc-2.2.93.so)
> ==9054== by 0x1B91AD9D: __pthread_manager (in /lib/i686/libpthread-0.10.so)
> ==9054== by 0x420DA1C9: clone (in /lib/i686/libc-2.2.93.so)
>
> Thread 3: status = VgTs_Runnable
> ==9054== at 0x420D3B2E: select (in /lib/i686/libc-2.2.93.so)
> ==9054== by 0x1BAAC6F7: bktHandleChildProcess (/sas/dev/mva/TKPOS/src/TKPOSbktchsrv.c:198)
> ==9054== by 0x1BAAA4EE: sktMain (/sas/dev/mva/tkp/src/sktMain.c:95)
> ==9054== by 0x1BAABDC8: bktMain (/sas/dev/mva/TKPOS/src/TKPOSbktMain.c:97)
> ==9054== by 0x1B91B940: pthread_start_thread (in /lib/i686/libpthread-0.10.so)
> ==9054== by 0x420DA1C9: clone (in /lib/i686/libc-2.2.93.so)
>
>
> Thread 4: status = VgTs_Runnable
> ==9054== at 0x420CDA84: open (in /lib/i686/libc-2.2.93.so)
>
>As a possible clue, I noticed that if one runs the following program
>and then changes the window size, it remains pause()d when run standalone
>but terminates when run under valgrind.
>
That's possible. The symptom you're seeing isn't directly related to
that, but it could certainly be indirectly related. Could you file a
bug for this?
Thanks,
J
|
|
From: Duane G. <d.g...@ps...> - 2005-03-11 17:00:21
|
Hi folks,=20 2.4.0.rc2 crashes trying to read the debugging symbols from one of our libraries. On the other hand, so does 2.2, so I doubt it is a regression :) To be honest, I'm not surprised it is falling over. We are running on a very old RedHat 7.2 system, and the library that crashes on includes C and C++ code compiled with gcc 2.96, plus FORTRAN code compiled by an old version (3.2-4) of the PGI compiler. On the other hand the PGI compiler is supposedly generating GNU debugging info, and gdb doesn't seem to mind it. The error is the same with or without the --workaround-gcc296-bugs flag. If I run with the release version of the library, i.e. without debugging information, it all seems to work fine. > uname -a Linux cucumbertree.psenterprise.com 2.4.9-13SGI_XFS_1.0.2smp #1 SMP Thu Nov 15 14:05:48 CST 2001 i686 unknown > valgrind -v --workaround-gcc296-bugs=3Dyes gPROMSconsoled.exe =3D=3D5130=3D=3D Memcheck, a memory error detector for x86-linux. =3D=3D5130=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian = Seward et al. =3D=3D5130=3D=3D Using valgrind-2.4.0.rc2, a program supervision = framework for x86-linux. =3D=3D5130=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian = Seward et al. =3D=3D5130=3D=3D Valgrind library directory: /usr/local/lib/valgrind =3D=3D5130=3D=3D Command line =3D=3D5130=3D=3D gPROMSconsoled.exe =3D=3D5130=3D=3D Startup, with flags: =3D=3D5130=3D=3D -v =3D=3D5130=3D=3D --workaround-gcc296-bugs=3Dyes =3D=3D5130=3D=3D Contents of /proc/version: =3D=3D5130=3D=3D Linux version 2.4.9-13SGI_XFS_1.0.2smp (root@gibble) = (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Thu Nov 15 14:05:48 CST 2001 =3D=3D5130=3D=3D Reading syms from /home/duaneg/projects/trunk/src/build/LINUX/debug/bin/gPROMSconsoled.exe (0x8048000) =3D=3D5130=3D=3D Reading syms from /lib/ld-2.2.4.so (0x1B8E4000) =3D=3D5130=3D=3D Reading syms from /usr/local/lib/valgrind/stage2 = (0xB0000000) =3D=3D5130=3D=3D Reading syms from /lib/ld-2.2.4.so (0xB1000000) =3D=3D5130=3D=3D Reading syms from /lib/libdl-2.2.4.so (0xB1032000) =3D=3D5130=3D=3D Reading syms from /lib/i686/libc-2.2.4.so (0xB1036000) =3D=3D5130=3D=3D Reading syms from = /usr/local/lib/valgrind/vgskin_memcheck.so (0xB1300000) =3D=3D5130=3D=3D Reading suppressions file: = /usr/local/lib/valgrind/default.supp =3D=3D5130=3D=3D =3D=3D5130=3D=3D Reading syms from /usr/local/lib/valgrind/vg_inject.so (0x1B8FE000) =3D=3D5130=3D=3D Reading syms from = /usr/local/lib/valgrind/vgpreload_memcheck.so (0x1B901000) =3D=3D5130=3D=3D Reading syms from /home/duaneg/projects/trunk/src/build/LINUX/debug/lib/libgLinkedMsgFiled .so (0x1B909000) =3D=3D5130=3D=3D Reading syms from /home/duaneg/projects/trunk/src/build/LINUX/debug/lib/libInterruptCheckd .so (0x1B922000) =3D=3D5130=3D=3D Reading syms from /home/duaneg/projects/trunk/src/build/LINUX/debug/lib/libgSERVER3d.so (0x1B928000) =3D=3D5130=3D=3D warning: mmap failed on /home/duaneg/projects/trunk/src/build/LINUX/debug/lib/libgSERVER3d.so =3D=3D5130=3D=3D no symbols or debug info loaded =3D=3D5130=3D=3D Reading syms from /home/duaneg/projects/trunk/src/build/LINUX/debug/lib/libgSERVERd.so (0x1C5EF000) =20 @@ expected ';' at FP-TYPE extra (remains=3D"double = precision:t7=3DR2;8;") @@ parsing 6=3DR1;4; gave NULL type (R1;4; remains) --5130-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --5130-- si_code=3D1 Fault EIP: 0xB003F013; Faulting address: 0x0 --5130-- esp=3D0xB03FEBE8 =20 =20 valgrind: the `impossible' happened: Killed by fatal signal Basic block ctr is approximately 9330 =3D=3D5130=3D=3D at 0xB003F013: vgPlain_st_basetype = (vg_symtypes.c:423) =3D=3D5130=3D=3D by 0xB003D357: initSym (vg_stabs.c:1079) =3D=3D5130=3D=3D by 0xB003DE8F: vgPlain_read_debuginfo_stabs (vg_stabs.c:1655) =3D=3D5130=3D=3D by 0xB00383F0: vg_read_lib_symbols = (vg_symtab2.c:1485) =3D=3D5130=3D=3D by 0xB00385F6: vgPlain_read_seg_symbols = (vg_symtab2.c:1564) =3D=3D5130=3D=3D by 0xB002E2F5: vgPlain_map_file_segment = (vg_memory.c:408) =3D=3D5130=3D=3D by 0xB002E43D: vgPlain_map_fd_segment = (vg_memory.c:465) =3D=3D5130=3D=3D by 0xB003FFCD: mmap_segment (vg_syscalls.c:192) =3D=3D5130=3D=3D by 0xB004B431: vgArch_gen_old_mmap_before (vg_syscalls.c:4339) =3D=3D5130=3D=3D by 0xB0050D65: vgPlain_client_syscall = (vg_syscalls.c:6138) =3D=3D5130=3D=3D by 0xB0017139: handle_syscall (vg_scheduler.c:632) =3D=3D5130=3D=3D by 0xB0017451: vgPlain_scheduler = (vg_scheduler.c:733) =20 sched status: running_tid=3D1 =20 Thread 1: status =3D VgTs_Runnable =3D=3D5130=3D=3D at 0x1B8F66ED: mmap (in /lib/ld-2.2.4.so) =3D=3D5130=3D=3D by 0x1B8EBC28: _dl_map_object (dl-load.c:1740) =3D=3D5130=3D=3D by 0x1B8F11AB: openaux (dl-deps.c:68) =3D=3D5130=3D=3D by 0x1B8F1712: _dl_catch_error (dl-error.c:152) =3D=3D5130=3D=3D by 0x1B8F0677: _dl_map_object_deps (dl-deps.c:248) =3D=3D5130=3D=3D by 0x1B8E6732: dl_main (rtld.c:881) =3D=3D5130=3D=3D by 0x1B8F4006: _dl_sysdep_start (../sysdeps/generic/dl-sysdep.c:207) =3D=3D5130=3D=3D by 0x1B8E640E: _dl_start_final (rtld.c:262) =3D=3D5130=3D=3D by 0x1B8E6202: _dl_start (rtld.c:214) =3D=3D5130=3D=3D by 0x1B8E5E65: (within /lib/ld-2.2.4.so) Cheers,=20 Duane. _____________________________________________________________ Duane Griffin Senior Software Developer Process Systems Enterprise Limited - "The model company" Bridge Studios, 107a Hammersmith Bridge Road, London W6 9DA Call +44 (0)20 8563 0888 or visit us at www.psenterprise.com |
|
From: Tom T. <tr...@un...> - 2005-03-11 16:42:19
|
valgrind-2.4.0.rc2 is quite nice but it (and rc1) sometimes glitches
if I resize the window after it starts running:
valgrind: vg_syscalls.c:6106 (vgPlain_client_syscall): Assertion `tst->sig_mask.sig[0] == tst->tmp_sig_mask.sig[0]' failed.
==9054== at 0xB002E2C9: ??? (vg_mylibc.c:1166)
==9054== by 0xB002E2C8: assert_fail (vg_mylibc.c:1166)
==9054== by 0xB002E307: vgPlain_core_assert_fail (vg_mylibc.c:1177)
==9054== by 0xB004C4AD: vgPlain_client_syscall (vg_syscalls.c:6194)
==9054== by 0xB00159B0: handle_syscall (vg_scheduler.c:632)
==9054== by 0xB0015C5A: vgPlain_scheduler (vg_scheduler.c:733)
==9054== by 0xB006EB3A: vgArch_thread_wrapper (core_os.c:69)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==9054== at 0x42028D69: sigsuspend (in /lib/i686/libc-2.2.93.so)
==9054== by 0x1B91D107: __pthread_wait_for_restart_signal (in /lib/i686/libpthread-0.10.so)
==9054== by 0x1B91A04A: pthread_cond_wait (in /lib/i686/libpthread-0.10.so)
==9054== by 0x1BAABF59: bktWait (/sas/dev/mva/TKLNX/src/TKLNXbktWait.c:110)
==9054== by 0x1BAAAD9B: sktWait (/sas/dev/mva/tkp/src/sktWait.c:124)
==9054== by 0x815EEFE: tkWait (/sas/dev/mva/tkp/src/tkwait.c:57)
==9054== by 0x8062A67: main (/sas/dev/mva/dsup/src/hamain.c:94)
Thread 2: status = VgTs_WaitSys
==9054== at 0x420D224B: poll (in /lib/i686/libc-2.2.93.so)
==9054== by 0x1B91AD9D: __pthread_manager (in /lib/i686/libpthread-0.10.so)
==9054== by 0x420DA1C9: clone (in /lib/i686/libc-2.2.93.so)
Thread 3: status = VgTs_Runnable
==9054== at 0x420D3B2E: select (in /lib/i686/libc-2.2.93.so)
==9054== by 0x1BAAC6F7: bktHandleChildProcess (/sas/dev/mva/TKPOS/src/TKPOSbktchsrv.c:198)
==9054== by 0x1BAAA4EE: sktMain (/sas/dev/mva/tkp/src/sktMain.c:95)
==9054== by 0x1BAABDC8: bktMain (/sas/dev/mva/TKPOS/src/TKPOSbktMain.c:97)
==9054== by 0x1B91B940: pthread_start_thread (in /lib/i686/libpthread-0.10.so)
==9054== by 0x420DA1C9: clone (in /lib/i686/libc-2.2.93.so)
Thread 4: status = VgTs_Runnable
==9054== at 0x420CDA84: open (in /lib/i686/libc-2.2.93.so)
As a possible clue, I noticed that if one runs the following program
and then changes the window size, it remains pause()d when run standalone
but terminates when run under valgrind.
#include <unistd.h>
int
main()
{
pause();
return 0;
}
Tom Truscott
|
|
From: <ar...@de...> - 2005-03-11 14:33:47
|
Jeremy Fitzhardinge <je...@go...> writes: > OK, I've put 2.4.0.rc2 up at http://www.goop.org/~jeremy/valgrind/dist/ An up-to-date Debian package is available at: http://incoming.debian.org/valgrind_2.2.0+2.4.0rc2-1_i386.deb Thanks. -- Andr=E9s Rold=E1n ar...@fl... / Fluidsignal Group S.A. ar...@de... / The Debian Project Mobile: +57 300-7920981 GPG F/P: 0EE9 27C9 55F1 92E4 3809 B852 D8E0 724B B293 96EB http://people.fluidsignal.com/~aroldan |
|
From: Nicholas N. <nj...@cs...> - 2005-03-11 14:19:20
|
On Fri, 11 Mar 2005, Patrick Ohly wrote: > For that one I have filed a bug: > http://bugs.kde.org/show_bug.cgi?id=101291 > The test program listed there demonstrates both > problems. Thanks for the report. Looks like Jeremy is on it. N |
|
From: Nicholas N. <nj...@cs...> - 2005-03-11 14:11:16
|
On Fri, 11 Mar 2005, Christian Parpart wrote: >> No, the hope is to get PPC32 support into the 3.0 release later >> in the year along with AMD64 support. > > Yay! That's what I wanted to read (the AMD64 part). > While waiting for 3.0 then, maybe you can tell me > what's new in 2.4? 2.4 has 6 months worth of bug fixes. Also, the way in which Valgrind handles threads has changed completely -- Valgrind no longer provides its own implementation of libpthread. This is a big win because that part was a total headache to maintain, and a frequent source of bugs. Getting rid of it let us remove thousands of lines of the most difficult and error-prone code in Valgrind. The down-side is that the change broke Helgrind and the pthread bug detection (eg. misuses of mutexes). We're working on reinstating those features, but they're not in 2.4.0 -- we decided it had been long enough between releases that 2.4.0 should ship without them. > ((btw, can you provide me a state of amd64 porting? maybe, > that you already finished up to N% of porting? thanks)) Percentages are hard to estimate. A little birdie told me that Mozilla has been seen to run successfully. But there's still a *lot* of work to be done to get it release-worthy -- getting AMD64 to work has required rewriting the entire JITter, which is a pretty decent chunk of Valgrind. N |
|
From: Patrick O. <Pat...@in...> - 2005-03-11 10:15:54
|
Hi all, FYI, valgrind 2.2.0's pthread implementation seems to have a problem with pthread_atfork(): it only calls the given child function in the first forked process, but not in following ones. This is probably irrelevant given the fact that 2.4.0 won't implement pthread calls itself any more. However, with 2.4.0 rc2 I ran into another problem where creating threads in a forked process would lead to a valgrind assertion. For that one I have filed a bug: http://bugs.kde.org/show_bug.cgi?id=101291 The test program listed there demonstrates both problems. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. |
|
From: Tom H. <to...@co...> - 2005-03-11 09:16:11
|
In message <6.1...@po...>
Dennis Lubert <pla...@in...> wrote:
> Now the question, how does valgrind do the scheduling here ? Where can
> context switches happen, only at the boundaries of basic blocks ? Or
> anywhere ?
They will only occur at basic block boundaries I believe. There will
also only ever be one thread running at a time even on an SMP machine.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dennis L. <pla...@in...> - 2005-03-11 09:07:24
|
Hi, I have a question to how valgrind behaves when running a multithreaded program on a smp machine. I recently discovered a subtle error in our program that only showed up once in a while but very often on smp machines. The reason was that on the smp machines two threads were really run parallel and non-thread-safe parts of the program could interfere directly, while when run on a uniprocessor threads were run one after each other, reducing the possibility of the bug appearing. Now the question, how does valgrind do the scheduling here ? Where can context switches happen, only at the boundaries of basic blocks ? Or anywhere ? greets Dennis Carpe quod tibi datum est |
|
From: Jeremy F. <je...@go...> - 2005-03-11 07:04:24
|
OK, I've put 2.4.0.rc2 up at http://www.goop.org/~jeremy/valgrind/dist/ This update fixes the following problems relative to rc1: * massif no longer crashes (caused by calloc not clearing memory) * suppressions with unmatched symbols no longer cause an assertion failure * Old-form sigsuspend and sigaction no longer cause Valgrind to die with a SEGV if you pass NULL signal sets * better reporting of internal errors * some printf format strings have been fixed * copyrights updated The NEWS file relative to 2.2.0 is attached. J |
|
From: Christian P. <tr...@ge...> - 2005-03-11 06:46:33
|
On Wednesday 09 March 2005 11:38 am, Tom Hughes wrote: > In message <200...@fr...> > > I was hoping that PPC support might have been merged into the main tree. > > I didn't know if it would work or not. This is really just confirmation > > that the check for CPU types works - I haven't tried any patches. > > No, the hope is to get PPC32 support into the 3.0 release later > in the year along with AMD64 support. Yay! That's what I wanted to read (the AMD64 part). While waiting for 3.0 then, maybe you can tell me=20 what's new in 2.4? ((btw, can you provide me a state of amd64 porting? maybe,=20 that you already finished up to N% of porting? thanks)) Regards, Christian Parpart. =2D-=20 Netiquette: http://www.ietf.org/rfc/rfc1855.txt 07:44:22 up 133 days, 14 min, 1 user, load average: 0.00, 0.02, 0.00 |
|
From: Robert W. <rj...@du...> - 2005-03-10 21:01:37
|
Ming Yang wrote: > I have seen another thread talking about this problem. I have tried > recompiling BDB with --with-mutex=x86/gcc-assembly, it still exits with > error "Function not implemented". Anyone has another suggestion to the > problem? Try the CVS head? |
|
From: Ming Y. <min...@ya...> - 2005-03-10 20:50:48
|
I have seen another thread talking about this problem. I have tried recompiling BDB with --with-mutex=x86/gcc-assembly, it still exits with error "Function not implemented". Anyone has another suggestion to the problem? Thanks in advance for any help, Ming --------------------------------- Do you Yahoo!? Yahoo! Small Business - Try our new resources site! |
|
From: Tom T. <tr...@un...> - 2005-03-09 21:27:28
|
I've encountered a SEGV apparently due to a sigprocmask with a null argument.
"Apparently" because I could not create a stand-alone reproducer.
The following hack works around my problem.
*** vg_syscalls.c.orig Tue Mar 1 01:20:15 2005
--- vg_syscalls.c Wed Mar 9 16:19:02 2005
***************
*** 366,368 ****
VG_(sigemptyset)(set);
! set->sig[0] = *oldset;
}
--- 366,371 ----
VG_(sigemptyset)(set);
! if (oldset)
! set->sig[0] = *oldset;
! else
! VG_(message)(Vg_UserMsg, "convert_sigset_to_rt: ignoring null oldset");
}
Tom Truscott
|