You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(15) |
2
(17) |
3
(23) |
4
(13) |
5
(7) |
6
(8) |
7
(9) |
|
8
(8) |
9
(31) |
10
(31) |
11
(19) |
12
(11) |
13
(38) |
14
(14) |
|
15
(8) |
16
(11) |
17
(7) |
18
(17) |
19
(12) |
20
(12) |
21
(17) |
|
22
(19) |
23
(33) |
24
(42) |
25
(37) |
26
(23) |
27
(27) |
28
(27) |
|
29
(16) |
30
(52) |
31
(33) |
|
|
|
|
|
From: Tom H. <th...@cy...> - 2004-08-26 23:09:33
|
CVS commit by thughes:
When delivering SIGFPE make sure we patch up si_addr in any siginfo
structure to match the address of the instruction in the client program
which caused the fault.
CCMAIL: 881...@bu...
M +3 -0 vg_signals.c 1.81
--- valgrind/coregrind/vg_signals.c #1.80:1.81
@@ -1025,4 +1025,7 @@ void vg_push_signal_frame ( ThreadId tid
(Addr)&frame->sigInfo, sizeof(frame->sigInfo) );
VG_(memcpy)(&frame->sigInfo, siginfo, sizeof(vki_ksiginfo_t));
+ if (sigNo == VKI_SIGFPE) {
+ frame->sigInfo._sifields._sigfault._addr = (void *)tst->m_eip;
+ }
VG_TRACK( post_mem_write, (Addr)&frame->sigInfo, sizeof(frame->sigInfo) );
|
|
From: Jeremy F. <je...@go...> - 2004-08-26 23:08:46
|
On Fri, 2004-08-27 at 08:17 +1000, Paul Mackerras wrote: > I have the same problem on PPC. Some ppc32 kernels let userspace use > 2GB, some 3GB, and ppc64 kernels give 32-bit userspace programs a > whole 4GB. I'm tempted to compile stage2 with -fpic (or -fPIC) and > teach the ume stuff how to do the necessary relocations, so that > stage2 can be loaded at any address. I'd like to avoid even more arch-specific code. Surely there's a small number of useful addresses? Would just pre-generating a series of stage2's at those useful addresses, and then picking the most appropriate work? J |
|
From: Eric E. <eri...@fr...> - 2004-08-26 22:44:28
|
Tom Hughes wrote: >>No, mmap does an implicit munmap on the address range if you use >>MAP_FIXED. > > Yuk. That's horrible. I always thought you got EINVAL if there was > already something mapped at that address. Agreed. But it's working that way, and we can't change it. I just sent an e-mail to ldp manpages maintainer to add that small precision in mmap manpage. Would have saved me some time... >>If you've gone and unmapped something important, like the sysinfo page, >>then I'd expect to see something like this. Indeed, it generally crashed after I had made a fixed mmap on either the ld.so, libc.so or stack ranges ;-) > So read /proc/self/maps first, and only try mapping areas which > aren't already mapped... Probably it's even not needed to read /proc/self/maps. The shm scanning code I posted properly detects already mapped areas, and is likely to work almost unchanged on all unices, and maybe also on ... argh I can't say its name ;-) There is another alternative, if you don't like shm, which would be to iterate reserving very large blocks at unspecified addresses, divide the size by two when it fails, stop when the size is very small. Then see which ranges we were returned, and munmap everything. These strategies are very fast and can be used at runtime. Regards -- Eric |
|
From: Nicholas N. <nj...@ca...> - 2004-08-26 22:22:44
|
On Fri, 27 Aug 2004, Paul Mackerras wrote: >> What's a good way to find the highest user-space address? >> >> One possibility is to look at the address of a stack variable, and round >> up a bit. This is really simple but assumes that the stack is at the top >> of the user-space. > > That is always true on Linux on all the architectures that Valgrind > has been ported to. :) Well, it's almost true, since we might have a > VDSO just above the stack, but it's true to say that we can't mmap > anything at any higher address than the stack. > > I have the same problem on PPC. Some ppc32 kernels let userspace use > 2GB, some 3GB, and ppc64 kernels give 32-bit userspace programs a > whole 4GB. I'm tempted to compile stage2 with -fpic (or -fPIC) and > teach the ume stuff how to do the necessary relocations, so that > stage2 can be loaded at any address. That would be better, but Jeremy is of the opinion that loading PIC is (a) difficult and (b) platform-specific. My patch providing multiple versions of stage2 (which I posted earlier today) is a simple and not-too-bad alternative. N |
|
From: Tom H. <th...@cy...> - 2004-08-26 22:18:51
|
In message <1093557098.3642.3.camel@localhost>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Thu, 2004-08-26 at 22:27 +0200, Eric Estievenart wrote:
> > The issue obviously is that calling the libc mmap
> > segfaults. This is specified in mmap2 manpage,
> > but not in mmap manpage. I do not understand
> > why the libc mmap, which I have always taken for 'safe'
> > is using the mmap2 syscall, which can fault.
> > I guess it's a bug in libc, and will report it if
> > you agree.
>
> No, mmap does an implicit munmap on the address range if you use
> MAP_FIXED.
Yuk. That's horrible. I always thought you got EINVAL if there was
already something mapped at that address.
I see SuS does allow either behaviour, or even that the memory gets
mapped at some other address!
> > I didn't even manage to have a sig handler working
> > when calling a mmap syscalling mmap2, because
> > it seems that the syscall is restarted forever
> > after the handler has been called. Looks like
> > a nasty kernel bug :-P
>
> If you've gone and unmapped something important, like the sysinfo page,
> then I'd expect to see something like this.
So read /proc/self/maps first, and only try mapping areas which
aren't already mapped...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Paul M. <pa...@sa...> - 2004-08-26 22:17:44
|
Nicholas Nethercote writes: > What's a good way to find the highest user-space address? > > One possibility is to look at the address of a stack variable, and round > up a bit. This is really simple but assumes that the stack is at the top > of the user-space. That is always true on Linux on all the architectures that Valgrind has been ported to. :) Well, it's almost true, since we might have a VDSO just above the stack, but it's true to say that we can't mmap anything at any higher address than the stack. I have the same problem on PPC. Some ppc32 kernels let userspace use 2GB, some 3GB, and ppc64 kernels give 32-bit userspace programs a whole 4GB. I'm tempted to compile stage2 with -fpic (or -fPIC) and teach the ume stuff how to do the necessary relocations, so that stage2 can be loaded at any address. Paul. |
|
From: Jeremy F. <je...@go...> - 2004-08-26 21:54:52
|
On Thu, 2004-08-26 at 22:27 +0200, Eric Estievenart wrote: > The issue obviously is that calling the libc mmap > segfaults. This is specified in mmap2 manpage, > but not in mmap manpage. I do not understand > why the libc mmap, which I have always taken for 'safe' > is using the mmap2 syscall, which can fault. > I guess it's a bug in libc, and will report it if > you agree. No, mmap does an implicit munmap on the address range if you use MAP_FIXED. > I didn't even manage to have a sig handler working > when calling a mmap syscalling mmap2, because > it seems that the syscall is restarted forever > after the handler has been called. Looks like > a nasty kernel bug :-P If you've gone and unmapped something important, like the sysinfo page, then I'd expect to see something like this. > Why do you say it trashes the code/data ? mmap should not succeed > if the address range is not available, so we won't call munmap, > so nothing should be trashed ? As above: mmap(MAP_FIXED) trashes any previous mapping. J |
|
From: Eric E. <eri...@fr...> - 2004-08-26 21:10:58
|
Finally got it working :-) Calling old_mmap strangely crashes too on my box, but using shm to scan the memory is ok: 0x00000000: ........U....... 0x10000000: ................ 0x20000000: ................ 0x30000000: ................ 0x40000000: U............... 0x50000000: ................ 0x60000000: ................ 0x70000000: ................ 0x80000000: ................ 0x90000000: ................ 0xa0000000: ................ 0xb0000000: ...............U 0xc0000000: UUUUUUUUUUUUUUUU 0xd0000000: UUUUUUUUUUUUUUUU 0xe0000000: UUUUUUUUUUUUUUUU 0xf0000000: UUUUUUUUUUUUUUUU This effectively reports as unavailable areas which crashed when calling mmap... (Still don't know why) I attached the code which does the scanning; hope it helps. Thanks for the challenge, I feel less idiot tonight ! Cheers -- Eric |
|
From: Eric E. <eri...@fr...> - 2004-08-26 20:27:27
|
Jeremy Fitzhardinge wrote: > I've been thinking about this, but there isn't a good clean way to do > it. The best I can come up with is to scan /proc/self/maps for the > highest address present, then try to create mmaps from there up, and use > a binary search to see how much space is available above the top > mapping. I've had a try at the mmap scanning, splitting the 32bit address space in 256 blocks, and using PROT_READ|PROT_WRITE and MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, which seem legitimate flags for such kind of tests. This is very fast, and could be done systematically at run-time, but... I segfault in mmap(2) at some places. When I skip a few hard-coded addresses, I get a proper overview of memory layout: stack : 0xbffff5ec 0x00000000: SSSSSSSSSSSSSSSS 0x10000000: ................ 0x20000000: ................ 0x30000000: ................ 0x40000000: S............... 0x50000000: ................ 0x60000000: ................ 0x70000000: ................ 0x80000000: ................ 0x90000000: ................ 0xa0000000: ................ 0xb0000000: S..............S 0xc0000000: UUUUUUUUUUUUUUUU 0xd0000000: UUUUUUUUUUUUUUUU 0xe0000000: UUUUUUUUUUUUUUUU 0xf0000000: UUUUUUUUUUUUUUUU stack is an address of a stack variable; S for areas I didn't scan (see later) . for areas available U for areas unavailable (mmap returned -1) The issue obviously is that calling the libc mmap segfaults. This is specified in mmap2 manpage, but not in mmap manpage. I do not understand why the libc mmap, which I have always taken for 'safe' is using the mmap2 syscall, which can fault. I guess it's a bug in libc, and will report it if you agree. I didn't even manage to have a sig handler working when calling a mmap syscalling mmap2, because it seems that the syscall is restarted forever after the handler has been called. Looks like a nasty kernel bug :-P Has someone a clue on that ? This mechanism seems really fast and relevant, except that mmap crashes... I'll have a try using alternate techniques, using: - either directly the old mmap syscall - or trying with shm mappings >>Another possibility is to poke around with mmaps, and see where they stop >>succeeding. Unfortunately, this kind of trashes the code/data that is >>already used in the address space, which gives unpredictable results. Why do you say it trashes the code/data ? mmap should not succeed if the address range is not available, so we won't call munmap, so nothing should be trashed ? > I think this should probably be done in stage1 dynamically rather than > fixed at config-time, since different processes can have different > address-space configurations (and certainly different kernels can). Indeed, I am for doing that at runtime, otherwise it will be a pain for people using a binary distribution and changing their address-space configs. For now it's ok building many stage2 at different addresses, but it doesn't solve the problem of the analysis of the memory layout (which could also greatly help bootstrapping valgrind). -- Eric |
|
From: Eric E. <eri...@fr...> - 2004-08-26 18:54:56
|
Nicholas Nethercote wrote: > It's unlikely to get into 2.2.0; we're in a semi-feature freeze for it. I understand that. I tried to push it just before 2.1.2, but I was in a hurry and the patch was not so clean at that moment, and 2.1.2 was almost released. > As for the other questions... I had a quick look, I didn't see anything > objectionable with the code (eg. formatting). But I haven't had time to > look at it closely. Tom said he didn't like the special --format=valgui > option. I'm not too keen on it either. I'm not very proud of this option name. The problem is that I need one way to now to change a bit the output format, so when the option is not given the output is exactly like before. I asked for other proposals, since I didn't have any other solution looking better (otherwise I would have used it), but nobody seemed to care... > This is a tricky situation -- you've spent a lot of time on Valgui, and > you're really keen for the patch to go in. I can understand that. > > On the other hand, you're asking for a special feature to be added to > Valgrind that serves only one purpose. And it's a feature that involves > a non-trivial amount of code to be added. And we don't have a whole > bunch of people saying "please add this feature so I can use Valgui". > And it requires someone to look at it closely, ahead of a zillion other > proposed bug-fixes, feature requests, etc. Yes the only purpose is to make valgui usable out-of-the-box without asking users to download, patch and install a specific version of V. This would be a waste of time for many users. Most will be able to do it (documented at http://eric.estievenart.free.fr/valgui/doc/html/patches.html), but if it cames as-is for people using binary distributions, this mean less work for users, and less for package maintainers (because they will certainly be asked to include the patch). For now, valgui has not been released yet, so it's normal that nobody asks for the patch to be standard. All the people who had test previews said they would not use anything else than Valgui as an interface for Valgrind, but were bothered to have to patch V. So I assume this would help many users. I would not want to generate extra hassle on Valgrind development by releasing Valgui as-is, and saying in the doc "yes you need to patch, it is painful, I'm sorry, feel free to complain at vg-users/dev @ sf.net. It would be unfair, and I feel it is my responsibility, as-well as to provide a usable high quality initial release of Valgui, to help the future users getting started quickly. That's why I make the request here. That's also on what I worked on my side, making extensive documentation for Valgui, ensuring minimal requirements to compile and install (c++ compiler, make and qt 3.x is enough), fixing many bugs, disabling features not yet ok, and verifying that it works - with all qt versions : 3.0.0 to 3.3.3 are supported - with many g++ : 2.95.2/4 3.3 and 3.4 - with many Valgrind versions : currently patches for 2.0.0, 2.1.1, 2.1.2 and head I can tell you that maintaining the patches for the latter, along with the code which handles subtle differences is a bit a pain, and having a fresh start would relieve me. > So there's a balancing act here. I guess you have to convince at least > one developer that the potential benefit is worth putting some time and > effort into looking at and possibly committing this patch. I think you > may have explained before why this change is necessary -- can you say > again, or point out the previous message? AFAIK, Alleyoop doesn't need > changes to Valgrind's output -- why is Valgui different? Could the > patch be made smaller, less intrusive, or could it be made part of a > more general change? (I know you say "--format=valgui" is general > because other formats could be added in the future, but until that > happens -- and there's no plans to add any -- it's effectively like a > --valgui=yes option.) Ok, I will summarize here the current main benefits of Valgui: * Efficient user interface: - MDI. You can run programs many times, and compare the results - Integrated source editor, opens automatically when you double click on a snippet - You can edit the sources, make, and re-run under valgrind without switching to your IDE, shell or whatever very quickly. - See visually (by coloring) where the errors occur (e.g. red for your code, black for libZZZ, whatever you color you want for /usr/X11/lib/*, etc) - Never asks you to locate a source file, or just once (for all moved files) if you have moved the source tree - filter in one click all the elements you don't want to see (stack addresses, module names, functions, shorten file names, ...) - Permits to view process hierarchy when tracing children, and create separate resultsets for each process. Reports properly process termination and exit codes. * Easy configuration to switch a run with/without debug libraries * Module identification and automatic error classification/filtering based on direct/indirect/other This is one key feature of Valgui, no other product, even commercial, has (AFAIK) (see http://eric.estievenart.free.fr/valgui/doc/kde/errclassif.html for more details, it is a whole documentation chapter) * And a lot more things I have certainly forgotten There will be more in the future. Please feel free to have a look at the documentation. What I hope is that it will be widely used by many users. For the patch, indeed I stripped it a lot, and can't see how I could make it smaller without: - loosing vital informations for valgui - duplicating current code - risking regressions compared to current patch For the --fmt=valgui (yes, it is not --format, but I can change that), I am open to any proposal. For now I see it as a temporary solution, until the logging mechanism in Valgrind can be changed. It does not even need to be documented: Valgui decides internally to use it if Valgrind version seems to support it. For a more general change, I would be happy to do anything in the future, mostly concerning the logging interface, but I think it is completely out-of-plan for 2.2.0. There are also many other things I would be happy to work or help working on. > I don't want to put you off; we certainly do appreciate contributions. > But contributors shouldn't expect their contributions to be used > unconditionally; there has to be some persuasion. Having multiple > people saying "I want this" is the best way -- a similar process works > with bugs. > Sometimes patience is necessary. > > I hope this doesn't seem unreasonable. Indeed you are right, and it is the way things must work. I didn't want to bother you, and knew well that you had many other things to do. I logged a bug (http://bugs.kde.org/show_bug.cgi?id=85050), commented heavily on it, and proposed patches. It is clear that at that time I didn't want to unveil too many things until I felt I was ready for release, in order to continue testing, fixing and documenting without making people loose time by trying valgui if it did not work, reporting bugs I was aware and fixing, and asking questions on things I had not finished documenting. Indeed I have a small pool of testers (4-5); when we agree that the quality is reasonable, I'll make a pre-release announcement here asking for volunteers to test for more. Then, depending on the results, there may be iterations, and ultimately Valgui will be publicly released. If you want, I can ask how many people would want it, but collecting that info will either take me time, or induce extra noise in the MLs. Anyway, if I convinced someone, the latest patch is still at: http://eric.estievenart.free.fr/tmp/vg-head-valgui-24082004-1.diff ;-) Cheers -- Eric |
|
From: Robert W. <rj...@du...> - 2004-08-26 17:22:49
|
Now that we've got FV, I've started removing things from vg_mylibc.c and replacing calls to them with just regular libc calls. Totally experimental - I just want to see how far I can go with this. The patch against the CVS head is at: http://www.durables.org/software/valgrind No regressions on my Fedora Core 2 box so far. If someone could apply the patch and test it on other distros, I'd appreciate it. I'll update the patch as I progress. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@ca...> - 2004-08-26 12:30:23
|
On Thu, 26 Aug 2004, Paul Mackerras wrote: > Are other people able to run OpenOffice successfully under Valgrind at > the moment? I tried it on PPC just now and it bombed out, but then I > tried it on x86 and it bombed out there also, so I conclude it's not a > PPC-specific bug. :) OpenOffice 1.0.2 works ok for me (well, Memcheck finds *lots* of errors :) on my RH9 box. N |
|
From: Tom H. <th...@cy...> - 2004-08-26 12:28:22
|
In message <yek...@au...>
Tom Hughes <th...@cy...> wrote:
> For the record the 1.0.2 build on my RedHat 9 box doesn't fail like
> that - it just issues a number of warnings and then dies with a SEGV.
If I trace system calls, it does seem to be poking about in
valgrind before it dies:
SYSCALL[5266,1](196):lstat64 ( 0xAFEFB620(/tmp), 0xAFEFB560 )
SYSCALL[5266,1](196):lstat64 ( 0xAFEFB620(/tmp/valgrind-debug), 0xAFEFB560 )
SYSCALL[5266,1](196):lstat64 ( 0xAFEFB620(/tmp/valgrind-debug/bin), 0xAFEFB560 )
SYSCALL[5266,1](196):lstat64 ( 0xAFEFB620(/tmp/valgrind-debug/bin/valgrind), 0xAFEFB560 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64144.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64144.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64101.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64101.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64149.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64149.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64133.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64133.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64139.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64139.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64134.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64134.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64131.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64131.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64146.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64146.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64190.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64190.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64199.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64199.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64155.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64155.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64103.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64103.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64148.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64148.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64147.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64147.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64199.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64199.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64147.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64147.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64135.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64135.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64131.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64131.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64145.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64145.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64137.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64137.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64186.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64186.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64188.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64188.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64181.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64181.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64136.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64136.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64142.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64142.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64107.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64107.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64196.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64196.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64130.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64130.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64182.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64182.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/resource/vcl64182.res), 0 )
SYSCALL[5266,1]( 33):access ( 0xAFEFC420(/tmp/valgrind-debug/bin/vcl64182.res), 0 )
==5266==
==5266== Process terminating with default action of signal 11 (SIGSEGV)
==5266== Access not within mapped region at address 0x384
==5266== at 0x3AE86F8A: ResMgr::GetResource(ResId const&, Resource const*) (in /usr/lib/openoffice/program/libtl641li.so)
==5266== by 0x3AE84377: String::String(ResId const&) (in /usr/lib/openoffice/program/libtl641li.so)
==5266== by 0x3AC8816C: Button::GetStandardText(unsigned short) (in /usr/lib/openoffice/program/libvcl641li.so)
==5266== by 0x3AC8B485: OKButton::ImplInit(Window*, unsigned long) (in /usr/lib/openoffice/program/libvcl641li.so)
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-08-26 12:26:40
|
CVS commit by thughes:
Include the filename in the system call trace for the access syscall.
M +1 -1 vg_syscalls.c 1.130
--- valgrind/coregrind/vg_syscalls.c #1.129:1.130
@@ -1839,5 +1839,5 @@ PRE(access)
{
/* int access(const char *pathname, int mode); */
- MAYBE_PRINTF("access ( %p, %d )\n", arg1,arg2);
+ MAYBE_PRINTF("access ( %p(%s), %d )\n", arg1,arg1,arg2);
SYSCALL_TRACK( pre_mem_read_asciiz, tid, "access(pathname)", arg1 );
}
|
|
From: Tom H. <th...@cy...> - 2004-08-26 12:20:39
|
In message <166...@ca...>
Paul Mackerras <pa...@sa...> wrote:
> The command line I am using is:
>
> LD_LIBRARY_PATH=/usr/lib/openoffice/program valgrind --tool=memcheck \
> /usr/lib/openoffice/program/soffice.bin
>
> On x86, it prints an error message like this:
>
> Bootstrap failing: 'Couldn't open registry file:///home/paulus/valgrind/valgrind-x86/coregrind/types.rdb for reading'
>
> followed by several Valgrind errors, then pops up a window saying that
> the program cannot be started, with a button in it, and when you click
> the button it exits.
Well why is it trying to open such a file? I assume it must be doing
something horrible like trying to scan the mapped objects and then
open a registry file for each one which won't work if valgrind has
injected some extra object files...
For the record the 1.0.2 build on my RedHat 9 box doesn't fail like
that - it just issues a number of warnings and then dies with a SEGV.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Paul M. <pa...@sa...> - 2004-08-26 12:08:45
|
Are other people able to run OpenOffice successfully under Valgrind at the moment? I tried it on PPC just now and it bombed out, but then I tried it on x86 and it bombed out there also, so I conclude it's not a PPC-specific bug. :) The command line I am using is: LD_LIBRARY_PATH=/usr/lib/openoffice/program valgrind --tool=memcheck \ /usr/lib/openoffice/program/soffice.bin On x86, it prints an error message like this: Bootstrap failing: 'Couldn't open registry file:///home/paulus/valgrind/valgrind-x86/coregrind/types.rdb for reading' followed by several Valgrind errors, then pops up a window saying that the program cannot be started, with a button in it, and when you click the button it exits. It does the same with --tool=corecheck. If I leave out the "valgrind --tool=memcheck" in the command line it starts up just fine. Paul. |
|
From: Nicholas N. <nj...@ca...> - 2004-08-26 09:39:09
|
On Thu, 26 Aug 2004, Eric Estievenart wrote: > Sorry if I bother you (again), did one of you have a look at > the given patch ? Was something wrong ? > > It is quite important for me, I have worked on that intensively > for the past months. I'm quite near from a pre-release, > and it would really help users if they can get this patch > standard in Valgui in the future. > > Yes, there are a lot more things to do in the future, but I felt it > was reasonable for a 2.2.0. It's unlikely to get into 2.2.0; we're in a semi-feature freeze for it. As for the other questions... I had a quick look, I didn't see anything objectionable with the code (eg. formatting). But I haven't had time to look at it closely. Tom said he didn't like the special --format=valgui option. I'm not too keen on it either. This is a tricky situation -- you've spent a lot of time on Valgui, and you're really keen for the patch to go in. I can understand that. On the other hand, you're asking for a special feature to be added to Valgrind that serves only one purpose. And it's a feature that involves a non-trivial amount of code to be added. And we don't have a whole bunch of people saying "please add this feature so I can use Valgui". And it requires someone to look at it closely, ahead of a zillion other proposed bug-fixes, feature requests, etc. So there's a balancing act here. I guess you have to convince at least one developer that the potential benefit is worth putting some time and effort into looking at and possibly committing this patch. I think you may have explained before why this change is necessary -- can you say again, or point out the previous message? AFAIK, Alleyoop doesn't need changes to Valgrind's output -- why is Valgui different? Could the patch be made smaller, less intrusive, or could it be made part of a more general change? (I know you say "--format=valgui" is general because other formats could be added in the future, but until that happens -- and there's no plans to add any -- it's effectively like a --valgui=yes option.) I don't want to put you off; we certainly do appreciate contributions. But contributors shouldn't expect their contributions to be used unconditionally; there has to be some persuasion. Having multiple people saying "I want this" is the best way -- a similar process works with bugs. Sometimes patience is necessary. I hope this doesn't seem unreasonable. N |
|
From: Tom H. <th...@cy...> - 2004-08-26 03:14:29
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-08-26 03:00:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow error_counts: valgrind --log-fd=-1 ./error_counts errs1: valgrind -q ./errs1 execve: valgrind -q ./execve execve2: valgrind -q --trace-children=yes ./execve2 exitprog: valgrind -q ./exitprog fpeflags: valgrind -q ./fpeflags fprw: valgrind -q ./fprw fwrite: valgrind -q ./fwrite inits: valgrind -q ./inits inline: valgrind -q ./inline insn_basic: valgrind -q ./../../none/tests/insn_basic insn_cmov: valgrind -q ./../../none/tests/insn_cmov insn_fpu: valgrind -q ./../../none/tests/insn_fpu insn_mmx: valgrind -q ./../../none/tests/insn_mmx insn_mmxext: valgrind -q ./../../none/tests/insn_mmxext insn_sse: valgrind -q ./../../none/tests/insn_sse malloc1: valgrind -q ./malloc1 malloc2: valgrind -q ./malloc2 Could not read `malloc2.stderr.exp' make: *** [regtest] Error 2 |
|
From: <js...@ac...> - 2004-08-26 02:56:24
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-08-26 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 174 tests, 4 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-08-26 02:25:19
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-08-26 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 179 tests, 8 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-08-26 02:19:44
|
Nightly build on audi ( Red Hat 9 ) started at 2004-08-26 03:15:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 179 tests, 8 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-08-26 02:13:15
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-08-26 03:10:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 179 tests, 3 stderr failures, 0 stdout failures ================= helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-08-26 02:08:19
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-08-26 03:05:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 179 tests, 14 stderr failures, 1 stdout failure ================= addrcheck/tests/toobig-allocs (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/brk2 (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/mismatches (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/new_override (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/writev (stderr) none/tests/coolo_sigaction (stderr) none/tests/gxx304 (stderr) make: *** [regtest] Error 1 |