Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [patch] Fix for PR gdb/10838
@ 2009-11-12  0:35 Paul Pluzhnikov
  2009-11-12  0:43 ` Daniel Jacobowitz
  0 siblings, 1 reply; 10+ messages in thread
From: Paul Pluzhnikov @ 2009-11-12  0:35 UTC (permalink / raw)
  To: gdb-patches; +Cc: ppluzhnikov

Greetings,

In http://sourceware.org/bugzilla/show_bug.cgi?id=10838
gdb attach; detach; attach sequence leaves libpthread in hosed state.

The root cause turned out to be that this:

      td_event_emptyset (&events);
      info->td_ta_set_event_p (info->thread_agent, &events);

is a no-op -- glibc ORs new event bits in, but doesn't clear any already
set bits. To clear them, one must call td_ta_clear_event() instead.

Here is a patch which fixes this in gdb and gdbserver.

Tested (GDB only) on Linux/x86_64 with no regressions.

Thanks,
--
Paul Pluzhnikov

gdb/ChangeLog:

2009-11-11  Paul Pluzhnikov  <ppluzhnikov@google.com>

	PR gdb/10838
	* linux-thread-db.c (thread_db_info): New member.
	(disable_thread_event_reporting): Call td_ta_clear_event.

gdbserver/ChangeLog:

2009-11-11  Paul Pluzhnikov  <ppluzhnikov@google.com>

	PR gdb/10838
	* thread-db.c (thread_db_free): Call td_ta_clear_event.

Index: linux-thread-db.c
===================================================================
RCS file: /cvs/src/src/gdb/linux-thread-db.c,v
retrieving revision 1.67
diff -u -p -u -r1.67 linux-thread-db.c
--- linux-thread-db.c	3 Nov 2009 17:14:56 -0000	1.67
+++ linux-thread-db.c	12 Nov 2009 00:21:02 -0000
@@ -141,6 +141,8 @@ struct thread_db_info
 				  td_event_e event, td_notify_t *ptr);
   td_err_e (*td_ta_set_event_p) (const td_thragent_t *ta,
 				 td_thr_events_t *event);
+  td_err_e (*td_ta_clear_event_p) (const td_thragent_t *ta,
+				   td_thr_events_t *event);
   td_err_e (*td_ta_event_getmsg_p) (const td_thragent_t *ta,
 				    td_event_msg_t *msg);
 
@@ -701,6 +703,7 @@ try_thread_db_load_1 (struct thread_db_i
   /* These are not essential.  */
   info->td_ta_event_addr_p = dlsym (info->handle, "td_ta_event_addr");
   info->td_ta_set_event_p = dlsym (info->handle, "td_ta_set_event");
+  info->td_ta_clear_event_p = dlsym (info->handle, "td_ta_clear_event");
   info->td_ta_event_getmsg_p = dlsym (info->handle, "td_ta_event_getmsg");
   info->td_thr_event_enable_p = dlsym (info->handle, "td_thr_event_enable");
   info->td_thr_tls_get_addr_p = dlsym (info->handle, "td_thr_tls_get_addr");
@@ -907,14 +910,14 @@ thread_db_load (void)
 static void
 disable_thread_event_reporting (struct thread_db_info *info)
 {
-  if (info->td_ta_set_event_p != NULL)
+  if (info->td_ta_clear_event_p != NULL)
     {
       td_thr_events_t events;
 
       /* Set the process wide mask saying we aren't interested in any
 	 events anymore.  */
-      td_event_emptyset (&events);
-      info->td_ta_set_event_p (info->thread_agent, &events);
+      td_event_fillset (&events);
+      info->td_ta_clear_event_p (info->thread_agent, &events);
     }
 
   info->td_create_bp_addr = 0;
Index: gdbserver/thread-db.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/thread-db.c,v
retrieving revision 1.26
diff -u -p -u -r1.26 thread-db.c
--- gdbserver/thread-db.c	29 Oct 2009 17:43:44 -0000	1.26
+++ gdbserver/thread-db.c	12 Nov 2009 00:21:02 -0000
@@ -759,6 +759,19 @@ thread_db_free (struct process_info *pro
     {
 #ifndef USE_LIBTHREAD_DB_DIRECTLY
       td_err_e (*td_ta_delete_p) (td_thragent_t *);
+      td_err_e (*td_ta_clear_event_p) (const td_thragent_t *ta,
+				       td_thr_events_t *event);
+
+      td_ta_clear_event_p = dlsym (thread_db->handle, "td_ta_clear_event");
+      if (td_ta_clear_event_p != NULL)
+	{
+	  td_thr_events_t events;
+
+	  /* Set the process wide mask saying we aren't interested in any
+	     events anymore.  */
+	  td_event_fillset (&events);
+	  (*td_ta_clear_event_p) (thread_db->thread_agent, &events);
+	}
 
       td_ta_delete_p = dlsym (thread_db->handle, "td_ta_delete");
       if (td_ta_delete_p != NULL)
@@ -766,6 +779,10 @@ thread_db_free (struct process_info *pro
 
       dlclose (thread_db->handle);
 #else
+      td_thd_events_t events;
+
+      td_event_fillset (&events);
+      td_ta_clear_event (thread_db->thread_agent, &events);
       td_ta_delete (thread_db->thread_agent);
 #endif  /* USE_LIBTHREAD_DB_DIRECTLY  */
 


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix for PR gdb/10838
  2009-11-12  0:35 [patch] Fix for PR gdb/10838 Paul Pluzhnikov
@ 2009-11-12  0:43 ` Daniel Jacobowitz
  2009-11-12  0:48   ` Paul Pluzhnikov
  0 siblings, 1 reply; 10+ messages in thread
From: Daniel Jacobowitz @ 2009-11-12  0:43 UTC (permalink / raw)
  To: Paul Pluzhnikov; +Cc: gdb-patches

On Wed, Nov 11, 2009 at 04:35:03PM -0800, Paul Pluzhnikov wrote:
> Greetings,
> 
> In http://sourceware.org/bugzilla/show_bug.cgi?id=10838
> gdb attach; detach; attach sequence leaves libpthread in hosed state.
> 
> The root cause turned out to be that this:
> 
>       td_event_emptyset (&events);
>       info->td_ta_set_event_p (info->thread_agent, &events);
> 
> is a no-op -- glibc ORs new event bits in, but doesn't clear any already
> set bits. To clear them, one must call td_ta_clear_event() instead.
> 
> Here is a patch which fixes this in gdb and gdbserver.
> 
> Tested (GDB only) on Linux/x86_64 with no regressions.

OK, thanks.

-- 
Daniel Jacobowitz
CodeSourcery


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix for PR gdb/10838
  2009-11-12  0:43 ` Daniel Jacobowitz
