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-18 07:33:32
|
Klint Gore wrote: >ok. I got the 2.4.0 rc4 from http://www.goop.org/~jeremy/valgrind/dist/ >and it gives "segmentation fault" too. > >The diagnostics look the same as the original post. Is there anything >else I can generate to try and find out what's happening? > Could you (re)post the full output of your valgrind command (with -v)? Also, if you can make the binary available, with any non-standard libraries it needs, available, that would help. J |
|
From: Klint G. <kg...@kg...> - 2005-03-18 05:48:57
|
On Wed, 09 Mar 2005 10:43:21 +0100, Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote: > Hi, > > > I'm trying to use valgrind on a kylix "hello world" and it just says > > "Segmentation fault" and exits. Any ideas? (it looks ok on "valgrind > > --tool=none /bin/ls") > > You're using Valgrind 2.2.0, try the CVS version instead. ok. I got the 2.4.0 rc4 from http://www.goop.org/~jeremy/valgrind/dist/ and it gives "segmentation fault" too. The diagnostics look the same as the original post. Is there anything else I can generate to try and find out what's happening? klint. +---------------------------------------+-----------------+ : Klint Gore : "Non rhyming : : EMail : kg...@kg... : slang - the : : Snail : A.B.R.I. : possibilities : : Mail University of New England : are useless" : : Armidale NSW 2351 Australia : L.J.J. : : Fax : +61 2 6772 5376 : : +---------------------------------------+-----------------+ |
|
From: Jeremy F. <je...@go...> - 2005-03-18 03:04:58
|
Alex Ivershen wrote:
> Jeremy, I found it. Somewhere somehow VKI_SIGVGKILL is getting
> blocked (I haven't found where yet). I added a line in do_setmask()
> line 690 - right after removing SIGKILL and SIGSTOP from the mask we
> should also remove SIGVGKILL. Everything fell into place, the app
> shuts down and cleans up its threads perfectly. You might wanna patch
> it into the current CVS head.
Yep, that's the kind of thing I was expecting. Thanks for tracking it down!
Hm, though I'm confused. sanitize_client_sigmask should remove that
signal before blocking in a syscall, so there should be no way that it
isn't blocked...
J
|
|
From: Alex I. <ale...@in...> - 2005-03-18 00:49:38
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
Jeremy, I found it. Somewhere somehow VKI_SIGVGKILL is getting blocked (I
haven't found where yet). I added a line in do_setmask() line 690 - right
after removing SIGKILL and SIGSTOP from the mask we should also remove SIGVGKILL.
Everything fell into place, the app shuts down and cleans up its threads
perfectly. You might wanna patch it into the current CVS head.<br>
<br>
Thanks!<br>
Alex<br>
<br>
Jeremy Fitzhardinge wrote:<br>
<blockquote type="cite" cite="mid...@go...">
<pre wrap="">Alex Ivershen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I am using RedHat 8 (2.4.9-9 kernel, glibc 2.3.2, pthreads 0.10) amd
MontaVista Linux (kernel 2.4.20, glibc 2.2.5, pthreads 0.9).
Unfortunately, I can't get you a test case - the application is huge,
dynamically loads about 20 shared libs and must be running in a
sandbox with other apps.
However, I did some debugging, and it seems that the problem is in
cleaning up the threads in shutdown_actions() and reap_threads(). My
threads have a common semaphore, so when we are "zapping" the threads,
those ones that are not blocked are going out cleanly, but some
threads are still in __pthread_sigsuspend() call, and it looks like
it's not a cancellation point. Therefore, these suspended threads
never exit and valgrind never returns from reap_threads(). Ath the
same time the main thread already exited - thus I end up with a bunch
of orphaned threads on "ps".
</pre>
</blockquote>
<pre wrap=""><!---->
The zap should be pretty unconditional, and make any blocking syscall
unblock. It's possible the signal mask isn't getting set right and it's
blocking the VKI_SIGVGKILL signal rather than having it interrupt the
syscall. I'll take a closer look later.
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="$mailwrapcol">--
Alex G. Ivershen Tektronix, Inc.
Network Products Dept. 1500 N. Greenville Ave.
Tektronix, Inc. Richardson, TX 75081
Phone: +1-469-330-4295 USA
"I have noticed that the people who are late are often so much jollier than
the people who have to wait for them." E. V. Lucas
</pre>
<br>
------------------------------------------------------------------------
Confidentiality Notice: This e-mail transmission may contain
confidential and/or privileged information that is intended only for the
individual or entity named in the e-mail address. If you are not the
intended recipient, you are hereby notified that any disclosure,
copying, distribution or reliance upon the contents of this e-mail
message is strictly prohibited. If you have received this e-mail
transmission in error, please reply to the sender, so that proper
delivery can be arranged, and please delete the message from your
computer. Thank you.
Tektronix Texas, LLC formerly Inet Technologies, Inc.
------------------------------------------------------------------------
</body>
</html>
|
|
From: Jeremy F. <je...@go...> - 2005-03-17 22:56:32
|
Alex Ivershen wrote:
> I am using RedHat 8 (2.4.9-9 kernel, glibc 2.3.2, pthreads 0.10) amd
> MontaVista Linux (kernel 2.4.20, glibc 2.2.5, pthreads 0.9).
> Unfortunately, I can't get you a test case - the application is huge,
> dynamically loads about 20 shared libs and must be running in a
> sandbox with other apps.
>
> However, I did some debugging, and it seems that the problem is in
> cleaning up the threads in shutdown_actions() and reap_threads(). My
> threads have a common semaphore, so when we are "zapping" the threads,
> those ones that are not blocked are going out cleanly, but some
> threads are still in __pthread_sigsuspend() call, and it looks like
> it's not a cancellation point. Therefore, these suspended threads
> never exit and valgrind never returns from reap_threads(). Ath the
> same time the main thread already exited - thus I end up with a bunch
> of orphaned threads on "ps".
The zap should be pretty unconditional, and make any blocking syscall
unblock. It's possible the signal mask isn't getting set right and it's
blocking the VKI_SIGVGKILL signal rather than having it interrupt the
syscall. I'll take a closer look later.
J
|
|
From: Alex I. <ale...@in...> - 2005-03-17 21:49:41
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
Jeremy,<br>
<br>
I am using RedHat 8 (2.4.9-9 kernel, glibc 2.3.2, pthreads 0.10) amd MontaVista
Linux (kernel 2.4.20, glibc 2.2.5, pthreads 0.9). Unfortunately, I can't
get you a test case - the application is huge, dynamically loads about 20
shared libs and must be running in a sandbox with other apps.<br>
<br>
However, I did some debugging, and it seems that the problem is in cleaning
up the threads in shutdown_actions() and reap_threads(). My threads have
a common semaphore, so when we are "zapping" the threads, those ones that
are not blocked are going out cleanly, but some threads are still in __pthread_sigsuspend()
call, and it looks like it's not a cancellation point. Therefore, these suspended
threads never exit and valgrind never returns from reap_threads(). Ath the
same time the main thread already exited - thus I end up with a bunch of
orphaned threads on "ps".<br>
<br>
This seems to be a generic problem ... right now I got around it by commenting
out the call to reap_threads() in shutdown_actions() - at that point we nuked
all threads, and if some of them have not exited, there is nothing that can
be done. I do get a summary now.<br>
<br>
Let me know of the implications of commenting out that call or if there is
a better way to fix this. I am attaching the dump from valgrind assertion
failure, which shows the state of the threads that are lingering at exit.<br>
<br>
Thanks a lot, as always!<br>
Alex<br>
<br>
valgrind: core_os.c:85 (vgArch_terminate): Assertion `vgPlain_count_living_threads()
== 0' failed.<br>
==20739== at 0xB002E30D: ??? (vg_mylibc.c:1166)<br>
<br>
sched status:<br>
running_tid=0<br>
<br>
Thread 4: status = VgTs_WaitSys<br>
==20739== at 0x1BA7527D: __pthread_sigsuspend (in /lib/libpthread-0.10.so)<br>
==20739== by 0x1BA7408C: __pthread_wait_for_restart_signal (in /lib/libpthread-0.10.so)<br>
==20739== by 0x1BA70D77: <a class="moz-txt-link-abbreviated" href="mailto:pthread_cond_wait@@GLIBC_2.3.2">pthread_cond_wait@@GLIBC_2.3.2</a> (in /lib/libpthread-0.10.so)<br>
==20739== by 0x1B95E251: BinarySemaphore::Wait(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/arch/sun-sparc/BinarySemaphore.cc:100)<br>
==20739== by 0x1B9652B5: Process::SchedulerSuspend(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/arch/sun-sparc/process.cc:993)<br>
==20739== by 0x1B96665E: resched(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/arch/sun-sparc/resched.cc:35)<br>
==20739== by 0x1B975383: Process::TrigWait(unsigned int) (/probe/SimXinuRef/v503/os/src/geoXinu/src/sys/kernel/trigger.cc:113)<br>
<br>
Thread 7: status = VgTs_WaitSys<br>
==20739== at 0x1BA7527D: __pthread_sigsuspend (in /lib/libpthread-0.10.so)<br>
==20739== by 0x1BA7408C: __pthread_wait_for_restart_signal (in /lib/libpthread-0.10.so)<br>
==20739== by 0x1BA70D77: <a class="moz-txt-link-abbreviated" href="mailto:pthread_cond_wait@@GLIBC_2.3.2">pthread_cond_wait@@GLIBC_2.3.2</a> (in /lib/libpthread-0.10.so)<br>
==20739== by 0x1B95E251: BinarySemaphore::Wait(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/arch/sun-sparc/BinarySemaphore.cc:100)<br>
==20739== by 0x1B9652B5: Process::SchedulerSuspend(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/arch/sun-sparc/process.cc:993)<br>
==20739== by 0x1B96665E: resched(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/arch/sun-sparc/resched.cc:35)<br>
==20739== by 0x1B9816B6: KSemaphore::Wait(void) const (/home/agi/probe/v503.sim/os/src/geoXinu/src/../../libKal/src/xinu/KSemaphore.cpp:174)<br>
<br>
Thread 8: status = VgTs_WaitSys<br>
==20739== at 0x1BA7527D: __pthread_sigsuspend (in /lib/libpthread-0.10.so)<br>
==20739== by 0x1BA7408C: __pthread_wait_for_restart_signal (in /lib/libpthread-0.10.so)<br>
==20739== by 0x1BA70D77: <a class="moz-txt-link-abbreviated" href="mailto:pthread_cond_wait@@GLIBC_2.3.2">pthread_cond_wait@@GLIBC_2.3.2</a> (in /lib/libpthread-0.10.so)<br>
==20739== by 0x1B95E251: BinarySemaphore::Wait(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/arch/sun-sparc/BinarySemaphore.cc:100)<br>
==20739== by 0x1B9652B5: Process::SchedulerSuspend(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/arch/sun-sparc/process.cc:993)<br>
==20739== by 0x1B96665E: resched(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/arch/sun-sparc/resched.cc:35)<br>
==20739== by 0x1B9816B6: KSemaphore::Wait(void) const (/home/agi/probe/v503.sim/os/src/geoXinu/src/../../libKal/src/xinu/KSemaphore.cpp:174)<br>
<br>
Thread 10: status = VgTs_WaitSys<br>
==20739== at 0x1BA7527D: __pthread_sigsuspend (in /lib/libpthread-0.10.so)<br>
==20739== by 0x1BA7408C: __pthread_wait_for_restart_signal (in /lib/libpthread-0.10.so)<br>
==20739== by 0x1BA70D77: <a class="moz-txt-link-abbreviated" href="mailto:pthread_cond_wait@@GLIBC_2.3.2">pthread_cond_wait@@GLIBC_2.3.2</a> (in /lib/libpthread-0.10.so)<br>
==20739== by 0x1B95E251: BinarySemaphore::Wait(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/arch/sun-sparc/BinarySemaphore.cc:100)<br>
==20739== by 0x1B9652B5: Process::SchedulerSuspend(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/arch/sun-sparc/process.cc:993)<br>
==20739== by 0x1B96665E: resched(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/arch/sun-sparc/resched.cc:35)<br>
==20739== by 0x1B97405C: Process::Receive(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/sys/kernel/receive.cc:25)<br>
<br>
Thread 14: status = VgTs_WaitSys<br>
==20739== at 0x1BA7527D: __pthread_sigsuspend (in /lib/libpthread-0.10.so)<br>
==20739== by 0x1BA7408C: __pthread_wait_for_restart_signal (in /lib/libpthread-0.10.so)<br>
==20739== by 0x1BA70D77: <a class="moz-txt-link-abbreviated" href="mailto:pthread_cond_wait@@GLIBC_2.3.2">pthread_cond_wait@@GLIBC_2.3.2</a> (in /lib/libpthread-0.10.so)<br>
==20739== by 0x1B95E251: BinarySemaphore::Wait(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/arch/sun-sparc/BinarySemaphore.cc:100)<br>
==20739== by 0x1B9652B5: Process::SchedulerSuspend(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/arch/sun-sparc/process.cc:993)<br>
==20739== by 0x1B96665E: resched(void) (/home/agi/probe/v503.sim/os/src/geoXinu/src/arch/sun-sparc/resched.cc:35)<br>
==20739== by 0x1B975383: Process::TrigWait(unsigned int) (/probe/SimXinuRef/v503/os/src/geoXinu/src/sys/kernel/trigger.cc:113)<br>
<br>
<br>
<br>
Jeremy Fitzhardinge wrote:<br>
<blockquote type="cite" cite="mid...@go...">
<pre wrap="">Alex Ivershen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I am having a little problem with 2.4.0.rc4 handling signals in my app
- 2.2.0 worked fine. The application logic is as follows - the main
thread spawns about a dozen threads, then sits in pause() call in a
forever loop. At some point one of the threads determines that the
application must be shut down and sends a SIGNIT to the main thread,
which does some cleanup and exits the application.
With rc4 it results in a bunch of defunct threads and I never get a
summary on exit. Incidentally, I don't get a summary when calling
_exit() from within the code either (it used to work). Please, let me
know what workarounds I can use here. Below is the signal trace.
</pre>
</blockquote>
<pre wrap=""><!---->
What kernel/libc/libpthread/distro are you using? Is it possible to
isolate this in a test-case program?
J</pre>
</blockquote>
------------------------------------------------------------------------
Confidentiality Notice: This e-mail transmission may contain
confidential and/or privileged information that is intended only for the
individual or entity named in the e-mail address. If you are not the
intended recipient, you are hereby notified that any disclosure,
copying, distribution or reliance upon the contents of this e-mail
message is strictly prohibited. If you have received this e-mail
transmission in error, please reply to the sender, so that proper
delivery can be arranged, and please delete the message from your
computer. Thank you.
Tektronix Texas, LLC formerly Inet Technologies, Inc.
------------------------------------------------------------------------
</body>
</html>
|
|
From: Jeremy F. <je...@go...> - 2005-03-17 21:06:28
|
Alex Ivershen wrote:
> I am having a little problem with 2.4.0.rc4 handling signals in my app
> - 2.2.0 worked fine. The application logic is as follows - the main
> thread spawns about a dozen threads, then sits in pause() call in a
> forever loop. At some point one of the threads determines that the
> application must be shut down and sends a SIGNIT to the main thread,
> which does some cleanup and exits the application.
>
> With rc4 it results in a bunch of defunct threads and I never get a
> summary on exit. Incidentally, I don't get a summary when calling
> _exit() from within the code either (it used to work). Please, let me
> know what workarounds I can use here. Below is the signal trace.
What kernel/libc/libpthread/distro are you using? Is it possible to
isolate this in a test-case program?
J
|
|
From: Alex I. <ale...@in...> - 2005-03-17 19:06:54
|
Guys, I am having a little problem with 2.4.0.rc4 handling signals in my app - 2.2.0 worked fine. The application logic is as follows - the main thread spawns about a dozen threads, then sits in pause() call in a forever loop. At some point one of the threads determines that the application must be shut down and sends a SIGNIT to the main thread, which does some cleanup and exits the application. With rc4 it results in a bunch of defunct threads and I never get a summary on exit. Incidentally, I don't get a summary when calling _exit() from within the code either (it used to work). Please, let me know what workarounds I can use here. Below is the signal trace. Thanks! Alex Ivershen ==15915== Process terminating with default action of signal 2 (SIGINT) ==15915== at 0x1BA79741: pause (in /lib/libpthread-0.10.so) ==15915== by 0x8048B8B: main (/home/agi/probe/v503.sim/SimXinuApps/SimXinu/src/SimXinu.cc:109) --15915-- kill_thread zaps tid 2 lwp 16332 --15915-- kill_thread zaps tid 3 lwp 16334 --15915-- kill_thread zaps tid 4 lwp 16344 --15915-- kill_thread zaps tid 5 lwp 16345 --15915-- kill_thread zaps tid 6 lwp 16347 --15915-- kill_thread zaps tid 7 lwp 16348 --15915-- kill_thread zaps tid 8 lwp 16349 --15915-- kill_thread zaps tid 10 lwp 16352 --15915-- kill_thread zaps tid 12 lwp 16355 --15915-- kill_thread zaps tid 13 lwp 16357 --15915-- kill_thread zaps tid 14 lwp 16359 --15915-- kill_thread zaps tid 16 lwp 17182 --15915-- kill_thread zaps tid 17 lwp 17183 --15915-- kill_thread zaps tid 18 lwp 17233 --15915-- kill_thread zaps tid 19 lwp 17293 --15915-- kill_thread zaps tid 20 lwp 17299 --15915-- kill_thread zaps tid 21 lwp 17352 --15915-- kill_thread zaps tid 22 lwp 17366 --16332-- sigvgkill for lwp 16332 tid 2 --16332-- Sending SIGVGCHLD to master tid=1 lwp=15915 --16345-- sigvgkill for lwp 16345 tid 5 --16334-- sigvgkill for lwp 16334 tid 3 --16345-- Sending SIGVGCHLD to master tid=1 lwp=15915 --16347-- sigvgkill for lwp 16347 tid 6 --16347-- Sending SIGVGCHLD to master tid=1 lwp=15915 --16355-- sigvgkill for lwp 16355 tid 12 --16355-- Sending SIGVGCHLD to master tid=1 lwp=15915 --16357-- sigvgkill for lwp 16357 tid 13 --16357-- Sending SIGVGCHLD to master tid=1 lwp=15915 --15915-- Got 63 (code=-6) from tid lwp 16332 --15915-- Got 63 (code=-6) from tid lwp 16345 --15915-- Got 63 (code=-6) from tid lwp 16347 --15915-- Got 63 (code=-6) from tid lwp 16355 --15915-- Got 63 (code=-6) from tid lwp 16357 --16334-- Sending SIGVGCHLD to master tid=1 lwp=15915 --15915-- Got 63 (code=-6) from tid lwp 16334 --16353-- Sending SIGVGCHLD to master tid=1 lwp=15915 --15915-- Got 63 (code=-6) from tid lwp 16353 ------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Tektronix Texas, LLC formerly Inet Technologies, Inc. ------------------------------------------------------------------------ |
|
From: Xavier W. (OSIRIS-EDF) <xav...@de...> - 2005-03-17 10:21:34
|
Hi I try to use valgrind 2.2 to debug an application launched by python. valgrind --tool=memcheck --workaround-gcc296-bugs=yes --error-limit=no python MainExpert.py My program written in C++ named risk.so (loaded by python) can't be mapped : warning: mmap failed on /local/xwarin/electricity_derivatives-1-1-1/ED/Risk-BU/lib/risk.so ==16896== no symbols or debug info loaded It is a huge .so file : due to debug information it grows to 400 MB I looked into the mailing list and saw that i could change a variable KICKSTART_BASE to 0xa0000000 in coregrind/Makefile.am. I tried this fix up but it didn't improve. Any idea ? Should i take the latest snapshot of the code or an older valgrind version. Thanks Xavier |
|
From: Christian P. <tr...@ge...> - 2005-03-16 21:30:29
|
On Tuesday 15 March 2005 4:00 am, Jeremy Fitzhardinge wrote: > OK, I've put 2.4.0.rc4 up at http://www.goop.org/~jeremy/valgrind/dist/ > > Changes since rc3 are: > > * fix unexpected SIGSEGV when using memcheck on programs where the > first write to a particular 64k chunk is done by the FPU > * fix a problem with the sys_futex wrapper which was inspecting the > wrong arguments for FUTEX_REQUEUE > * format fixup for a debug printf by the way, while carefully reading the list here, even where=20 I can't use this tool since I'm having changed my system to amd64=20 and though can't use valgrind anymore :(, I do really appreciate=20 all the work you've put into this tool. I'm looking happily forward=20 in getting an amd64 version of valgrind anytime you've done it :) So, thanks, Christian Parpart. =2D-=20 Netiquette: http://www.ietf.org/rfc/rfc1855.txt 22:27:11 up 138 days, 14:57, 0 users, load average: 0.23, 0.36, 0.49 |
|
From: Patrick O. <Pat...@in...> - 2005-03-16 12:45:28
|
On Tue, 2005-03-15 at 17:39 +0000, Tom Hughes wrote:
> In message <111...@ph...>
> Robert Walsh <rj...@du...> wrote:
>
> > > Valgrind will periodically open /proc/self/maps to do some sanity
> > > checking. If the thread changes its id so that it can't open its own
> > > /proc/self/maps, then this will fail. You can use --sanity-level=0 to
> > > turn off the sanity checking. I guess the proper fix would be for
> > > Valgrind to keep /proc/self/maps open from the start in case it gets
> > > into a state where it can't open it later (chroot would also cause this).
> >
> > You often can't seek on stuff in /proc - is maps any different?
>
> So open it once at the start, leave that descriptor along (positioned
> at start of file) and dup it each time you want to read the file ;-)
File descriptors duplicated with dup() share the same file pointer,
so that won't work. From "man dup":
After successful return of dup or dup2, the old and new
descriptors may
be used interchangeably. They share locks, file position
pointers and
flags; for example, if the file position is modified by using
lseek on
one of the descriptors, the position is also changed for the
other.
At least once I also observed problems reading from the /proc file
system with fgets on a 2.4 kernel: the result was garbled as if the
content of the open file had changed while reading it. I'm not sure what
the official, portable solution is, but reading with read() in larger
chunks seemed to help.
What I would expect is that open() creates a snapshot of the current
state and then delivers that static copy. That would defeat the idea of
opening the file only once, but at least it would avoid the race
conditions that seem to exist.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Software & Solutions Group
Hermuelheimer Strasse 8a
50321 Bruehl
Germany
Tel: +49-2232-2090-30
Fax: +49-2232-2090-29
|
|
From: Nagi K. <Dem...@ke...> - 2005-03-16 12:25:08
|
Hello, room rose with him - save only M. de Cussy, who sat on with a gri held the island of Barbados. Benedicamus Domino, said the receiving still no answer from the Colonel, continued: It's a m them; for another a ship which he announced to be sinking offered natural vindictiveness of his fellow-slaves until he had been in Having thus emptied her basket, she called her negro, and without The Deputy-Governor was flung into panic. He lost his temper, an of Hispaniola. You should make them safely. And if you'll take when he was told of it. But happened it had, and he was forced t more, and up through that cloud to replace the flag of England so Have a good day. |
|
From: Jeremy F. <je...@go...> - 2005-03-16 02:51:33
|
Nicholas Nethercote wrote:
> On Tue, 15 Mar 2005, strk wrote:
>
>>> You could just use a blanket suppression on CG_* symbols to make all
>>> the
>>> noise go away...
>>
>>
>> Will the error count NOT increment in that case ?
>> (it gives up after 3000 errors are encountered)
>
>
> I think suppressed errors do not count towards the 30000 limit.
And you can use --error-limit=no, of course.
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-16 02:40:18
|
On Tue, 15 Mar 2005, strk wrote: >> You could just use a blanket suppression on CG_* symbols to make all the >> noise go away... > > Will the error count NOT increment in that case ? > (it gives up after 3000 errors are encountered) I think suppressed errors do not count towards the 30000 limit. N> |
|
From: Kjartan M. <km...@br...> - 2005-03-16 00:05:05
|
tir, 15,.03.2005 kl. 15.50 -0800, skrev Brian Anderson: > The subject says it all, can I install Valgrind without hindering the > other debuggers on my RedHat EL 4 system? > Sure you can. Valgrind doesn't depend on or hinder other debuggers installed on your system at all. Cheers Kjartan |
|
From: Robert W. <rj...@du...> - 2005-03-16 00:01:42
|
> The subject says it all, can I install Valgrind without hindering the > other debuggers on my RedHat EL 4 system? There's should be no problem. Are you seeing a problem? Regards, Robert. |
|
From: Brian A. <Bri...@ma...> - 2005-03-15 23:50:18
|
The subject says it all, can I install Valgrind without hindering the other debuggers on my RedHat EL 4 system? Thanks, BA Disclaimer: The information contained in this transmission, including = any attachments, may contain confidential information of Matsushita = Avionics Systems Corporation. This transmission is intended only for = the use of the addressee(s) listed above. Unauthorized review, = dissemination or other use of the information contained in this = transmission is strictly prohibited. If you have received this = transmission in error or have reason to believe you are not authorized = to receive it, please notify the sender by return email and promptly = delete the transmission |
|
From: Stephen T. <st...@to...> - 2005-03-15 22:09:04
|
On Tue, 2005-03-15 at 22:51 +0100, Kjartan Maraas wrote: > > > (If you can convince your mailer not to wrap these messages when posting > > > them, that would be nice.) > > > > If you know how to make Evolution do it I am all ears. > > > Set the style to "Preformat" when pasting output from valgrind or > anything else that is longer than linewidth. Thanks. Stephen |
|
From: Kjartan M. <km...@br...> - 2005-03-15 21:51:45
|
tir, 15,.03.2005 kl. 16.38 -0500, skrev Stephen Torri:
> On Tue, 2005-03-15 at 12:08 -0800, Jeremy Fitzhardinge wrote:
> > Stephen Torri wrote:
> >
> > >What is up with the std::string destructor?
> > >
> > >
> > Hard to say. I presume it is destructing textstring? Is val defined?
> > Try including <valgrind/memcheck.h> and doing
> > VALGRIND_CHECK_DEFINED(val) (though this depends on what val actually
> > is, and whether its valid to check every byte in the range [&val,
> > &val+1) for definedness.
>
> Where I believe I am using it val is of type 'std::string'.
>
> Here is what val is reported by gdb
>
> (gdb) print val
> $2 = {static npos = 4294967295,
> _M_dataplus = {<std::allocator<char>> =
> {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
> fields>}, _M_p = 0x1bfe0494 "pid"}}
>
>
> > (If you can convince your mailer not to wrap these messages when posting
> > them, that would be nice.)
>
> If you know how to make Evolution do it I am all ears.
>
Set the style to "Preformat" when pasting output from valgrind or
anything else that is longer than linewidth.
Cheers
Kjartan
|
|
From: Bryan O'S. <bo...@se...> - 2005-03-15 21:46:08
|
On Tue, 2005-03-15 at 16:38 -0500, Stephen Torri wrote: > If you know how to make Evolution do it I am all ears. Change the paragraph type from "Normal" to "Preformat". <b |
|
From: Stephen T. <st...@to...> - 2005-03-15 21:38:11
|
On Tue, 2005-03-15 at 12:08 -0800, Jeremy Fitzhardinge wrote:
> Stephen Torri wrote:
>
> >What is up with the std::string destructor?
> >
> >
> Hard to say. I presume it is destructing textstring? Is val defined?
> Try including <valgrind/memcheck.h> and doing
> VALGRIND_CHECK_DEFINED(val) (though this depends on what val actually
> is, and whether its valid to check every byte in the range [&val,
> &val+1) for definedness.
Where I believe I am using it val is of type 'std::string'.
Here is what val is reported by gdb
(gdb) print val
$2 = {static npos = 4294967295,
_M_dataplus = {<std::allocator<char>> =
{<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
fields>}, _M_p = 0x1bfe0494 "pid"}}
> (If you can convince your mailer not to wrap these messages when posting
> them, that would be nice.)
If you know how to make Evolution do it I am all ears.
Stephen
|
|
From: strk <st...@ke...> - 2005-03-15 20:39:19
|
On Tue, Mar 15, 2005 at 11:54:29AM -0800, Jeremy Fitzhardinge wrote: ... > On the other hand, since the program is using GC, the leak checker > probably won't be able to tell you much. Or are you interested in > Valgrinding some non-Java code linked in with the Java? I'm interested on checking if the non-Java code is leaking... It seems I can't do anything but trust the GC to be working > You could just use a blanket suppression on CG_* symbols to make all the > noise go away... Will the error count NOT increment in that case ? (it gives up after 3000 errors are encountered) --strk; |
|
From: strk <st...@ke...> - 2005-03-15 20:22:57
|
On Tue, Mar 15, 2005 at 01:40:10PM -0600, Nicholas Nethercote wrote: > On Tue, 15 Mar 2005, strk wrote: > > >$ valgrind --tool=addrcheck ./jtstest data1 > /dev/null > >... > >==26360== Invalid read of size 4 > >==26360== at 0x3489DE40: GC_push_all_eager (mark.c:1468) > >==26360== by 0x3489DEB1: GC_push_all_stack (mark.c:1521) > >==26360== by 0x348A6197: GC_push_all_stacks (pthread_stop_world.c:232) > >==26360== by 0x348A14D6: GC_default_push_other_roots (os_dep.c:1990) > >==26360== by 0x3489F563: GC_push_roots (mark_rts.c:643) > >==26360== by 0x3489E98E: GC_mark_some (mark.c:326) > >==26360== by 0x34895CCA: GC_stopped_mark (alloc.c:517) > >==26360== by 0x34896683: GC_try_to_collect_inner (alloc.c:364) > >==26360== by 0x34896EAD: GC_collect_or_expand (alloc.c:1007) > >==26360== by 0x34897069: GC_allocobj (alloc.c:1058) > >==26360== by 0x3489B68E: GC_generic_malloc_inner (malloc.c:134) > >==26360== by 0x3489C42E: GC_generic_malloc_many (mallocx.c:500) > >==26360== Address 0x9BDFF8CC is on thread 3's stack > > This might also be caused by the GC doing low-level things that Addrcheck > doesn't expect. > > >... > >[ then hangs here ] > > That's not so good. Does it hang with --tool=none? If so, can you please > file a bug report? Thanks. I take it back. It only took a long time, but returns.. --strk; > > N |
|
From: Jeremy F. <je...@go...> - 2005-03-15 20:08:22
|
Stephen Torri wrote:
>What is up with the std::string destructor?
>
>
Hard to say. I presume it is destructing textstring? Is val defined?
Try including <valgrind/memcheck.h> and doing
VALGRIND_CHECK_DEFINED(val) (though this depends on what val actually
is, and whether its valid to check every byte in the range [&val,
&val+1) for definedness.
(If you can convince your mailer not to wrap these messages when posting
them, that would be nice.)
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-15 19:54:41
|
strk wrote:
>Yes. valgrind-2.4.0.rc4.
>
>==26276== Conditional jump or move depends on uninitialised value(s)
>==26276== at 0x1C057E52: GC_push_all_eager (mark.c:1469)
>==26276== by 0x1C0593EE: GC_push_current_stack (mark_rts.c:488)
>==26276== by 0x1C060714: GC_generic_push_regs (mach_dep.c:452)
>==26276== by 0x1C059555: GC_push_roots (mark_rts.c:628)
>
Yeah, that's the Boehm garbage collector. It does stuff which no
correct program should do, like wander around reading random pieces of
memory. I once looked at what it would take to make it valgrind-clean,
and it would be a bit fiddley; you'd need to put in client requests to
tell Valgrind "no, this is actually OK" by twiddling the memory state,
doing the read, then restoring it. I guess a cleaner approach would be
something like VALGRIND_SAFE_MEMREAD/WRITE which says that you really
mean to read/write the address, and you want no complaints...
On the other hand, since the program is using GC, the leak checker
probably won't be able to tell you much. Or are you interested in
Valgrinding some non-Java code linked in with the Java?
You could just use a blanket suppression on CG_* symbols to make all the
noise go away...
J
|