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
(11) |
2
(8) |
|
3
(8) |
4
(8) |
5
(8) |
6
(19) |
7
(17) |
8
(12) |
9
(10) |
|
10
(15) |
11
(18) |
12
(14) |
13
(16) |
14
(24) |
15
(16) |
16
(12) |
|
17
(25) |
18
(23) |
19
(12) |
20
(10) |
21
(9) |
22
(12) |
23
(13) |
|
24
(19) |
25
(7) |
26
(39) |
27
(22) |
28
(22) |
29
(16) |
30
(13) |
|
31
(23) |
|
|
|
|
|
|
|
From: Nicholas N. <nj...@cs...> - 2006-12-10 22:30:30
|
On Sun, 10 Dec 2006, Julian Seward wrote:
> This could be an OSet (an AVL tree-based, generic, searchable structure)
> (see pub_{core,tool}_oset.h) of 'struct DrdThreadInfo', which can be searched
> in O(log N) time for some specified field (ThreadId, maybe?).
You could also use the VgHashTable type, which is similar to OSet but faster
in some circumstances. (You'll have to experiment to see which is better,
there's no straightforward comparison between the two data structures.)
N
|
|
From: Julian S. <js...@ac...> - 2006-12-10 19:37:01
|
> How do I make the pthread_t datatype available to the drd tool ? Is it > allowed to include header-files like <pthread.h> directly from a tool > source file ? Or should I introduce a typedef in the drd tool, which > might cause trouble when porting drd to other OS's than Linux ? Good question. So far we've avoided system header files as much as possible because of stability problems earlier in V's life. I suggest a fairly safe kludge is to assume that pthread_t is a machine word (C unsigned long, or 'UWord' in V's type system) and then add a configure test to check that. We can generalise later if needed. Bear in mind also that you can only pass word-sized parameters as arguments of client requests, so equating pthread_t with UWord is helpful there too. I'll write the relevant configure test if you want. J |
|
From: Bart V. A. <bar...@gm...> - 2006-12-10 19:12:07
|
> > [ Bart ] > > - Define a new thread ID internal in the drd tool, e.g. DrdThreadId. > > - Every time Valgrind's core triggers a tracking function, it will > > reference to a thread via its ThreadId. Convert this into a > > DrdThreadId in the drd tool (*). > > - Function wrappers in drd_preloaded.so will reference to a thread via > > its pthread_t ID. Convert this into a DrdThreadId before issuing a > > client request from any of the wrappers. > > [ Julian ] > It would be faster to for the wrappers to specify the pthread_t ID in > the client request. Drd can then do the conversion on the real CPU rather > than the wrapper having to arrange to do the conversion (and associated > locking) on the simulated CPU. How do I make the pthread_t datatype available to the drd tool ? Is it allowed to include header-files like <pthread.h> directly from a tool source file ? Or should I introduce a typedef in the drd tool, which might cause trouble when porting drd to other OS's than Linux ? Bart. |
|
From: Julian S. <js...@ac...> - 2006-12-10 19:01:27
|
> Thanks for reporting this -- by this time I have fixed this, and the > drd tool now reports on each run the same set of data races, > independent of (Valgrind's) thread scheduling activity. Ok good. I wasn't sure if it was a bug; it just looked a bit strange to me. J |
|
From: Julian S. <js...@ac...> - 2006-12-10 19:00:51
|
On Sunday 10 December 2006 16:44, Bart Van Assche wrote:
> On 12/9/06, Julian Seward <js...@ac...> wrote:
> > > - Data-race analysis for regular POSIX threads (non-detached POSIX
> > > threads) can only be performed once pthread_join() finished.
> >
> > Can you clarify what this means? I thought that as soon as a
> > segment is finished, it can be checked against all other finished
> > segments which are unordered relative to it.
>
> That's correct. But please keep in mind that the segments of a
> finished thread are unordered to the segments of the thread that
> created it as long as that creating thread did not call
> pthread_join().
Ok. So pthread_join is really a sync event between the joiner and
joinee threads.
> By the way, I overlooked something: in the current patch thread
> information for detached threads is discarded as soon as the detached
> thread finishes. This is wrong: the bitmap information for a detached
> thread must be kept until program exit.
Surely all the segment info for a detached and terminated thread can be
discarded as soon as the VCs for all other threads are > than its final VC ?
> Maybe it's possible as follows to manage thread information in drd,
> but this will complicate the drd tool somewhat:
I think it would make drd stronger and easier to understand, though.
Part of this whole business is to figure out how to keep the core/tool
interface as simple as possible.
> - make the number of threads for which information is managed in the
> drd tool independent of the maximum number of Valgrind threads (e.g.
> the double).
(see next point) OSets are dynamically sized; no problem there.
> - For each thread, let drd keep the following information up to date:
> * Whether the thread is still running (as viewed by Valgrind and the OS
> kernel). * POSIX thread detach state: joinable or detached.
> * Valgrind thread ID (ThreadId) if the thread is still running.
> * POSIX thread ID (pthread_t). Note: for detached threads that already
> finished, this will be a stale POSIX threads ID.
> * Thread name, because the thread name must be available to drd even
> after Valgrind emptied a thread state record.
This could be an OSet (an AVL tree-based, generic, searchable structure)
(see pub_{core,tool}_oset.h) of 'struct DrdThreadInfo', which can be searched
in O(log N) time for some specified field (ThreadId, maybe?).
Or two OSets, one for alive threads which still have a valid ThreadId,
indexed by ThreadId, and one for dead threads which we still need to
keep info about, perhaps indexed by DrdThreadId.
> - Define a new thread ID internal in the drd tool, e.g. DrdThreadId.
> - Every time Valgrind's core triggers a tracking function, it will
> reference to a thread via its ThreadId. Convert this into a
> DrdThreadId in the drd tool (*).
> - Function wrappers in drd_preloaded.so will reference to a thread via
> its pthread_t ID. Convert this into a DrdThreadId before issuing a
> client request from any of the wrappers.
It would be faster to for the wrappers to specify the pthread_t ID in
the client request. Drd can then do the conversion on the real CPU rather
than the wrapper having to arrange to do the conversion (and associated
locking) on the simulated CPU.
> In order to limit the performance hit on loads and stores the
> conversion (*) would have to be cached. Is my understanding of
> VG_(track_thread_run)() correct that it allows a tool to register a
> tracking function that is called by the core every time the core
> schedules another thread ?
Either that is already true, or we should make it true, because it
would as you say make (*) cacheable and hence effectively make its
cost zero for loads and stores.
J
|
|
From: Bart V. A. <bar...@gm...> - 2006-12-10 16:46:49
|
On 12/9/06, Julian Seward <js...@ac...> wrote: > When inspecting drd code before I think I saw what might be a bug. > From memory: Suppose thread T1 releases a lock L and some time later > thread T2 acquires L. I think what drd does when T2 gets the lock > is to set T2's vector clock to union(T2's current vector clock, T1's > current vector clock). This seemed wrong to me -- shouldn't it use the > vector clock from T1 at the point T1 released the lock? In other words, > shouldn't locks have an associated vector clock saying when they were > most recently unlocked? Thanks for reporting this -- by this time I have fixed this, and the drd tool now reports on each run the same set of data races, independent of (Valgrind's) thread scheduling activity. Bart. |
|
From: Bart V. A. <bar...@gm...> - 2006-12-10 16:44:05
|
On 12/9/06, Julian Seward <js...@ac...> wrote: > > - Data-race analysis for regular POSIX threads (non-detached POSIX > > threads) can only be performed once pthread_join() finished. > > Can you clarify what this means? I thought that as soon as a > segment is finished, it can be checked against all other finished > segments which are unordered relative to it. That's correct. But please keep in mind that the segments of a finished thread are unordered to the segments of the thread that created it as long as that creating thread did not call pthread_join(). This can even apply to segments in the creating thread that were added *after* the created thread finished. By the way, I overlooked something: in the current patch thread information for detached threads is discarded as soon as the detached thread finishes. This is wrong: the bitmap information for a detached thread must be kept until program exit. Maybe it's possible as follows to manage thread information in drd, but this will complicate the drd tool somewhat: - make the number of threads for which information is managed in the drd tool independent of the maximum number of Valgrind threads (e.g. the double). - For each thread, let drd keep the following information up to date: * Whether the thread is still running (as viewed by Valgrind and the OS kernel). * POSIX thread detach state: joinable or detached. * Valgrind thread ID (ThreadId) if the thread is still running. * POSIX thread ID (pthread_t). Note: for detached threads that already finished, this will be a stale POSIX threads ID. * Thread name, because the thread name must be available to drd even after Valgrind emptied a thread state record. - Define a new thread ID internal in the drd tool, e.g. DrdThreadId. - Every time Valgrind's core triggers a tracking function, it will reference to a thread via its ThreadId. Convert this into a DrdThreadId in the drd tool (*). - Function wrappers in drd_preloaded.so will reference to a thread via its pthread_t ID. Convert this into a DrdThreadId before issuing a client request from any of the wrappers. In order to limit the performance hit on loads and stores the conversion (*) would have to be cached. Is my understanding of VG_(track_thread_run)() correct that it allows a tool to register a tracking function that is called by the core every time the core schedules another thread ? Bart. |
|
From: Nicholas N. <nj...@cs...> - 2006-12-10 06:07:37
|
On Sat, 9 Dec 2006, Bart Van Assche wrote:
> As promised I have reworked the integration of drd into Valgrind such
> that the number of core changes is now minimal.
>
> A few comments on the remaining core changes (for the location of the
> patch, see below):
> - I have removed all tracking functions from the interface between the
> core and the tools that were never called by the core
> (track_post_thread_join and the mutex-related tracking functions).
That's good.
> - The following infrastructure has been added for tracking detached
> POSIX threads:
> * A new boolean state has been added to ThreadState, called joinable.
> Its default value is false, but this value can be changed from the
> client via a client request.
> * One new tracking function has been added:
> track_detached_thread_finished. This tracking function is called after
> a client thread finished.
> - Data-race analysis for regular POSIX threads (non-detached POSIX
> threads) can only be performed once pthread_join() finished. I had to
> modify the thread state machine in order to avoid that the core reuses
> thread ID's after a client thread finishes and before pthread_join()
> finished. This works as follows:
> * drd ensures that joinable threads finish with ThreadState::joinable == true.
> * the thread state machine in the core has been modified such that if
> a thread finishes with ThreadState::joinable == true, then the
> transition of the thread state from VgTs_Zombie into VgTs_empty is
> deferred until the client triggers a call to the new function
> VG_(join_thread). All this last function does is changing the thread
> state into VgTs_Empty.
All this stuff is in part of the system I don't understand, but it makes me
nervous, just because any changes to the threading stuff make me nervous :)
Also, the track_detached_thread_finished seems a bit specific... is there
some more general-purpose event that could replace it?
In the patch we have this:
Index: coregrind/m_threadstate.c
===================================================================
--- coregrind/m_threadstate.c (revision 6386)
+++ coregrind/m_threadstate.c (working copy)
@@ -32,6 +32,9 @@
#include "pub_core_vki.h"
#include "pub_core_threadstate.h"
#include "pub_core_libcassert.h"
+#include "pub_core_libcbase.h"
+#include "pub_core_libcprint.h"
+#include "pub_core_tooliface.h" // VG_TRACK()
Are those #includes necessary? It doesn't look like they are, and
m_threadstate.c preferably shouldn't depend on those other modules.
> - One non-essential but nice-to-have feature I added is that clients
> can now associate a name with each thread. I already use this thread
> name instead of the thread number for drd's error reporting (client
> request VG_USERREQ__SET_THREAD_NAME, core functions
> VG_(get_thread_name) and VG_(set_thread_name)). Maybe it is a good
> idea to let memcheck also print these thread names in its error
> reports.
Seems reasonable.
The removal of threadmodel/pthreadmodel looks fine to me, I'm happy to do
that now if Julian agrees.
Nick
|
|
From: <js...@ac...> - 2006-12-10 05:03:18
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-12-10 04:30:01 GMT Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 250 tests, 9 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/blockfault (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: <js...@ac...> - 2006-12-10 04:37:29
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-12-10 09:00:01 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 215 tests, 12 stderr failures, 7 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/blockfault (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/jm-int (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Tom H. <to...@co...> - 2006-12-10 03:53:30
|
Nightly build on dunsmere ( athlon, Fedora Core 6 ) started at 2006-12-10 03:30:07 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 252 tests, 8 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/blockfault (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) |
|
From: <sv...@va...> - 2006-12-10 02:59:18
|
Author: sewardj Date: 2006-12-10 02:59:16 +0000 (Sun, 10 Dec 2006) New Revision: 6389 Log: Fix 'make html-docs' and 'make print-docs'. Modified: trunk/cachegrind/docs/cg-manual.xml trunk/docs/xml/manual-writing-tools.xml trunk/docs/xml/tech-docs.xml Modified: trunk/cachegrind/docs/cg-manual.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/cachegrind/docs/cg-manual.xml 2006-12-10 02:58:27 UTC (rev 6388= ) +++ trunk/cachegrind/docs/cg-manual.xml 2006-12-10 02:59:16 UTC (rev 6389= ) @@ -1,6 +1,7 @@ <?xml version=3D"1.0"?> <!-- -*- sgml -*- --> <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" - "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[ <!ENTITY % vg-entities SYSTEM "../../docs/xml/vg-entities.xml"> %vg-en= tities; ]> =20 =20 <chapter id=3D"cg-manual" xreflabel=3D"Cachegrind: a cache-miss profiler= "> Modified: trunk/docs/xml/manual-writing-tools.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/xml/manual-writing-tools.xml 2006-12-10 02:58:27 UTC (rev = 6388) +++ trunk/docs/xml/manual-writing-tools.xml 2006-12-10 02:59:16 UTC (rev = 6389) @@ -198,7 +198,7 @@ <computeroutput>VG_DETERMINE_INTERFACE_VERSION</computeroutput> (which a= lso checks that the core/tool interface of the tool matches that of the core= ). The last three are registered using the -<computeroutput>VG_(basic_tool_funcs)</computeroutput> function. +<computeroutput>VG_(basic_tool_funcs)</computeroutput> function.</para> =20 <para>In addition, if a tool wants to use some of the optional services provided by the core, it may have to define other functions and tell the Modified: trunk/docs/xml/tech-docs.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/xml/tech-docs.xml 2006-12-10 02:58:27 UTC (rev 6388) +++ trunk/docs/xml/tech-docs.xml 2006-12-10 02:59:16 UTC (rev 6389) @@ -21,7 +21,7 @@ xmlns:xi=3D"http://www.w3.org/2001/XInclude" /> <xi:include href=3D"../../callgrind/docs/cl-format.xml" parse=3D"xml" = =20 xmlns:xi=3D"http://www.w3.org/2001/XInclude" /> - <xi:include href=3D"writing-tools.xml" parse=3D"xml" =20 + <xi:include href=3D"manual-writing-tools.xml" parse=3D"xml" =20 xmlns:xi=3D"http://www.w3.org/2001/XInclude" /> =20 </book> |
|
From: <sv...@va...> - 2006-12-10 02:58:30
|
Author: sewardj Date: 2006-12-10 02:58:27 +0000 (Sun, 10 Dec 2006) New Revision: 6388 Log: Update. Modified: trunk/docs/README Modified: trunk/docs/README =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/README 2006-12-10 02:26:50 UTC (rev 6387) +++ trunk/docs/README 2006-12-10 02:58:27 UTC (rev 6388) @@ -119,7 +119,16 @@ in recent distros. =20 =20 +Notes [Dec. 2006] +----------------- +pdfxmltex still bombs when building the print docs. On SuSE 10.1 I +edited /etc/texmf/web2c/texmf.cnf and changed + pool_size.pdfxmltex =3D 500000 +to + pool_size.pdfxmltex =3D 1500000 +and that fixes it. =20 + Notes [Nov. 2005] ----------------- After upgrading to Suse 10, found a (known) bug in PassiveTex which=20 |
|
From: <sv...@va...> - 2006-12-10 02:26:55
|
Author: sewardj Date: 2006-12-10 02:26:50 +0000 (Sun, 10 Dec 2006) New Revision: 6387 Log: Fix installation of libmpiwrap.so on the primary platform. Modified: trunk/auxprogs/Makefile.am Modified: trunk/auxprogs/Makefile.am =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/auxprogs/Makefile.am 2006-12-08 21:29:46 UTC (rev 6386) +++ trunk/auxprogs/Makefile.am 2006-12-10 02:26:50 UTC (rev 6387) @@ -87,7 +87,7 @@ # convert (eg) X86_LINUX to x86-linux # really should use sed here, rather than assume tr is available pD=3D`echo @VG_PLATFORM_PRI@ | tr A-Z_ a-z-` ; \ - $(mkinstalldirs) $(DESTDIR)$(valdir)/$$pD; + $(mkinstalldirs) $(DESTDIR)$(valdir)/$$pD; \ rm -f ./libmpiwrap.so; \ cp ./libmpiwrap-@VG_PLATFORM_PRI@.so ./libmpiwrap.so; \ $(INSTALL_PROGRAM) ./libmpiwrap.so \ |
|
From: <js...@ac...> - 2006-12-10 01:16:37
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2006-12-10 02:00:01 CET Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 221 tests, 14 stderr failures, 4 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) none/tests/blockfault (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-int (stdout) none/tests/ppc64/jm-int (stdout) |