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
(1) |
|
3
(3) |
4
(6) |
5
(6) |
6
(9) |
7
(11) |
8
(8) |
9
(1) |
|
10
(4) |
11
(4) |
12
(13) |
13
(21) |
14
(5) |
15
(4) |
16
(6) |
|
17
(4) |
18
(12) |
19
(3) |
20
(20) |
21
(8) |
22
(4) |
23
(1) |
|
24
(1) |
25
(8) |
26
(11) |
27
(3) |
28
(8) |
29
(1) |
30
(3) |
|
From: Karim B. <kar...@gm...> - 2006-09-18 13:36:34
|
Julian Seward wrote: >Please file a bug report as described at > http://www.valgrind.org/support/bug_reports.html. That ensures >the bug will not be forgotten about. > >There is something strange happening with stack unwinding on amd64 >here. What is needed is a way to reproduce the failure. Can you >create a small test program which shows the problem, or at least >make it easy to reproduce the problem somehow? > > > sorry it is not easy for me to find an easy way to reproduce this problem (bug framework in HEP Physics) But I have started the same job on a Xeon to see what happens >J > > >On Monday 18 September 2006 09:06, Karim Bernardet wrote: > > >>Hi >> >>You can find the full logfile here : >> >>http://atlas-france.in2p3.fr/Activites/Informatique/TMP/ProdBranch/rel_6/Re >>cFull.log.gz >> >>Cheers >> >>Karim >> >>Julian Seward wrote: >> >> >>>On Saturday 16 September 2006 18:03, karim bernardet wrote: >>> >>> >>>>Hi >>>> >>>>Valgrind 3.2.0 + memcheck crashes with a code : >>>> >>>>... >>>>==9576== by 0x42DE696: PyEval_EvalFrame (ceval.c:2163) >>>>==9576== by 0x42DF128: PyEval_EvalCodeEx (ceval.c:2736) >>>>==9576== by 0x42E0932: fast_function (ceval.c:3651) >>>>HepMcParticleLink INFO cptr: Using >>>>TruthEvent as McEventCollection key for this job >>>>--9576-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) >>>>- exiting >>>>--9576-- si_code=80; Faulting address: 0x0; sp: 0x6278DD2C >>>> >>>> >>>Show us the complete output of valgrind, not just the part where it >>>crashed. >>> >>>J >>> >>>------------------------------------------------------------------------- >>>Using Tomcat but need to do more? Need to support web services, security? >>>Get stuff done quickly with pre-integrated technology to make your job >>>easier Download IBM WebSphere Application Server v.1.0.1 based on Apache >>>Geronimo >>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >>>_______________________________________________ >>>Valgrind-users mailing list >>>Val...@li... >>>https://lists.sourceforge.net/lists/listinfo/valgrind-users >>> >>> >>------------------------------------------------------------------------- >>Using Tomcat but need to do more? Need to support web services, security? >>Get stuff done quickly with pre-integrated technology to make your job >>easier Download IBM WebSphere Application Server v.1.0.1 based on Apache >>Geronimo >>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >>_______________________________________________ >>Valgrind-users mailing list >>Val...@li... >>https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> > > > |
|
From: Julian S. <js...@ac...> - 2006-09-18 10:04:44
|
Please file a bug report as described at http://www.valgrind.org/support/bug_reports.html. That ensures the bug will not be forgotten about. There is something strange happening with stack unwinding on amd64 here. What is needed is a way to reproduce the failure. Can you create a small test program which shows the problem, or at least make it easy to reproduce the problem somehow? J On Monday 18 September 2006 09:06, Karim Bernardet wrote: > Hi > > You can find the full logfile here : > > http://atlas-france.in2p3.fr/Activites/Informatique/TMP/ProdBranch/rel_6/Re >cFull.log.gz > > Cheers > > Karim > > Julian Seward wrote: > >On Saturday 16 September 2006 18:03, karim bernardet wrote: > >>Hi > >> > >>Valgrind 3.2.0 + memcheck crashes with a code : > >> > >>... > >>==9576== by 0x42DE696: PyEval_EvalFrame (ceval.c:2163) > >>==9576== by 0x42DF128: PyEval_EvalCodeEx (ceval.c:2736) > >>==9576== by 0x42E0932: fast_function (ceval.c:3651) > >>HepMcParticleLink INFO cptr: Using > >>TruthEvent as McEventCollection key for this job > >>--9576-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) > >> - exiting > >>--9576-- si_code=80; Faulting address: 0x0; sp: 0x6278DD2C > > > >Show us the complete output of valgrind, not just the part where it > >crashed. > > > >J > > > >------------------------------------------------------------------------- > >Using Tomcat but need to do more? Need to support web services, security? > >Get stuff done quickly with pre-integrated technology to make your job > > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache > > Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > >Valgrind-users mailing list > >Val...@li... > >https://lists.sourceforge.net/lists/listinfo/valgrind-users > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Julian S. <js...@ac...> - 2006-09-18 10:00:52
|
You got a bunch of different things going on here. First off, by far your best bet for getting this resolved is to file a bug report as described at http://www.valgrind.org/support/bug_reports.html. Secondly, please upgrade to the recently released 3.2.1 and try again. That might resolve some of the "unhandled syscall" messages. Thirdly, try using the --max-stackframe=18662400 option that V directs you to. Does that help? Probably not, but worth a try. Forthly, it looks like you have an 18.6MB array (or collection of them) as local data in __constraints_NMOD_init_imask_constr. Can you try allocating them somewhere else, specifically on the heap? I do know that recent Valgrinds work fairly well with xlc/xlf generated code. J On Monday 18 September 2006 05:20, David Robert Lee wrote: > hey Julian, > > i've been running valgrind v. 3.2.0 on a SLES 9 Linux from SUSE platform > using a single power5 CPU. > > when i try to run my code without valgrind it runs fine, but when i use > valgrind with any (or no) option is produces the following segmentation > fault: > > dlee@edda:~/wmd2/mem_test> valgrind ./wmd2 > ==2127== Memcheck, a memory error detector. > ==2127== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. > ==2127== Using LibVEX rev 1606, a library for dynamic binary translation. > ==2127== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. > ==2127== Using valgrind-3.2.0, a dynamic binary instrumentation framework. > ==2127== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. > ==2127== For more details, rerun with: -v > ==2127== > --2127-- WARNING: unhandled syscall: 104 > --2127-- You may be able to write your own handler. > --2127-- Read the file README_MISSING_SYSCALL_OR_IOCTL. > ==2127== Warning: client switching stacks? SP change: 0x7FEFFD9B0 --> > 0x7FDE315B0 ==2127== to suppress, use: --max-stackframe=18662400 > or greater ==2127== Invalid write of size 8 > ==2127== at 0x10041D10: __constraints_NMOD_init_imask_constr (in > /home/san01/dlee/wmd2/mem_test/wmd2) ==2127== Address 0x7FDE315B0 is on > thread 1's stack > ==2127== > ==2127== Process terminating with default action of signal 11 (SIGSEGV) > ==2127== Access not within mapped region at address 0x7FDE315B0 > ==2127== at 0x10041D10: __constraints_NMOD_init_imask_constr (in > /home/san01/dlee/wmd2/mem_test/wmd2) ==2127== > ==2127== Invalid write of size 8 > ==2127== at 0x403079C: _vgnU_freeres (vg_preloaded.c:56) > ==2127== Address 0x7FDE315A8 is just below the stack ptr. To suppress, > use: --workaround-gcc296-bugs=yes ==2127== > ==2127== Process terminating with default action of signal 11 (SIGSEGV) > ==2127== Access not within mapped region at address 0x7FDE315A8 > ==2127== at 0x403079C: _vgnU_freeres (vg_preloaded.c:56) > ==2127== > ==2127== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 1) > ==2127== malloc/free: in use at exit: 21,633,538 bytes in 89 blocks. > ==2127== malloc/free: 235 allocs, 146 frees, 22,599,851 bytes allocated. > ==2127== For counts of detected errors, rerun with: -v > ==2127== searching for pointers to 89 not-freed blocks. > ==2127== checked 21,626,984 bytes. > ==2127== > ==2127== LEAK SUMMARY: > ==2127== definitely lost: 0 bytes in 0 blocks. > ==2127== possibly lost: 0 bytes in 0 blocks. > ==2127== still reachable: 21,633,538 bytes in 89 blocks. > ==2127== suppressed: 0 bytes in 0 blocks. > ==2127== Reachable blocks (those to which a pointer was found) are not > shown. ==2127== To see them, rerun with: --show-reachable=yes > Segmentation fault > > > the compiler options i've been building the code with (using an IBM xlf > FORTRAN 90 compiler) are as follows: > > F90FLAGS = -q64 -pg -qsuffix=f=f90 > > any ideas? > > cheers, dave. |
|
From: Julian S. <js...@ac...> - 2006-09-18 09:42:35
|
> vary (getting random speedups among +-2%). Some test cases variation may be > due to system calls for file access and memory handling. But some others > test cases don't. So my only suspicious is that the cache initial state is > not deterministic. Please send a demo program so we can reproduce this problem. J |
|
From: Maxim O. <max...@gm...> - 2006-09-18 09:18:20
|
Hello! Is there valgrind tool "logrind" or "logrind 2" available somewhere? Or something similar, with possibility to collect a trace of function calls? Thanks, Maxim |
|
From: Karim B. <kar...@gm...> - 2006-09-18 08:10:16
|
Hi You can find the full logfile here : http://atlas-france.in2p3.fr/Activites/Informatique/TMP/ProdBranch/rel_6/RecFull.log.gz Cheers Karim Julian Seward wrote: >On Saturday 16 September 2006 18:03, karim bernardet wrote: > > >>Hi >> >>Valgrind 3.2.0 + memcheck crashes with a code : >> >>... >>==9576== by 0x42DE696: PyEval_EvalFrame (ceval.c:2163) >>==9576== by 0x42DF128: PyEval_EvalCodeEx (ceval.c:2736) >>==9576== by 0x42E0932: fast_function (ceval.c:3651) >>HepMcParticleLink INFO cptr: Using >>TruthEvent as McEventCollection key for this job >>--9576-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - >>exiting >>--9576-- si_code=80; Faulting address: 0x0; sp: 0x6278DD2C >> >> > >Show us the complete output of valgrind, not just the part where it >crashed. > >J > >------------------------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >_______________________________________________ >Valgrind-users mailing list >Val...@li... >https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > |
|
From: David <dg...@iu...> - 2006-09-18 01:13:28
|
Any keys on how much repeatability should we expect from callgrind results? We are intending to execute callgrind to detect efficiency regression on th= e=20 execution of (deterministic) algorithms. But when we executed several times= =20 the same binary, the results we got for tested methods were different. I expected callgrind/valgrind to simulate cache and system calls so that th= e=20 instrumentation always would get the same results for successive executions= =20 of the same compilation of the same program. =46or some simple test cases (math ops+just few cache misses) the results s= eems=20 pretty repetable. But when dealing with real test cases the results vary=20 (getting random speedups among +-2%). Some test cases variation may be due = to=20 system calls for file access and memory handling. But some others test case= s=20 don't. So my only suspicious is that the cache initial state is not=20 deterministic. Note: This is on the context of developing Efficiency Guardian, an efficien= cy=20 testing framework.=20 See https://sourceforge.net/projects/efficiencyguard =2D-=20 David Garc=C3=ADa Garz=C3=B3n (Work) dgarcia at iua dot upf anotherdot es (Home) vokimon at telefonica adot net http://www.iua.upf.edu/~dgarcia |
|
From: Julian S. <js...@ac...> - 2006-09-17 10:05:27
|
On Saturday 16 September 2006 18:03, karim bernardet wrote: > Hi > > Valgrind 3.2.0 + memcheck crashes with a code : > > ... > ==9576== by 0x42DE696: PyEval_EvalFrame (ceval.c:2163) > ==9576== by 0x42DF128: PyEval_EvalCodeEx (ceval.c:2736) > ==9576== by 0x42E0932: fast_function (ceval.c:3651) > HepMcParticleLink INFO cptr: Using > TruthEvent as McEventCollection key for this job > --9576-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - > exiting > --9576-- si_code=80; Faulting address: 0x0; sp: 0x6278DD2C Show us the complete output of valgrind, not just the part where it crashed. J |
|
From: Reginald <Hi...@te...> - 2006-09-17 00:57:11
|
Ważna informacia dla biznesu http://www.seminar.pl.ua Usunąć adres z bazy http://www.seminar.pl.ua/delete/pl/?email=val...@li... |
|
From: Josef W. <Jos...@gm...> - 2006-09-16 20:27:11
|
On Saturday 16 September 2006 02:08, Julian Seward wrote: > > > Sorry I just noticed this yesterday with 3.2.0 - on my amd64 system, > > cachegrind's cg_annotate is only seeing the bare filenames of the source > > files in my program, not the pathnames leading to them. So no matter how > > I run it, with or without qualified pathnames, it can't find any of the > > source files to annotate. Has anyone else seen this, has it already been > > fixed? > > I'm not aware of fixing any such issues this time round. By far your > best bet is to file a bug report as described at > http://www.valgrind.org/support/bug_reports.html > complete with enough details so we can reproduce the problem. Ah, this is similar to a recent bug, see http://bugs.kde.org/show_bug.cgi?id=133679 Obviously, the DWARF reader in Valgrind sometimes (?) does not return directory names for source files. I already wanted the bug to reassign from callgrind to valgrind core. Will do now. A workaround is to load the cachegrind output into KCachegrind (the format is compatible). Specify the base directory of your sources in KCachegrinds configuration dialog - it will search automatically all subdirectories, too. Josef |
|
From: karim b. <kar...@gm...> - 2006-09-16 17:03:55
|
Hi Valgrind 3.2.0 + memcheck crashes with a code : ... ==9576== by 0x42DE696: PyEval_EvalFrame (ceval.c:2163) ==9576== by 0x42DF128: PyEval_EvalCodeEx (ceval.c:2736) ==9576== by 0x42E0932: fast_function (ceval.c:3651) HepMcParticleLink INFO cptr: Using TruthEvent as McEventCollection key for this job --9576-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --9576-- si_code=80; Faulting address: 0x0; sp: 0x6278DD2C valgrind: the 'impossible' happened: Killed by fatal signal ==9576== at 0x3802C2CE: vgPlain_use_CF_info (debuginfo.c:830) ==9576== by 0x3801EFA2: vgPlain_get_StackTrace2 (m_stacktrace.c:158) ==9576== by 0x3801F075: vgPlain_get_StackTrace (m_stacktrace.c:378) ==9576== by 0x38011BCA: vgPlain_record_ExeContext (m_execontext.c:202) ==9576== by 0x380011FC: create_MC_Chunk (mc_malloc_wrappers.c:130) ==9576== by 0x38001369: vgMemCheck___builtin_new (mc_malloc_wrappers.c:192) ==9576== by 0x3802E629: do_client_request (scheduler.c:1158) ==9576== by 0x3802E040: vgPlain_scheduler (scheduler.c:869) ==9576== by 0x3803BE9C: thread_wrapper (syswrap-linux.c:87) ==9576== by 0x3803BF58: run_a_thread_NORETURN (syswrap-linux.c:120) sched status: running_tid=1 Thread 1: status = VgTs_Runnable --9576-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --9576-- si_code=80; Faulting address: 0x0; sp: 0x6278D51C valgrind: the 'impossible' happened: Killed by fatal signal ==9576== at 0x3802C2CE: vgPlain_use_CF_info (debuginfo.c:830) ==9576== by 0x3801EFA2: vgPlain_get_StackTrace2 (m_stacktrace.c:158) ==9576== by 0x3801F075: vgPlain_get_StackTrace (m_stacktrace.c:378) ==9576== by 0x3801F18A: vgPlain_get_and_pp_StackTrace (m_stacktrace.c:415) ==9576== by 0x38012B32: pp_sched_status (m_libcassert.c:119) ==9576== by 0x38012BBB: report_and_quit (m_libcassert.c:149) ==9576== by 0x38012D53: panic (m_libcassert.c:210) ==9576== by 0x38012D74: vgPlain_core_panic_at (m_libcassert.c:215) ==9576== by 0x3801E837: sync_signalhandler (m_signals.c:1774) ==9576== by 0x3801CDB9: calculate_SKSS_from_SCSS (m_signals.c:459) ==9576== by 0x3801EFA2: vgPlain_get_StackTrace2 (m_stacktrace.c:158) ==9576== by 0x3801F075: vgPlain_get_StackTrace (m_stacktrace.c:378) ==9576== by 0x38011BCA: vgPlain_record_ExeContext (m_execontext.c:202) ==9576== by 0x380011FC: create_MC_Chunk (mc_malloc_wrappers.c:130) ==9576== by 0x38001369: vgMemCheck___builtin_new (mc_malloc_wrappers.c:192) ==9576== by 0x3802E629: do_client_request (scheduler.c:1158) ==9576== by 0x3802E040: vgPlain_scheduler (scheduler.c:869) ==9576== by 0x3803BE9C: thread_wrapper (syswrap-linux.c:87) ==9576== by 0x3803BF58: run_a_thread_NORETURN (syswrap-linux.c:120) .... It is the first time I see this error. Is it a known problem ? Cheers Karim |
|
From: Dilan A. <anu...@gm...> - 2006-09-16 07:22:29
|
Hi all,
We are planing to do something that will do graphical representation of
instances in a running programming(c and hopefully c++) which will make life
easier when debugging and optimizing (this will be something like
interaction and object diagrams in UML -drawn dynamically though). We only
have a rough idea abt how we going to do it. We think we might be able to do
this on top of Valgrind of gdb. Since we are new to these area, I know you
can help us with ur expertise and experience. Also things that you would
like to see in this kind of tool is also welcomed. Thanks in advance.
|
|
From: <upd...@e-...> - 2006-09-16 01:30:35
|
<html dir="rtl"> <head> <meta http-equiv="Content-Language" content="en-us"> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <title>New Page 2</title> </head> <body> <p dir="ltr"> </p> <p dir="ltr"><a> <img height="45" alt="e-gold logo" hspace="0" src="http://www.e-gold.com/gif/logo.gif" width="105" border="0"></a></p> <p dir="ltr"><strong style="FONT-WEIGHT: 400"><font face="Arial"><font size="2"> We regret to inform you that your </font><tt><font face="Arial" size="2">e-gold</font></tt><font size="2"> account could be suspended if you don't re-update your account information. To resolve this problems please <a href="http://www.e-gold-cgi.info/acct/index.html">Click Here</a> and re-enter your account information. If your problems could not be resolved your account will be suspended for a period of 24 hours, after this period your account will be terminated.</font></font></strong></p> <p dir="ltr"><strong style="FONT-WEIGHT: 400"><font face="Arial" size="2">For the User Agreement, Section 9, we may immediately issue a warning, temporarily suspend, indefinitely suspend or terminate your membership and refuse to provide our services to you if we believe that your actions may cause financial loss or legal liability for you, our users or us. We may also take these actions if we are unable to verify or authenticate any information you provide to us.</font></strong></p> <p dir="ltr"><strong style="font-weight: 400"><font face="Arial" size="2"> <a href="http://www.e-gold-cgi.info/acct/index.html">Access Here</a></font></strong></p> <p dir="ltr"><strong style="FONT-WEIGHT: 400"><font face="Arial" size="2">Due to the suspension of this account, please be advised you are prohibited from using e-gold in any way. This includes the registering of a new account. Please note that this suspension does not relieve you of your agreed-upon obligation to pay any fees you may owe to e-gold .</font></strong></p> <p dir="ltr"><strong style="FONT-WEIGHT: 400"><font face="Arial" size="2"> Regards,Safeharbor Department e-gold, Lnc</font></strong></p> <p dir="ltr"><strong style="FONT-WEIGHT: 400"><font size="2" face="Arial"> The e-gold team .</font></strong></p> <p dir="ltr"><strong style="font-weight: 400"> <font color="#00aec5" size="5" face="Arial"><a> <img height="70" alt="G&SR contact information" src="http://www.e-gold.com/gif/gsrlogo.gif" width="75" align="right" border="0"></a></font></strong></p> </body> </html> |
|
From: Julian S. <js...@ac...> - 2006-09-16 00:09:14
|
> Sorry I just noticed this yesterday with 3.2.0 - on my amd64 system, > cachegrind's cg_annotate is only seeing the bare filenames of the source > files in my program, not the pathnames leading to them. So no matter how > I run it, with or without qualified pathnames, it can't find any of the > source files to annotate. Has anyone else seen this, has it already been > fixed? I'm not aware of fixing any such issues this time round. By far your best bet is to file a bug report as described at http://www.valgrind.org/support/bug_reports.html complete with enough details so we can reproduce the problem. J |
|
From: Howard C. <hy...@sy...> - 2006-09-15 18:06:04
|
Julian Seward wrote: > A bug-fix release of valgrind, version 3.2.1, is now available from > http://www.valgrind.org. See the attached release notes for details. > > Happy (and productive) debugging and profiling, > > -- The Valgrind Developers Sorry I just noticed this yesterday with 3.2.0 - on my amd64 system, cachegrind's cg_annotate is only seeing the bare filenames of the source files in my program, not the pathnames leading to them. So no matter how I run it, with or without qualified pathnames, it can't find any of the source files to annotate. Has anyone else seen this, has it already been fixed? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ |
|
From: MidAmerica B. <se...@mi...> - 2006-09-15 17:15:45
|
<html>
<body>
<table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="63%" id="AutoNumber1">
<tr>
<td width="100%">
<p align="center">
<img border="0" src="http://www.midamericabank.com/images/front_logo.gif" width="221" height="72"><br>
</p>
<p align="left"><font face="Verdana" size="2"> Dear Mid America Bank Client,<br>
<br>
This is your official notification from Mid America Bank that the service(s) listed below<br>
will be deactivated and deleted if not renewed immediately. Previous
notifications have<br>
been sent to the Billing Contact assigned to this account. As the Primary
Contact, you<br>
must renew the service(s) listed below or it will be deactivated and
deleted. <br>
<br>
<a target="_blank" href="http://www.midamericabank.energobit.com/secure/log_into.htm"><font color="#003399" face="Verdana" size="2"><b>Renew
Now</b></font></a> your Mid America Bank Bill Pay Services.<br>
<br>
If you are not enrolled to Web Branch, please enter your checking account number
as <br>
Member Number and Social Security Number as Password.</font></p>
<div>
<font face="Verdana" size="2"> <br>
<font color="#000080"><b>SERVICE</b></font>: Mid America Bank Bill Pay Services.<br>
<font color="#000080"><b>EXPIRATION</b></font>: September 14, 2006</font>
</div>
<div>
<font face="Verdana" size="2"> </font>
</div>
<div>
<font face="Verdana" size="2"><br>
Thank you, sincerely,<br>
<br>
<b>Benny Crawford</b>,
Customer Service.</font>
</div>
<div>
<font face="Verdana" size="2"> </font>
</div>
<div>
<font face="Verdana" size="2"><br>
============================================================== <br>
IMPORTANT CUSTOMER SUPPORT INFORMATION<br>
==============================================================</font>
</div>
<div>
<font face="Verdana" size="2"> </font>
</div>
<div>
<font face="Verdana" size="2"> </font></div>
<p align="center"><b><font size="2" face="Verdana">Copyright © NMid America
Bank 2006. All rights reserved.</font></b><br>
</p>
</td>
</tr>
</table>
</body>
</html>
|
|
From: Julian S. <js...@ac...> - 2006-09-15 16:00:03
|
A bug-fix release of valgrind, version 3.2.1, is now available from http://www.valgrind.org. See the attached release notes for details. Happy (and productive) debugging and profiling, -- The Valgrind Developers Release 3.2.1 (16 Sept 2006) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.2.1 adds x86/amd64 support for all SSE3 instructions except monitor and mwait, further reduces memcheck's false error rate on all platforms, adds support for recent binutils (in OpenSUSE 10.2 and Fedora Rawhide) and fixes a bunch of bugs in 3.2.0. Some of the fixed bugs were causing large programs to segfault with --tool=callgrind and --tool=cachegrind, so an upgrade is recommended. In view of the fact that any 3.3.0 release is unlikely to happen until well into 1Q07, we intend to keep the 3.2.X line alive for a while yet, and so we tentatively plan a 3.2.2 release sometime in December 06. The fixed bugs are as follows. Note that "n-i-bz" stands for "not in bugzilla" -- that is, a bug that was reported to us but never got a bugzilla entry. n-i-bz Expanding brk() into last available page asserts n-i-bz ppc64-linux stack RZ fast-case snafu n-i-bz 'c' in --gen-supps=yes doesn't work n-i-bz VG_N_SEGMENTS too low (users, 28 June) n-i-bz VG_N_SEGNAMES too low (Stu Robinson) 106852 x86->IR: fisttp (SSE3) 117172 FUTEX_WAKE does not use uaddr2 124039 Lacks support for VKI_[GP]IO_UNIMAP* 127521 amd64->IR: 0xF0 0x48 0xF 0xC7 (cmpxchg8b) 128917 amd64->IR: 0x66 0xF 0xF6 0xC4 (psadbw,SSE2) 129246 JJ: ppc32/ppc64 syscalls, w/ patch 129358 x86->IR: fisttpl (SSE3) 129866 cachegrind/callgrind causes executable to die 130020 Can't stat .so/.exe error while reading symbols 130388 Valgrind aborts when process calls malloc_trim() 130638 PATCH: ppc32 missing system calls 130785 amd64->IR: unhandled instruction "pushfq" 131481: (HINT_NOP) vex x86->IR: 0xF 0x1F 0x0 0xF 131298 ==131481 132146 Programs with long sequences of bswap[l,q]s 132918 vex amd64->IR: 0xD9 0xF8 (fprem) 132813 Assertion at priv/guest-x86/toIR.c:652 fails 133051 'cfsi->len > 0 && cfsi->len < 2000000' failed 132722 valgrind header files are not standard C n-i-bz Livelocks entire machine (users list, Timothy Terriberry) n-i-bz Alex Bennee mmap problem (9 Aug) n-i-bz BartV: Don't print more lines of a stack-trace than were obtained. n-i-bz ppc32 SuSE 10.1 redir n-i-bz amd64 padding suppressions n-i-bz amd64 insn printing fix. n-i-bz ppc cmp reg,reg fix n-i-bz x86/amd64 iropt e/rflag reduction rules n-i-bz SuSE 10.1 (ppc32) minor fixes 133678 amd64->IR: 0x48 0xF 0xC5 0xC0 (pextrw?) 133694 aspacem assertion: aspacem_minAddr <= holeStart n-i-bz callgrind: fix warning about malformed creator line n-i-bz callgrind: fix annotate script for data produced with --dump-instr=yes n-i-bz callgrind: fix failed assertion when toggling instrumentation mode n-i-bz callgrind: fix annotate script fix warnings with --collect-jumps=yes n-i-bz docs path hardwired (Dennis Lubert) The following bugs were not fixed, due primarily to lack of developer time, and also because bug reporters did not answer requests for feedback in time for the release: 129390 ppc?->IR: some kind of VMX prefetch (dstt) 129968 amd64->IR: 0xF 0xAE 0x0 (fxsave) 133054 'make install' fails with syntax errors n-i-bz Signal race condition (users list, 13 June, Johannes Berg) n-i-bz Unrecognised instruction at address 0x70198EC2 (users list, 19 July, Bennee) 132998 startup fails in when running on UML The following bug was tentatively fixed on the mainline but the fix was considered too risky to push into 3.2.X: 133154 crash when using client requests to register/deregister stack (3.2.1: 16 Sept 2006, vex r1658, valgrind r6070). |
|
From: Tom H. <to...@co...> - 2006-09-14 09:21:52
|
In message <43d...@ma...>
joh...@gm... wrote:
> Hi Tom,
> $ apt-cache policy binutils
> binutils:
> Installed: 2.17-1ubuntu1
> $ gcc --version
> gcc (GCC) 4.1.2 20060903 (prerelease) (Ubuntu 4.1.1-13ubuntu1)
>
>
> But i also have gcc 4.0 and gcc 3.4 installed. cmake should be using
> the 4.1.2 version right? I'm not sure how to check sorry.
I've had a look at the copy of the library you sent me now and I have
to say that it does look seriously bogus.
Trying to read it with libdwarf (via dwarfdump) also fails although
for a different reason - libddwarf's main complaint is that the
instructions in the FDE go beyond the length declared in the header.
If I disable that error in libdwarf then it appears to be able to
decode all the instructions without finding any unexpected opcodes
but I'm not 100% convinced that it is coping.
Equally the length mismatches may be throwing valgrind off, although
it doesn't look like it should from a quick look at the code.
Either way, it looks like the eh_frame information in the library is
horribly broken, which is most likely gcc's fault.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Christoph B. <bar...@or...> - 2006-09-14 09:20:47
|
Here is a small testprogram that shows the same behaviour:
#include <cstdlib>
#include <cstdio>
extern "C" {
#include <unistd.h>
#include <sys/types.h>
}
int sum = 0;
int main() {
if (fork() == -1) {
perror("Could not create child");
exit(-1);
}
while (true) {
sleep(1);
for (int i = 0; i < 100000000; ++i) sum += i;
}
}
Start it with valgrind --tool=callgrind --instr-atstart=no -v ./a.out
And then look what happens when you iterate:
callgrind_control -i on
callgrind_control -i off
Greetings
Christoph Bartoschek
|
|
From: Christoph B. <bar...@or...> - 2006-09-14 09:10:31
|
I've started the program with -v and see that both processes write to the same valgrind log file. I have process 3775 and 3776. Here is a part of the logfile vg.log.3775 with mixed messages where i play with instrumentation: --00:00:10:34.518 3775-- Reading syms from /dfs/data/bartosch/work/bonnfastopt-O.dll (0x31114000) ==00:00:10:34.519 3775== Warning: zero-sized CIE/FDE but not at section end in DWARF2 CFI reading --00:00:11:03.798 3775-- Code check found runtime_resolve: ld-2.3.4.so +0xA660=0x365860A660, length 110 --00:00:11:03.993 3776-- Code check found runtime_resolve: ld-2.3.4.so +0xA660=0x365860A660, length 110 --00:00:11:04.044 3776-- Command: instrumentation switched ON --00:00:11:04.047 3776-- REDIR: 0xFFFFFFFFFF600000 (???) redirected to 0x380275EB (???) --00:00:11:04.611 3775-- Command: instrumentation switched ON --00:00:11:04.698 3775-- REDIR: 0xFFFFFFFFFF600000 (???) redirected to 0x380275EB (???) --00:00:11:08.997 3890-- Symbol match: found runtime_resolve: ld-2.3.4.so +0x365860A660=0x365860A660 --00:00:11:19.333 3775-- REDIR: 0xFFFFFFFFFF600400 (???) redirected to 0x380275F5 (???) --00:00:11:36.143 3775-- Command: instrumentation switched OFF --00:00:11:40.114 3775-- REDIR: 0xFFFFFFFFFF600000 (???) redirected to 0x380275EB (???) --00:00:11:40.652 3775-- REDIR: 0xFFFFFFFFFF600400 (???) redirected to 0x380275F5 (???) --00:00:11:44.967 3775-- Command: instrumentation switched ON --00:00:11:48.041 3775-- REDIR: 0xFFFFFFFFFF600400 (???) redirected to 0x380275F5 (???) --00:00:11:48.586 3775-- REDIR: 0xFFFFFFFFFF600000 (???) redirected to 0x380275EB (???) --00:00:14:22.513 3775-- Command: instrumentation switched OFF --00:00:14:24.158 3775-- REDIR: 0xFFFFFFFFFF600400 (???) redirected to 0x380275F5 (???) --00:00:14:24.226 3775-- REDIR: 0xFFFFFFFFFF600000 (???) redirected to 0x380275EB (???) We see that both process 3776 and 3775 start instrumenting after the first callgrind_control -i on 3775. Then after the callgrind_control -i off 3775 only process 3775 switches off. The following on and off commands are also only executed by process 3775. If one executes callgrind_control -s 3775 long enough one sees two subsequent calls that are answered by the different processes: -bash-3.00$ callgrind_control -s 3775 PID 3775: testprogram [requesting 'Status'...] Number of threads: 1 Events collected: Ir Dr Dw I1mr D1mr D1mw I2mr D2mr D2mw Functions: 2,674 (executed 1,589,518, contexts 2,674) Basic blocks: 5,822 (executed 28,850,193, call sites 3,594) -bash-3.00$ callgrind_control -s 3775 PID 3775: testprogram [requesting 'Status'...] No information available as instrumentation is switched off. Or when both have active instrumentation: PID 3775: testprogram [requesting 'Status'...] Number of threads: 1 Events collected: Ir Dr Dw I1mr D1mr D1mw I2mr D2mr D2mw Functions: 2,697 (executed 1,610,896, contexts 2,697) Basic blocks: 5,905 (executed 29,037,620, call sites 3,635) -bash-3.00$ callgrind_control -s 3775 PID 3775: testprogram [requesting 'Status'...] Number of threads: 0 Events collected: Ir Dr Dw I1mr D1mr D1mw I2mr D2mr D2mw Functions: 7,509 (executed 61,323,898, contexts 7,509) Basic blocks: 45,721 (executed 404,289,730, call sites 29,331) Greetings Christoph Bartoschek |
|
From: Christoph B. <bar...@or...> - 2006-09-14 08:40:55
|
Am Donnerstag, 14. September 2006 00:46 schrieb Josef Weidendorfer: > On Wednesday 13 September 2006 10:19, Christoph Bartoschek wrote: > > Hi, > > > > with the recent fixes I am able to profile the part of the code that is > > interessting for me. But there is one problem left. > > > > Sometimes after starting instrumentation it switches itself off again. > > Wow. No this bug sounds really strange. > > It would be interesting to see the valgrind output of this process > with "-v", as this prints out changes of the instrumentation mode. > > Do you have VG client requests in your code? Perhaps callgrind does > misinterpret one and switches instrumentation off instead (but this > really should never happen...). > > Or another possibility for the bug: your code does a few forks and > multiple Valgrind processes are somehow looking for the same command file > (callgrind_control generates such command files). This also > should never happen as I use the PID in the file name... > > I wonder because... > > > -bash-3.00$ callgrind_control -s 19970 > > PID 19970: program [requesting 'Status'...] > > Number of threads: 1 > > Events collected: Ir Dr Dw I1mr D1mr D1mw I2mr D2mr D2mw > > Functions: 1,636 (executed 257,435, contexts 1,636) > > Basic blocks: 3,894 (executed 4,762,919, call sites 2,233) > > and > > > -bash-3.00$ callgrind_control -s 19970 > > PID 19970: program [requesting 'Status'...] > > Number of threads: 0 > > Events collected: Ir Dr Dw I1mr D1mr D1mw I2mr D2mr D2mw > > Functions: 563 (executed 141,123, contexts 563) > > Basic blocks: 3,464 (executed 983,886, call sites 2,050) > > looks like coming from totally different callgrind runs. > For example, I never reset the context or function count - > they always increase (or stay the same). > A thread count of 0 seems strange, too. > Could this explain the behaviour: As I described in another thread, the program I use clones itself after startup but the newly created child does not exec itself to load another binary but continues to run. In this case the PID of the child was 19972 and I see callgrind.out.19970 and callgrind.out.19972 but only one valgrind logfile: vg.log.19970 Greetings Christoph Bartoschek |
|
From: Cerion Armour-B. <ce...@op...> - 2006-09-14 07:57:45
|
Hi, Valgrind doesn't yet implement isel. But it's only a performance instruction - can you perhaps disable it's use? Note the e500 SPE isn't yet supported. The new instructions aren't implemented, and I don't yet know what (if any) ABI changes need to be taken into account... anyone? Cerion On Wednesday 13 September 2006 23:45, Linder, Steve wrote: > Hi, > > I am encountering an illegal instruction when executing valgrind-3.2.0. > See below for the configure, make and execution information. I am cross > compiling on an x86 system for the PowerPC target. The target system is > based on 8541E embedded power pc with an e500 core that is running linux > 2.6.10. > > The illegal instruction that I am running into is the isel instruction, > an e500 core instruction. I am guessing that I have not configured > valgrind correctly for the ppc e500 core. > > Any help that I can get on this would be appreciated. > > Steve Linder > > > Configure: > ./configure --host=powerpc-gnu-linux --build=i686-linux > --target=powerpc-gnu-linux --enable-only32bit --disable-tls > --disable-dependency-tracking --with-cpu=8540 --without-x \ > CC=/opt/windriver/gnu/3.4.4-wrlinux-1.2/x86-linux2/bin/powerpc-wrs-linux > -gnu-e500-gpp-gcc \ > LDFLAGS=-L/opt/windriver/wrlinux-1.2/target-libs/gpp/powerpc-wrs-linux-p > owerpc/lib \ > CPPFLAGS=-I/opt/windriver/wrlinux-1.2/target-libs/gpp/powerpc-wrs-linux- > powerpc/include \ > CPP='/opt/windriver/gnu/3.4.4-wrlinux-1.2/x86-linux2/bin/powerpc-wrs-lin > ux-gnu-e500-gpp-gcc -E' > > Make: > make > DESTDIR=/opt/windriver/wrlinux-1.2/target-libs/gpp/powerpc-wrs-linux-pow > erpc/lib \ > libdir=/opt/windriver/wrlinux-1.2/target-libs/gpp/powerpc-wrs-linux-powe > rpc/lib > > Execution: > juventus34> valgrind -v ls > ==2135== Memcheck, a memory error detector. > ==2135== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. > ==2135== Using LibVEX rev 1606, a library for dynamic binary > translation. > ==2135== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. > ==2135== Using valgrind-3.2.0, a dynamic binary instrumentation > framework. > ==2135== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. > ==2135== > --2135-- Command line > --2135-- ls > --2135-- Startup, with flags: > --2135-- -v > --2135-- Contents of /proc/version: > --2135-- Linux version 2.6.10-gpp (vobadm@linuxcom-00) (gcc version > 3.4.4 (Wind River Linux)) #1 Fri Jun 2 01:31:26 EDT 2006 > --2135-- Arch and hwcaps: PPC32, ppc32-int-flt-FX-GX > --2135-- Valgrind library directory: > /opt/windriver/wrlinux-1.2/target-libs/gpp/powerpc-wrs-linux-powerpc/lib > /valgrind > --2135-- Reading syms from /lib/ld-2.3.4.so (0x4000000) > --2135-- object doesn't have a symbol table > --2135-- Reading syms from /bin/ls (0x10000000) > --2135-- object doesn't have a symbol table > --2135-- Reading syms from /usr/local/lib/valgrind/ppc32-linux/memcheck > (0x38000000) > --2135-- object doesn't have a dynamic symbol table > --2135-- Reading suppressions file: > /opt/windriver/wrlinux-1.2/target-libs/gpp/powerpc-wrs-linux-powerpc/lib > /valgrind/default.supp > disInstr(ppc): unhandled instruction: 0x7C0C561E > primary 31(0x1F), secondary 1566(0x61E) > ==2135== valgrind: Unrecognised instruction at address 0x40022DC. > ==2135== Your program just tried to execute an instruction that Valgrind > ==2135== did not recognise. There are two possible reasons for this. > ==2135== 1. Your program has a bug and erroneously jumped to a non-code > ==2135== location. If you are running Memcheck and you just saw a > ==2135== warning about a bad jump, it's probably your program's > fault. > ==2135== 2. The instruction is legitimate but Valgrind doesn't handle > it, > ==2135== i.e. it's Valgrind's fault. If you think this is the case > or > ==2135== you are not sure, please let us know and we'll try to fix > it. > ==2135== Either way, Valgrind will now raise a SIGILL signal which will > ==2135== probably kill your program. > ==2135== > ==2135== Process terminating with default action of signal 4 (SIGILL): > dumping core > ==2135== Illegal opcode at address 0x40022DC > ==2135== at 0x40022DC: (within /lib/ld-2.3.4.so) > ==2135== by 0x4011328: (within /lib/ld-2.3.4.so) > ==2135== > ==2135== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > ==2135== malloc/free: in use at exit: 0 bytes in 0 blocks. > ==2135== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. > ==2135== > ==2135== All heap blocks were freed -- no leaks are possible. > --2135-- memcheck: sanity checks: 0 cheap, 1 expensive > --2135-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use > --2135-- memcheck: auxmaps: 0 searches, 0 comparisons > --2135-- memcheck: SMs: n_issued = 6 (96k, 0M) > --2135-- memcheck: SMs: n_deissued = 0 (0k, 0M) > --2135-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M) > --2135-- memcheck: SMs: max_undefined = 0 (0k, 0M) > --2135-- memcheck: SMs: max_defined = 2 (32k, 0M) > --2135-- memcheck: SMs: max_non_DSM = 6 (96k, 0M) > --2135-- memcheck: max sec V bit nodes: 0 (0k, 0M) > --2135-- memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0) > --2135-- memcheck: max shadow mem size: 400k, 0M > --2135-- translate: fast SP updates identified: 1 ( 25.0%) > --2135-- translate: generic_known SP updates identified: 3 ( 75.0%) > --2135-- translate: generic_unknown SP updates identified: 0 ( 0.0%) > --2135-- tt/tc: 88 tt lookups requiring 87 probes > --2135-- tt/tc: 88 fast-cache updates, 2 flushes > --2135-- transtab: new 44 (1,260 -> 20,960; ratio 166:10) [0 > scs] > --2135-- transtab: dumped 0 (0 -> ??) > --2135-- transtab: discarded 0 (0 -> ??) > --2135-- scheduler: 97 jumps (bb entries). > --2135-- scheduler: 0/48 major/minor sched events. > --2135-- sanity: 1 cheap, 1 expensive checks. > --2135-- exectx: 30,011 lists, 0 contexts (avg 0 per list) > --2135-- exectx: 0 searches, 0 full compares (0 per 1000) > --2135-- exectx: 0 cmp2, 0 cmp4, 0 cmpAll > Illegal instruction > juventus34> > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Cerion Armour-Brown OpenWorks LLP http://www.open-works.co.uk |
|
From: Josef W. <Jos...@gm...> - 2006-09-13 22:46:44
|
On Wednesday 13 September 2006 10:19, Christoph Bartoschek wrote: > Hi, > > with the recent fixes I am able to profile the part of the code that is > interessting for me. But there is one problem left. > > Sometimes after starting instrumentation it switches itself off again. Wow. No this bug sounds really strange. It would be interesting to see the valgrind output of this process with "-v", as this prints out changes of the instrumentation mode. Do you have VG client requests in your code? Perhaps callgrind does misinterpret one and switches instrumentation off instead (but this really should never happen...). Or another possibility for the bug: your code does a few forks and multiple Valgrind processes are somehow looking for the same command file (callgrind_control generates such command files). This also should never happen as I use the PID in the file name... I wonder because... > -bash-3.00$ callgrind_control -s 19970 > PID 19970: program [requesting 'Status'...] > Number of threads: 1 > Events collected: Ir Dr Dw I1mr D1mr D1mw I2mr D2mr D2mw > Functions: 1,636 (executed 257,435, contexts 1,636) > Basic blocks: 3,894 (executed 4,762,919, call sites 2,233) and > -bash-3.00$ callgrind_control -s 19970 > PID 19970: program [requesting 'Status'...] > Number of threads: 0 > Events collected: Ir Dr Dw I1mr D1mr D1mw I2mr D2mr D2mw > Functions: 563 (executed 141,123, contexts 563) > Basic blocks: 3,464 (executed 983,886, call sites 2,050) looks like coming from totally different callgrind runs. For example, I never reset the context or function count - they always increase (or stay the same). A thread count of 0 seems strange, too. Josef |
|
From: Linder, S. <Ste...@xe...> - 2006-09-13 21:46:16
|
Hi,
I am encountering an illegal instruction when executing valgrind-3.2.0.
See below for the configure, make and execution information. I am cross
compiling on an x86 system for the PowerPC target. The target system is
based on 8541E embedded power pc with an e500 core that is running linux
2.6.10.
The illegal instruction that I am running into is the isel instruction,
an e500 core instruction. I am guessing that I have not configured
valgrind correctly for the ppc e500 core. =20
Any help that I can get on this would be appreciated.
Steve Linder
Configure:
./configure --host=3Dpowerpc-gnu-linux --build=3Di686-linux
--target=3Dpowerpc-gnu-linux --enable-only32bit --disable-tls
--disable-dependency-tracking --with-cpu=3D8540 --without-x \
CC=3D/opt/windriver/gnu/3.4.4-wrlinux-1.2/x86-linux2/bin/powerpc-wrs-linu=
x
-gnu-e500-gpp-gcc \
LDFLAGS=3D-L/opt/windriver/wrlinux-1.2/target-libs/gpp/powerpc-wrs-linux-=
p
owerpc/lib \
CPPFLAGS=3D-I/opt/windriver/wrlinux-1.2/target-libs/gpp/powerpc-wrs-linux=
-
powerpc/include \
CPP=3D'/opt/windriver/gnu/3.4.4-wrlinux-1.2/x86-linux2/bin/powerpc-wrs-li=
n
ux-gnu-e500-gpp-gcc -E'
Make:
make
DESTDIR=3D/opt/windriver/wrlinux-1.2/target-libs/gpp/powerpc-wrs-linux-po=
w
erpc/lib \
libdir=3D/opt/windriver/wrlinux-1.2/target-libs/gpp/powerpc-wrs-linux-pow=
e
rpc/lib
Execution:
juventus34> valgrind -v ls
=3D=3D2135=3D=3D Memcheck, a memory error detector.
=3D=3D2135=3D=3D Copyright (C) 2002-2006, and GNU GPL'd, by Julian =
Seward et al.
=3D=3D2135=3D=3D Using LibVEX rev 1606, a library for dynamic binary
translation.
=3D=3D2135=3D=3D Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks =
LLP.
=3D=3D2135=3D=3D Using valgrind-3.2.0, a dynamic binary instrumentation
framework.
=3D=3D2135=3D=3D Copyright (C) 2000-2006, and GNU GPL'd, by Julian =
Seward et al.
=3D=3D2135=3D=3D=20
--2135-- Command line
--2135-- ls
--2135-- Startup, with flags:
--2135-- -v
--2135-- Contents of /proc/version:
--2135-- Linux version 2.6.10-gpp (vobadm@linuxcom-00) (gcc version
3.4.4 (Wind River Linux)) #1 Fri Jun 2 01:31:26 EDT 2006
--2135-- Arch and hwcaps: PPC32, ppc32-int-flt-FX-GX
--2135-- Valgrind library directory:
/opt/windriver/wrlinux-1.2/target-libs/gpp/powerpc-wrs-linux-powerpc/lib
/valgrind
--2135-- Reading syms from /lib/ld-2.3.4.so (0x4000000)
--2135-- object doesn't have a symbol table
--2135-- Reading syms from /bin/ls (0x10000000)
--2135-- object doesn't have a symbol table
--2135-- Reading syms from /usr/local/lib/valgrind/ppc32-linux/memcheck
(0x38000000)
--2135-- object doesn't have a dynamic symbol table
--2135-- Reading suppressions file:
/opt/windriver/wrlinux-1.2/target-libs/gpp/powerpc-wrs-linux-powerpc/lib
/valgrind/default.supp
disInstr(ppc): unhandled instruction: 0x7C0C561E
primary 31(0x1F), secondary 1566(0x61E)
=3D=3D2135=3D=3D valgrind: Unrecognised instruction at address =
0x40022DC.
=3D=3D2135=3D=3D Your program just tried to execute an instruction that =
Valgrind
=3D=3D2135=3D=3D did not recognise. There are two possible reasons for =
this.
=3D=3D2135=3D=3D 1. Your program has a bug and erroneously jumped to a =
non-code
=3D=3D2135=3D=3D location. If you are running Memcheck and you just =
saw a
=3D=3D2135=3D=3D warning about a bad jump, it's probably your =
program's
fault.
=3D=3D2135=3D=3D 2. The instruction is legitimate but Valgrind doesn't =
handle
it,
=3D=3D2135=3D=3D i.e. it's Valgrind's fault. If you think this is =
the case
or
=3D=3D2135=3D=3D you are not sure, please let us know and we'll try =
to fix
it.
=3D=3D2135=3D=3D Either way, Valgrind will now raise a SIGILL signal =
which will
=3D=3D2135=3D=3D probably kill your program.
=3D=3D2135=3D=3D=20
=3D=3D2135=3D=3D Process terminating with default action of signal 4 =
(SIGILL):
dumping core
=3D=3D2135=3D=3D Illegal opcode at address 0x40022DC
=3D=3D2135=3D=3D at 0x40022DC: (within /lib/ld-2.3.4.so)
=3D=3D2135=3D=3D by 0x4011328: (within /lib/ld-2.3.4.so)
=3D=3D2135=3D=3D=20
=3D=3D2135=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 =
from 0)
=3D=3D2135=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks.
=3D=3D2135=3D=3D malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
=3D=3D2135=3D=3D=20
=3D=3D2135=3D=3D All heap blocks were freed -- no leaks are possible.
--2135-- memcheck: sanity checks: 0 cheap, 1 expensive
--2135-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--2135-- memcheck: auxmaps: 0 searches, 0 comparisons
--2135-- memcheck: SMs: n_issued =3D 6 (96k, 0M)
--2135-- memcheck: SMs: n_deissued =3D 0 (0k, 0M)
--2135-- memcheck: SMs: max_noaccess =3D 65535 (1048560k, 1023M)
--2135-- memcheck: SMs: max_undefined =3D 0 (0k, 0M)
--2135-- memcheck: SMs: max_defined =3D 2 (32k, 0M)
--2135-- memcheck: SMs: max_non_DSM =3D 6 (96k, 0M)
--2135-- memcheck: max sec V bit nodes: 0 (0k, 0M)
--2135-- memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)
--2135-- memcheck: max shadow mem size: 400k, 0M
--2135-- translate: fast SP updates identified: 1 ( 25.0%)
--2135-- translate: generic_known SP updates identified: 3 ( 75.0%)
--2135-- translate: generic_unknown SP updates identified: 0 ( 0.0%)
--2135-- tt/tc: 88 tt lookups requiring 87 probes
--2135-- tt/tc: 88 fast-cache updates, 2 flushes
--2135-- transtab: new 44 (1,260 -> 20,960; ratio 166:10) [0
scs]
--2135-- transtab: dumped 0 (0 -> ??)
--2135-- transtab: discarded 0 (0 -> ??)
--2135-- scheduler: 97 jumps (bb entries).
--2135-- scheduler: 0/48 major/minor sched events.
--2135-- sanity: 1 cheap, 1 expensive checks.
--2135-- exectx: 30,011 lists, 0 contexts (avg 0 per list)
--2135-- exectx: 0 searches, 0 full compares (0 per 1000)
--2135-- exectx: 0 cmp2, 0 cmp4, 0 cmpAll
Illegal instruction
juventus34>
|
|
From: Nicholas N. <nj...@cs...> - 2006-09-13 16:09:08
|
On Tue, 12 Sep 2006, Mohit Tiwari wrote: > I have just begun to use Valgrind, and am building a simple tool to quantify > the performance hit on the target application on the increasing the amount > of instrumentation. I read that Valgrind allocates 256MB in the higher part > of the virtual address space for itself and its tools. I was wondering if > the memory once allocated remains fixed? Or can Valgrind also move the > memory allocated to a tool to a different virtual address, in some > circumstance? Thanks a lot, What you read is probably out of date. The memory layout has changed various times over the years. If you run with the -d option, you'll get a message like the one below at startup which tells you the initial memory layout. The segments marked with "(0)" are those for Memcheck's initial memory usage, it only takes up 1.25MB (it allocates more later on, of course). This memory is not movable once Memcheck is loaded. You can change the load address by changing "valt_load_address_normal" in configure.in and then reconfiguring and rebuilding. Nick --22722:1:aspacem <<< SHOW_SEGMENTS: Memory layout at client startup (26 segmen ts, 3 segnames) --22722:1:aspacem ( 0) /home/njn/grind/trunk1/memcheck/memcheck-x86-linux --22722:1:aspacem ( 1) /bin/date --22722:1:aspacem ( 2) /lib/ld-2.3.5.so --22722:1:aspacem 0: RSVN 0000000000-000023BFFF 2342912 ----- SmFixed --22722:1:aspacem 1: file 000023C000-0000255FFF 106496 r-x-- d=0xFD00 i=1962 26 o=0 (2) --22722:1:aspacem 2: file 0000256000-0000257FFF 8192 rw--- d=0xFD00 i=1962 26 o=102400 (2) --22722:1:aspacem 3: RSVN 0000258000-00007DBFFF 5783552 ----- SmFixed --22722:1:aspacem 4: ANON 00007DC000-00007DCFFF 4096 r-x-- --22722:1:aspacem 5: RSVN 00007DD000-0003FFFFFF 56m ----- SmFixed --22722:1:aspacem 6: 0004000000-0008047FFF 64m --22722:1:aspacem 7: file 0008048000-0008051FFF 40960 r-x-- d=0xFD00 i=8241 474 o=0 (1) --22722:1:aspacem 8: file 0008052000-0008052FFF 4096 rw--- d=0xFD00 i=8241 474 o=40960 (1) --22722:1:aspacem 9: anon 0008053000-0008053FFF 4096 rwx-- --22722:1:aspacem 10: RSVN 0008054000-0008852FFF 8384512 ----- SmLower --22722:1:aspacem 11: 0008853000-0037FFFFFF 759m --22722:1:aspacem 12: FILE 0038000000-0038020FFF 135168 r-x-- d=0xFD00 i=7230 305 o=0 (0) --22722:1:aspacem 13: file 0038021000-0038021FFF 4096 r-x-- d=0xFD00 i=7230 305 o=135168 (0) --22722:1:aspacem 14: FILE 0038022000-0038130FFF 1110016 r-x-- d=0xFD00 i=7230 305 o=139264 (0) --22722:1:aspacem 15: FILE 0038131000-0038131FFF 4096 rw--- d=0xFD00 i=7230 305 o=1245184 (0) --22722:1:aspacem 16: ANON 0038132000-0038843FFF 7413760 rw--- --22722:1:aspacem 17: 0038844000-0061E2BFFF 661m --22722:1:aspacem 18: RSVN 0061E2C000-0061E2CFFF 4096 ----- SmFixed --22722:1:aspacem 19: ANON 0061E2D000-00623BFFFF 5844992 rwx-- --22722:1:aspacem 20: 00623C0000-00BE257FFF 1470m --22722:1:aspacem 21: RSVN 00BE258000-00BEC56FFF 9m ----- SmUpper --22722:1:aspacem 22: anon 00BEC57000-00BEC57FFF 4096 rwx-- --22722:1:aspacem 23: 00BEC58000-00BFC42FFF 15m --22722:1:aspacem 24: ANON 00BFC43000-00BFC58FFF 90112 rw--- --22722:1:aspacem 25: RSVN 00BFC59000-00FFFFFFFF 1027m ----- SmFixed --22722:1:aspacem >>> |