|
From: Julian S. <js...@ac...> - 2004-07-18 11:47:07
|
=46rom the usual place: http://valgrind.kde.org. 2.1.2 contains four months worth of bug fixes and refinements. Although officially a developer release, we believe it to be stable enough for widespread day-to-day use. 2.1.2 is pretty good, so try it first, although there is a chance it won't work. If so then try 2.0.0 and tell us what went wrong. 2.1.2 fixes a lot of problems present in 2.0.0 and is generally a much better product. Relative to 2.1.1, a large number of minor problems have been fixed, and so if you use 2.1.1 you should try 2.1.2. Users of the last=20 stable release, 2.0.0, might also want to try this release. For one thing, 2.1.2 compiles with gcc-3.4.X, whereas 2.0.0 doesn't. The following bugs, and probably many more, have been fixed. These are listed at http://bugs.kde.org. Reporting a bug for valgrind at http://bugs.kde.org is much more likely to get you a fix than=20 mailing developers directly, so please continue to keep sending bugs there. 76869 Crashes when running any tool under Fedora Core 2 test1 This fixes the problem with returning from a signal handler=20 when VDSOs are turned off in FC2. 69508 java 1.4.2 client fails with erroneous "stack size too small". This fix makes more of the pthread stack attribute related=20 functions work properly. Java still doesn't work though. 71906 malloc alignment should be 8, not 4 All memory returned by malloc/new etc is now at least 8-byte aligned. 81970 vg_alloc_ThreadState: no free slots available (closed because the workaround is simple: increase VG_N_THREADS, rebuild and try again.) 78514 Conditional jump or move depends on uninitialized value(s) (a slight mishanding of FP code in memcheck) 77952 pThread Support (crash) (due to initialisation-ordering probs) (also 85118) 80942 Addrcheck wasn't doing overlap checking as it should. 78048 return NULL on malloc/new etc failure, instead of asserting 73655 operator new() override in user .so files often doesn't get picked = up 83060 Valgrind does not handle native kernel AIO 69872 Create proper coredumps after fatal signals 82026 failure with new glibc versions: __libc_* functions are not exported 70344 UNIMPLEMENTED FUNCTION: tcdrain=20 81297 Cancellation of pthread_cond_wait does not require mutex 82872 Using debug info from additional packages (wishlist) 83025 Support for ioctls FIGETBSZ and FIBMAP 83340 Support for ioctl HDIO_GET_IDENTITY 79714 Support for the semtimedop system call. 77022 Support for ioctls FBIOGET_VSCREENINFO and FBIOGET_FSCREENINFO 82098 hp2ps ansification (wishlist) 83573 Valgrind SIGSEGV on execve 82999 show which cmdline option was erroneous (wishlist) 83040 make valgrind VPATH and distcheck-clean (wishlist) 83998 Assertion `newfd > vgPlain_max_fd' failed (see below) 82722 Unchecked mmap in as_pad leads to mysterious failures later 78958 memcheck seg faults while running Mozilla=20 85416 Arguments with colon (e.g. --logsocket) ignored Additionally there are the following changes, which are not=20 connected to any bug report numbers, AFAICS: * Rearranged address space layout relative to 2.1.1, so that Valgrind/tools will run out of memory later than currently in many circumstances. This is good news esp. for Calltree. It should be possible for client programs to allocate over 800MB of memory when using memcheck now. * Improved checking when laying out memory. Should hopefully avoid the random segmentation faults that 2.1.1 sometimes caused. * Support for Fedora Core 2 and SuSE 9.1. Improvements to NPTL support to the extent that V now works properly on NPTL-only setups. * Renamed the following options: --logfile-fd --> --log-fd --logfile --> --log-file --logsocket --> --log-socket to be consistent with each other and other options (esp. --input-fd). * Add support for SIOCGMIIPHY, SIOCGMIIREG and SIOCSMIIREG ioctls and improve the checking of other interface related ioctls. * Fix building with gcc-3.4.1. * Remove limit on number of semaphores supported. * Add support for syscalls: set_tid_address (258), acct (51). * Support instruction "repne movs" -- not official but seems to occur. * Implement an emulated soft limit for file descriptors in addition to the current reserved area, which effectively acts as a hard limit. The setrlimit system call now simply updates the emulated limits as best as possible - the hard limit is not allowed to move at all and just returns EPERM if you try and change it. This should stop reductions in the soft limit causing assertions when valgrind tries to allocate descriptors from the reserved area. (This actually came from bug #83998). * Major overhaul of Cachegrind implementation. Only user visible change is that cachegrind.out files are now typically 90% smaller than they used to be. Code annotation times are correspondingly much smaller. * Client requests for telling valgrind about memory pools. |
|
From: Paul L D. <pld...@pl...> - 2004-07-18 14:38:40
|
So far things are going well here - putting valgrind through its legs here making it retest my ripMIME decoder over about 50,000 email tests.... I'll find out how it went in about 8 hours time. Paul. -- Paul L Daniels - PLD Software - Xamime Unix systems Internet Development A.B.N. 19 500 721 806 ICQ#103642862,AOL:pldsoftware,Yahoo:pldaniels73 PGP Public Key at http://www.pldaniels.com/gpg-keys.pld |
|
From: Alex I. <ale...@in...> - 2004-07-19 00:50:17
|
Julian, I was testing 2.1.2 on RedHat 9 - works great as I can see so far. There is one issue, however - for some reason when there are memory access errors, sometines it prints exact file and line number where it occurred, sometimes just the name of the shared library it occurred in. Below are two entries from the sample output - first one is perfect (pinpoint line number in ExportAim.cc), the second only gives the library name ... Any ideas for me here? Thanks a lot! Alex =14301== Thread 26: ==14301== Conditional jump or move depends on uninitialised value(s) ==14301== at 0x1E26ACC1: ExportAim::ProcessInitialFilters(TpCallRecord const *) (../ExportAim.cc:2464) ==14301== by 0x1E2702D1: ExportAim::AimCallStatus(TpCallRecord const *, unsigned int, TpSignalUnit const *, SignalUnit const *) (../ExportAim.cc:5089) ==14301== by 0x1DE61F9C: TpAlmAttachPoint::DistributeCallStatusToAims(TpCallRecord const *, unsigned int, TpSignalUnit const *, SignalUnit const *) (../TpAlmAttachPoint.cc:306) ==14301== by 0x1DE684EE: TrackingShell::SignalUnitCallProcessorCont(TpAlmAttachPoint *, TpSignalUnit *, SignalUnit const *, TpCallRecord *, short) (../TrackingShell.cc:1189) ==14301== by 0x1DE6963A: TrackingShell::SecondSignalUnitProcessorWrapper(void *, TpSortQueSignalUnit *) (../TrackingShell.cc:1035) ==14301== by 0x1DE642F4: TpSortQueueDelay::TpSortQueueOutputRoutineWrapper(void *) (in /opt/spIprobeApps/v4.5.BETA/cttp/intel-xinu/bin/trackingShell-gprs-intel-xinu.so) ==14301== by 0x1B97ECE8: KEventList::Process(void) (/net/scully/refarea/ref2/NIAinternal/SimProbe/probe/v5.0.4.004/os/src/geoXinu/src/../../libKal/src/xinu/KEvent.cpp:221) ==14301== ==14301== Thread 26: ==14301== Use of uninitialised value of size 4 ==14301== at 0x1E26DC07: ExportAim::ProcessUmtsConnectorFilters(AlcapCallRecord const *, short) const (in /opt/spIprobeApps/v4.5.BETA/cttp/intel-xinu/bin/ExportAim-gprs-intel-xinu.so) ==14301== by 0x1E271013: ExportAim::AimCallTimeout(TpCallRecord const *, unsigned int, int) (../ExportAim.cc:5568) ==14301== by 0x1DE6253C: TpAlmAttachPoint::DistributeTimeoutsToAims(TpCallRecord const *, unsigned int, int) (../TpAlmAttachPoint.cc:702) ==14301== by 0x1DE6272F: TpAlmAttachPoint::TimerExpired(TpCallRecord *, int) (in /opt/spIprobeApps/v4.5.BETA/cttp/intel-xinu/bin/trackingShell-gprs-intel-xinu.so) ==14301== by 0x1DE76546: TimerRecord::TimerExpiredWrapper(void *, StateMachineInstance *) (in /opt/spIprobeApps/v4.5.BETA/cttp/intel-xinu/bin/trackingShell-gprs-intel-xinu.so) ==14301== by 0x1DECBEC1: DeltaTimerList::TimeoutHandlerWrapper(void *) (in /opt/spIprobeApps/v4.5.BETA/cttp/intel-xinu/bin/trackingShell-gprs-intel-xinu.so) ==14301== by 0x1B97ECE8: KEventList::Process(void) (/net/scully/refarea/ref2/NIAinternal/SimProbe/probe/v5.0.4.004/os/src/geoXinu/src/../../libKal/src/xinu/KEvent.cpp:221) Julian Seward wrote: >From the usual place: http://valgrind.kde.org. > >2.1.2 contains four months worth of bug fixes and refinements. >Although officially a developer release, we believe it to be stable >enough for widespread day-to-day use. 2.1.2 is pretty good, so try it >first, although there is a chance it won't work. If so then try 2.0.0 >and tell us what went wrong. 2.1.2 fixes a lot of problems present >in 2.0.0 and is generally a much better product. > >Relative to 2.1.1, a large number of minor problems have been fixed, >and so if you use 2.1.1 you should try 2.1.2. Users of the last >stable release, 2.0.0, might also want to try this release. For >one thing, 2.1.2 compiles with gcc-3.4.X, whereas 2.0.0 doesn't. > >The following bugs, and probably many more, have been fixed. These >are listed at http://bugs.kde.org. Reporting a bug for valgrind at >http://bugs.kde.org is much more likely to get you a fix than >mailing developers directly, so please continue to keep sending bugs >there. > > ------------------------------------------------------------------------ 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. Inet Technologies, Inc. ------------------------------------------------------------------------ |
|
From: Tom H. <th...@cy...> - 2004-07-19 06:13:11
|
In message <40F...@in...>
Alex Ivershen <ale...@in...> wrote:
> I was testing 2.1.2 on RedHat 9 - works great as I can see so far. There
> is one issue, however - for some reason when there are memory access
> errors, sometines it prints exact file and line number where it
> occurred, sometimes just the name of the shared library it occurred in.
> Below are two entries from the sample output - first one is perfect
> (pinpoint line number in ExportAim.cc), the second only gives the
> library name ... Any ideas for me here?
It just means there is no debugging information for that address
in the library - did you forget to compile some file with -g?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-19 08:07:50
|
On Mon, 19 Jul 2004, Tom Hughes wrote: >> Below are two entries from the sample output - first one is perfect >> (pinpoint line number in ExportAim.cc), the second only gives the >> library name ... Any ideas for me here? > > It just means there is no debugging information for that address > in the library - did you forget to compile some file with -g? Yep, see FAQ 4.4. N |