Some history for you: The 'guile' module is the first one on subversions 
where people are using lsh.  I'm troubleshooting to figure out why people 
were reporting data loss from 'cvs diff'.  Dirk has volunteered to help 
us troubleshoot if this is an lsh problem, and also has 'ssh' access as 
well for comparison.

Please also preserve the [EMAIL PROTECTED] cc: on this so that we can 
follow what's going on. =)

Thanks for your help!

----- Forwarded message from Dirk Herrmann <[EMAIL PROTECTED]> -----

Received: from marvin.ida.ing.tu-bs.de ([EMAIL PROTECTED] [134.169.132.60]) 
by sparky.nisa.net (8.9.3/nisa4.7) with ESMTP id IAA08045 for <[EMAIL PROTECTED]>; Wed, 
6 Sep 2000 08:08:21 -0700
X-MailHub: mail.nisa.net
Received: from localhost (dirk@localhost)
        by marvin.ida.ing.tu-bs.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id 
RAA15527;
        Wed, 6 Sep 2000 17:08:18 +0200
X-Authentication-Warning: marvin.ida.ing.tu-bs.de: dirk owned process doing -bs
Date: Wed, 6 Sep 2000 17:08:18 +0200 (MEST)
From: Dirk Herrmann <[EMAIL PROTECTED]>
To: Jeff Bailey <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: Re: Volunteer?
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O
X-Status: A
Content-Length: 2889
Lines: 85

On Wed, 6 Sep 2000, Jeff Bailey wrote:

> Please confirm:  Under LSH you see an error wth cvs diff, and under SSH 
> you do not?  Can you also please try a commit under both and send me 
> screen shots (Or cut and paste text, etc)  to see if the error still occurs?

Under LSH, I see truncated output, for example, with lsh the diff output on my
xterm holds the following line (this is cut and pasted):

  + * get execu+      "If FLAG is #t, cell access checking is enabled, but no\n"

This is corrupted, since a lot of intermediate data got lost.  The output
with SSH which corresponds to the above line is as follows (again cut and 
pasted):

  + * get executed after a user defined number of cell accesses.  This helps to
  + * find places in the C code where references are dropped for extremely short
  + * periods.
    */
   void
   scm_assert_cell_valid (SCM cell)
   {
  -  if (scm_debug_cell_accesses_p)
  +  static unsigned int already_running = 0;
  +
  +  if (scm_debug_cell_accesses_p && !already_running)
       {
  -      scm_debug_cell_accesses_p = 0;  /* disable to avoid recursion */
  +      already_running = 1;  /* set to avoid recursion */
   
         if (!scm_cellp (cell))
          {
  @@ -122,14 +134,32 @@
               cells during gc.  I don't understand why this happens.  If it is
               a bug and gets fixed, the following test should also work while
               gc is running.
  -          */
  +         */
            if (SCM_FREE_CELL_P (cell))
              {
                fprintf (stderr, "scm_assert_cell_valid: Accessing free cell: %lx\n", 
SCM_UNPACK (cell));
                abort ();
              }
  +
  +         /* If desired, perform additional garbage collections after a user
  +          * defined number of cell accesses.
  +          */
  +         if (debug_cells_gc_interval)
  +           {
  +             static unsigned int counter = 0;
  +             
  +             if (counter != 0)
  +               {
  +                 --counter;
  +               }
  +             else
  +               {
  +                 counter = debug_cells_gc_interval;
  +                 scm_igc ("scm_assert_cell_valid");
  +               }
  +           }
          }
  -      scm_debug_cell_accesses_p = 1;  /* re-enable */
  +      already_running = 0;  /* re-enable */
       }
   }
   
  @@ -137,7 +167,11 @@
   SCM_DEFINE (scm_set_debug_cell_accesses_x, "set-debug-cell-accesses!", 1, 0, 0,
              (SCM flag),
              "If FLAG is #f, cell access checking is disabled.\n"
  -           "If FLAG is #t, cell access checking is enabled.\n"
  +           "If FLAG is #t, cell access checking is enabled, but no\n"

I have no problems, however, if I do the following:

  cvs diff > some_file

The problem only occurs when output goes to the xterm or to less.  Further, it
seems that I can submit without problems.  I have already done so.  Moreover,
I also receive updates correctly.


Best regards
Dirk

----- End forwarded message -----

-- 
"It is easy to be blinded to the essential uselessness of computers by
the sense of accomplishment you get from getting them to work at all."
 - Douglas Adams


Reply via email to