@ 2009-11-12  0:48   ` Paul Pluzhnikov
  2009-11-14  2:04     ` Paul Pluzhnikov
  0 siblings, 1 reply; 10+ messages in thread
From: Paul Pluzhnikov @ 2009-11-12  0:48 UTC (permalink / raw)
  To: Paul Pluzhnikov, gdb-patches

On Wed, Nov 11, 2009 at 4:42 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Wed, Nov 11, 2009 at 04:35:03PM -0800, Paul Pluzhnikov wrote:

> OK, thanks.

That was fast :-)
So committed.

Thanks,
-- 
Paul Pluzhnikov


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix for PR gdb/10838
  2009-11-12  0:48   ` Paul Pluzhnikov
@ 2009-11-14  2:04     ` Paul Pluzhnikov
  2009-11-15 17:37       ` Daniel Jacobowitz
  2009-11-16 15:11       ` Pedro Alves
  0 siblings, 2 replies; 10+ messages in thread
From: Paul Pluzhnikov @ 2009-11-14  2:04 UTC (permalink / raw)
  To: Paul Pluzhnikov, gdb-patches; +Cc: Doug Evans

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

2009/11/11 Paul Pluzhnikov <ppluzhnikov@google.com>:

> That was fast :-)

Too fast, as it turns out :-(
I didn't test the gdbserver part, but this patch introduced a
gdbserver crash here:

Program terminated with signal 11, Segmentation fault.

#0  0x0000000000408b75 in look_up_one_symbol (name=0x7f6dc44ee3a2
"__nptl_threads_events", addrp=0x7fffcce720c8) at
../../../src/gdb/gdbserver/remote-utils.c:1374
1374      for (sym = proc->symbol_cache; sym; sym = sym->next)

