[Valgrind-developers] 2008-02-17 03:15:20 GMT nightly build (alvis, i686, Red Hat 7.3)

Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2008-02-17 03:15:20 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ..

[Valgrind-developers] 2008-02-17 03:05:17 GMT nightly build (lloyd, x86_64, Fedora 7)

Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2008-02-17 03:05:17 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ...

[Valgrind-developers] 2008-02-17 03:20:07 GMT nightly build (aston, x86_64, Fedora Core 5)

Nightly build on aston ( x86_64, Fedora Core 5 ) started at 2008-02-17 03:20:07 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests

[Valgrind-developers] 2008-02-17 03:25:15 GMT nightly build (trojan, x86_64, Fedora Core 6)

Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2008-02-17 03:25:15 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests

[Valgrind-developers] 2008-02-17 03:10:03 GMT nightly build (dellow, x86_64, Fedora 8)

Nightly build on dellow ( x86_64, Fedora 8 ) started at 2008-02-17 03:10:03 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... f

[Valgrind-developers] 2008-02-17 03:00:05 GMT nightly build (gill, x86_64, Fedora Core 2)

Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2008-02-17 03:00:05 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests

[Valgrind-developers] valgrind: r7415 - in branches/DATASYMS: coregrind include

Author: sewardj Date: 2008-02-17 00:25:49 + (Sun, 17 Feb 2008) New Revision: 7415 Log: Add a new method, VG_(cloneXA), which clones an existing XArray. Modified: branches/DATASYMS/coregrind/m_xarray.c branches/DATASYMS/include/pub_tool_xarray.h Modified: branches/DATASYMS/coregrind/m

[Valgrind-developers] valgrind: r7416 - branches/DATASYMS/coregrind/m_debuginfo

Author: sewardj Date: 2008-02-17 00:30:12 + (Sun, 17 Feb 2008) New Revision: 7416 Log: More tidying up in Dwarf3 variable reading: * m_debuginfo.c: more all variable-related stuff further down the file * m_storage.c: deal properly with code address ranges for variables, in which the addr

[Valgrind-developers] valgrind: r7414 - in branches/DATASYMS: coregrind include

Author: sewardj Date: 2008-02-17 00:24:22 + (Sun, 17 Feb 2008) New Revision: 7414 Log: * change the default ordering unboxed order from signed word (Word) to unsigned word (UWord) * change some size-of-the-OSet measures from Int to Word * add a method VG_(OSetGen_ResetIterAt) to start the

Re: [Valgrind-developers] processes and threads

On Sat, 16 Feb 2008, Markus Schiltknecht wrote: > Aha, so the valgrind's internal "scheduler" doesn't do the deciding, but > just blocks threads appropriately, right? However, properly blocking, > you could override the kernel's decisions, in a way. I guess so. > But after a fork, do the two pro

Re: [Valgrind-developers] processes and threads

On Feb 16, 2008 1:40 PM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote: > I think those don't serve my needs. First of all, I'm fiddling with > multiple processes, not multiple threads. Second, I'm not after race > conditions on shared memory access, which can be detected automatically. > But I wan

Re: [Valgrind-developers] processes and threads

Hello Julian, Julian Seward wrote: > Indeed; it seems a bit pointless to mess with the scheduler. In > any case it does not control the order in which threads run -- > the kernel does that. It only really ensures that one thread > runs at any one time. Aha, so the valgrind's internal "scheduler

Re: [Valgrind-developers] processes and threads

On Saturday 16 February 2008 11:43, Bart Van Assche wrote: > On Feb 16, 2008 10:35 AM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote: > > I would like to simulate the scheduler, or even influence it, to be able > > to reproducibly test execution of concurrent code. Because as commodity > > hardware

Re: [Valgrind-developers] processes and threads

Hello Bart, Bart Van Assche wrote: > This makes me wonder why you would like to do this ? Is it because you > want to be able to debug race conditions in concurrent code ? In that > case, please have a look at the exp-drd project -- this might be what > you are looking for. Thanks, I've taken a l

Re: [Valgrind-developers] processes and threads

On Feb 16, 2008 10:35 AM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote: > I would like to simulate the scheduler, or even influence it, to be able > to reproducibly test execution of concurrent code. Because as commodity > hardware gets more and more CPU cores, multi-threaded code will get more >

Re: [Valgrind-developers] adding -Wsign-compare AM_CFLAGS_BASE

On Feb 15, 2008 11:58 PM, Julian Seward <[EMAIL PROTECTED]> wrote: > > Does anybody have any experience with the desirability/usefulness > of -Wsign-compare? I have been using -Wsign-compare before in a large project. The warnings resulting from this option are usually easy to fix and the risk of

[Valgrind-developers] processes and threads

Hello valgrind developers, I've been studying the source code of valgrind to figure out how it deals with processes and threads. And I'd like to make sure my understanding is correct. From the system call wrappers, I conclude that a fork() (or rather clone) is passed down to the kernel, so th