proc is NULL.
Called from:

#0  0x0000000000408b75 in look_up_one_symbol () at
../../../src/gdb/gdbserver/remote-utils.c:1374
#1  0x000000000041ae0e in ps_pglobal_lookup () at
../../../src/gdb/gdbserver/proc-service.c:68
#2  0x00007f6dc44ed60d in td_ta_clear_event () from /lib/libthread_db.so.1
#3  0x000000000041ac8b in thread_db_free (proc=0x6311a0) at
../../../src/gdb/gdbserver/thread-db.c:773
#4  0x0000000000411b44 in linux_remove_process (process=0x6311a0) at
../../../src/gdb/gdbserver/linux-low.c:267

Attached patch fixes that (tested with gdbserver on Linux/x86_64 this time).
The gdb.mi/mi-non-stop-exit.exp test is still failing (regression
since 2009-10-27), but apparently for a different reason.

Thanks,
-- 
Paul Pluzhnikov


2009-11-13  Paul Pluzhnikov  <ppluzhnikov@google.com>

	* proc-service.c (ps_pglobal_lookup): Handle error return
	* remote-utils.c (look_up_one_symbol): Don't crash if the process is gone.

[-- Attachment #2: gdbserver-crash-20091113.txt --]
[-- Type: text/plain, Size: 1220 bytes --]

Index: gdbserver/proc-service.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/proc-service.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 proc-service.c
--- gdbserver/proc-service.c	13 Oct 2009 13:51:21 -0000	1.14
+++ gdbserver/proc-service.c	14 Nov 2009 01:04:48 -0000
@@ -65,7 +65,7 @@ ps_pglobal_lookup (gdb_ps_prochandle_t p
 {
   CORE_ADDR addr;
 
-  if (look_up_one_symbol (name, &addr) == 0)
+  if (look_up_one_symbol (name, &addr) <= 0)
     return PS_NOSYM;
 
   *sym_addr = (psaddr_t) (unsigned long) addr;
Index: gdbserver/remote-utils.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/remote-utils.c,v
retrieving revision 1.68
diff -u -p -u -r1.68 remote-utils.c
--- gdbserver/remote-utils.c	6 Jul 2009 18:31:20 -0000	1.68
+++ gdbserver/remote-utils.c	14 Nov 2009 01:04:48 -0000
@@ -1369,6 +1369,9 @@ look_up_one_symbol (const char *name, CO
   struct process_info *proc;
 
   proc = current_process ();
+  if (proc == NULL)
+    /* Could happen if the process has just exited.  */
+    return -1;
 
   /* Check the cache first.  */
   for (sym = proc->symbol_cache; sym; sym = sym->next)

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix for PR gdb/10838
  2009-11-14  2:04     ` Paul Pluzhnikov
@ 2009-11-15 17:37       ` Daniel Jacobowitz
  2009-11-15 17:43         ` Doug Evans
  2009-11-16 15:11       ` Pedro Alves
  1 sibling, 1 reply; 10+ messages in thread
From: Daniel Jacobowitz @ 2009-11-15 17:37 UTC (permalink / raw)
  To: Paul Pluzhnikov; +Cc: gdb-patches, Doug Evans

On Fri, Nov 13, 2009 at 06:04:41PM -0800, Paul Pluzhnikov wrote:
> Attached patch fixes that (tested with gdbserver on Linux/x86_64 this time).
> The gdb.mi/mi-non-stop-exit.exp test is still failing (regression
> since 2009-10-27), but apparently for a different reason.

This is fine if you haven't checked it in.

Is the non-stop failure new, or just intermittent?  I believe I posted
a patch to refuse to do non-stop on targets where it won't work, but
it was limited to the remote target and I never revisited.  We don't
have x86_64 displaced stepping yet, right?

-- 
Daniel Jacobowitz
CodeSourcery


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix for PR gdb/10838
  2009-11-15 17:37       ` Daniel Jacobowitz
@ 2009-11-15 17:43         ` Doug Evans
  2009-11-15 17:47           ` Daniel Jacobowitz
  0 siblings, 1 reply; 10+ messages in thread
From: Doug Evans @ 2009-11-15 17:43 UTC (permalink / raw)
  To: Paul Pluzhnikov, gdb-patches

On Sun, Nov 15, 2009 at 9:36 AM, Daniel Jacobowitz <drow@false.org> wrote:
> We don't
> have x86_64 displaced stepping yet, right?

Actually we do.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix for PR gdb/10838
  2009-11-15 17:43         ` Doug Evans
@ 2009-11-15 17:47           ` Daniel Jacobowitz
  0 siblings, 0 replies; 10+ messages in thread
From: Daniel Jacobowitz @ 2009-11-15 17:47 UTC (permalink / raw)
  To: Doug Evans; +Cc: Paul Pluzhnikov, gdb-patches

On Sun, Nov 15, 2009 at 09:41:57AM -0800, Doug Evans wrote:
> On Sun, Nov 15, 2009 at 9:36 AM, Daniel Jacobowitz <drow@false.org> wrote:
> > We don't
> > have x86_64 displaced stepping yet, right?
> 
> Actually we do.

Hmm.  Maybe I should be more concerned, then.  I've been getting
intermittent non-stop failures... e.g. in mi-nsmoribund.exp.

-- 
Daniel Jacobowitz
CodeSourcery


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix for PR gdb/10838
  2009-11-14  2:04     ` Paul Pluzhnikov
  2009-11-15 17:37       ` Daniel Jacobowitz
@ 2009-11-16 15:11       ` Pedro Alves
  2009-11-16 15:14         ` Pedro Alves
  2009-11-16 16:05         ` Paul Pluzhnikov
  1 sibling, 2 replies; 10+ messages in thread
From: Pedro Alves @ 2009-11-16 15:11 UTC (permalink / raw)
  To: gdb-patches; +Cc: Paul Pluzhnikov, Doug Evans, Daniel Jacobowitz

On Saturday 14 November 2009 02:04:41, Paul Pluzhnikov wrote:

> Program terminated with signal 11, Segmentation fault.
> 
> #0  0x0000000000408b75 in look_up_one_symbol (name=0x7f6dc44ee3a2
> "__nptl_threads_events", addrp=0x7fffcce720c8) at
> ../../../src/gdb/gdbserver/remote-utils.c:1374
> 1374      for (sym = proc->symbol_cache; sym; sym = sym->next)
> 
> proc is NULL.
> Called from:
> 
> #0  0x0000000000408b75 in look_up_one_symbol () at
> ../../../src/gdb/gdbserver/remote-utils.c:1374
> #1  0x000000000041ae0e in ps_pglobal_lookup () at
> ../../../src/gdb/gdbserver/proc-service.c:68
> #2  0x00007f6dc44ed60d in td_ta_clear_event () from /lib/libthread_db.so.1
> #3  0x000000000041ac8b in thread_db_free (proc=0x6311a0) at
> ../../../src/gdb/gdbserver/thread-db.c:773
> #4  0x0000000000411b44 in linux_remove_process (process=0x6311a0) at
> ../../../src/gdb/gdbserver/linux-low.c:267

Having look_up_one_symbol handle the null process case
tastes like papering over an earlier issue.

> Attached patch fixes that (tested with gdbserver on Linux/x86_64 this time).

Why are we calling td_ta_clear_event at all if the
process is gone?  I think we should do that only if detaching,
like this (untested)?  This is what GDB does too.  The fact
that td_ta_clear_event wants to poke at a dead inferior is
a good indication of something not right.  If the process is
gone (or we didn't actually manage to connect to
this thread_db), there's no event mask to clear.

Also, thread_db_free assumes its PROC argument is the
current inferior (due to the fact that proc-service.c
relies on current_inferior currently).  This assumption
could/should be removed, but I'll leave that for
another day.

-- 
Pedro Alves

2009-11-16  Pedro Alves  <pedro@codesourcery.com>

	gdb/gdbserver/
	* linux-low.c (linux_remove_process): Add `detaching' parameter.
	Pass it to thread_db_free.
	(linux_kill, linux_detach, linux_wait_1): Adjust to pass the
	proper `detaching' argument to linux_remove_process.
	* linux-low.h (thread_db_free): Add `detaching' parameter.
	* thread-db.c (thread_db_init): Pass true as `detaching' argument
	to thread_db_free.
	(thread_db_free): Add `detaching' parameter.  Only
	call td_ta_clear_event if detaching from process.

---
 gdb/gdbserver/linux-low.c |   10 +++++-----
 gdb/gdbserver/linux-low.h |    2 +-
 gdb/gdbserver/thread-db.c |   26 +++++++++++++-------------
 3 files changed, 19 insertions(+), 19 deletions(-)

Index: src/gdb/gdbserver/linux-low.c
===================================================================
--- src.orig/gdb/gdbserver/linux-low.c	2009-11-16 02:07:20.000000000 +0000
+++ src/gdb/gdbserver/linux-low.c	2009-11-16 14:31:45.000000000 +0000
@@ -259,12 +259,12 @@ linux_add_process (int pid, int attached
    also freeing all private data.  */
 
 static void
-linux_remove_process (struct process_info *process)
+linux_remove_process (struct process_info *process, int detaching)
 {
   struct process_info_private *priv = process->private;
 
 #ifdef USE_THREAD_DB
-  thread_db_free (process);
+  thread_db_free (process, detaching);
 #endif
 
   free (priv->arch_private);
@@ -663,7 +663,7 @@ linux_kill (int pid)
     } while (lwpid > 0 && WIFSTOPPED (wstat));
 
   delete_lwp (lwp);
-  linux_remove_process (process);
+  linux_remove_process (process, 0);
   return 0;
 }
 
@@ -752,7 +752,7 @@ linux_detach (int pid)
 
   delete_all_breakpoints ();
   find_inferior (&all_threads, linux_detach_one_lwp, &pid);
-  linux_remove_process (process);
+  linux_remove_process (process, 1);
   return 0;
 }
 
@@ -1378,7 +1378,7 @@ retry:
 	  struct process_info *process = find_process_pid (pid);
 
 	  delete_lwp (lwp);
-	  linux_remove_process (process);
+	  linux_remove_process (process, 0);
 
 	  current_inferior = NULL;
 
Index: src/gdb/gdbserver/linux-low.h
===================================================================
--- src.orig/gdb/gdbserver/linux-low.h	2009-11-16 02:07:20.000000000 +0000
+++ src/gdb/gdbserver/linux-low.h	2009-11-16 12:51:09.000000000 +0000
@@ -201,7 +201,7 @@ struct lwp_info *find_lwp_pid (ptid_t pt
 
 /* From thread-db.c  */
 int thread_db_init (int use_events);
-void thread_db_free (struct process_info *);
+void thread_db_free (struct process_info *, int detaching);
 int thread_db_handle_monitor_command (char *);
 int thread_db_get_tls_address (struct thread_info *thread, CORE_ADDR offset,
 			       CORE_ADDR load_module, CORE_ADDR *address);
Index: src/gdb/gdbserver/thread-db.c
===================================================================
--- src.orig/gdb/gdbserver/thread-db.c	2009-11-16 12:51:06.000000000 +0000
+++ src/gdb/gdbserver/thread-db.c	2009-11-16 13:51:22.000000000 +0000
@@ -737,7 +737,7 @@ thread_db_init (int use_events)
       if (use_events && thread_db_enable_reporting () == 0)
 	{
 	  /* Keep trying; maybe event reporting will work later.  */
-	  thread_db_free (proc);
+	  thread_db_free (proc, 0);
 	  return 0;
 	}
       thread_db_find_new_threads ();
@@ -752,38 +752,38 @@ thread_db_init (int use_events)
 /* Disconnect from libthread_db and free resources.  */
 
 void
-thread_db_free (struct process_info *proc)
+thread_db_free (struct process_info *proc, int detaching)
 {
   struct thread_db *thread_db = proc->private->thread_db;
   if (thread_db)
     {
-#ifndef USE_LIBTHREAD_DB_DIRECTLY
       td_err_e (*td_ta_delete_p) (td_thragent_t *);
       td_err_e (*td_ta_clear_event_p) (const td_thragent_t *ta,
 				       td_thr_events_t *event);
 
+#ifndef USE_LIBTHREAD_DB_DIRECTLY
       td_ta_clear_event_p = dlsym (thread_db->handle, "td_ta_clear_event");
-      if (td_ta_clear_event_p != NULL)
+      td_ta_delete_p = dlsym (thread_db->handle, "td_ta_delete");
+#else
+      td_ta_delete_p = &td_ta_delete;
+      td_ta_clear_event_p = &td_ta_clear_event;
+#endif
+
+      if (detaching && td_ta_clear_event_p != NULL)
 	{
 	  td_thr_events_t events;
 
-	  /* Set the process wide mask saying we aren't interested in any
-	     events anymore.  */
+	  /* Set the process wide mask saying we aren't interested
+	     in any events anymore.  */
 	  td_event_fillset (&events);
 	  (*td_ta_clear_event_p) (thread_db->thread_agent, &events);
 	}
 
-      td_ta_delete_p = dlsym (thread_db->handle, "td_ta_delete");
       if (td_ta_delete_p != NULL)
 	(*td_ta_delete_p) (thread_db->thread_agent);
 
+#ifndef USE_LIBTHREAD_DB_DIRECTLY
       dlclose (thread_db->handle);
-#else
-      td_thr_events_t events;
-
-      td_event_fillset (&events);
-      td_ta_clear_event (thread_db->thread_agent, &events);
-      td_ta_delete (thread_db->thread_agent);
 #endif  /* USE_LIBTHREAD_DB_DIRECTLY  */
 
       free (thread_db);


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix for PR gdb/10838
  2009-11-16 15:11       ` Pedro Alves
@ 2009-11-16 15:14         ` Pedro Alves
  2009-11-16 16:05         ` Paul Pluzhnikov
  1 sibling, 0 replies; 10+ messages in thread
From: Pedro Alves @ 2009-11-16 15:14 UTC (permalink / raw)
  To: gdb-patches; +Cc: Paul Pluzhnikov, Doug Evans, Daniel Jacobowitz

On Monday 16 November 2009 15:10:43, Pedro Alves wrote:

> like this (untested)?  This is what GDB does too.  The fact

I've actually tested this on x86_64-linux (after having written that...).
Fixes the crashes, has no regressions.

-- 
Pedro Alves


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix for PR gdb/10838
  2009-11-16 15:11       ` Pedro Alves
  2009-11-16 15:14         ` Pedro Alves
@ 2009-11-16 16:05         ` Paul Pluzhnikov
  1 sibling, 0 replies; 10+ messages in thread
From: Paul Pluzhnikov @ 2009-11-16 16:05 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb-patches, Doug Evans, Daniel Jacobowitz

On Mon, Nov 16, 2009 at 7:10 AM, Pedro Alves <pedro@codesourcery.com> wrote:

> 2009-11-16  Pedro Alves  <pedro@codesourcery.com>
>
>        gdb/gdbserver/
>        * linux-low.c (linux_remove_process): Add `detaching' parameter.
>        Pass it to thread_db_free.

Looks good to me.

Thanks!
-- 
Paul Pluzhnikov


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2009-11-16 16:05 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-11-12  0:35 [patch] Fix for PR gdb/10838 Paul Pluzhnikov
2009-11-12  0:43 ` Daniel Jacobowitz
2009-11-12  0:48   ` Paul Pluzhnikov
2009-11-14  2:04     ` Paul Pluzhnikov
2009-11-15 17:37       ` Daniel Jacobowitz
2009-11-15 17:43         ` Doug Evans
2009-11-15 17:47           ` Daniel Jacobowitz
2009-11-16 15:11       ` Pedro Alves
2009-11-16 15:14         ` Pedro Alves
2009-11-16 16:05         ` Paul Pluzhnikov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox