Re: [pilot-db-list] archive not updated

[Yedidyah Bar-D. <di...@ta...>]

On Wed, Apr 28, 2004 at 01:28:44AM +0300, Yedidyah Bar-David wrote:
> On Tue, Apr 27, 2004 at 03:02:51PM -0600, Nathan Kurz wrote:
> > On Tue, Apr 27, 2004 at 10:55:34PM +0300, Yedidyah Bar-David wrote:
> > > Sorry for a probably FAQ, but:
> > > The web archive is not updated. I did not keep all messages, assuming
> > > I can use the archive.
> > > 1. Does anyone know why it's not updated?
> > > 2. Is it possible to ask mailman to send to me messages? I sent 'help'
> > > to pilot-db-list-request and it does not have a command for this.
> > 
> > I just checked on the SourceForge status page and found this:
> > 
> >   ( 2004-04-19 05:44:42 - Mailing List Service ) Performance testing
> >   of an updated SourceForge.net mailing list archive architecture has
> >   commenced as of the morning of 2004-04-19; this change is expected
> >   to increase search performance and resolve long-term mailing list
> >   archive reliability problems. During this test period (of up to a
> >   few days), archive updates will be suspended temporarily and
> >   archives will be backdated to their state as of approx. two weeks
> >   ago. Pending completion of testing and performance monitoring,
> >   updates will resume.
> > 
> > As far as I know, there is no general way to get the non-archived
> > messages.  In general, my impression is that SourceForge is dying a
> > slow painful death.  Many good projects have left due to reliability
> > problems.  We'd probably leave too, if we were strong enough to move.
> 
> :-(
> Hopefully we will. Am I now part of "we"?
> 
> > 
> > I've got most of the April messages undeleted.  Should I bundle
> > together those that I can find and send you a batch of them?
> 
> Please do. The one I wanted specifically was with the URL of a multi-
> section prc-tools, but I already found it with google, so it's not that
> important. Actually, I made quite a lot of progress - I compiled 1.1.0
> with it, and using the patched gdb found the source of the problem I
> mentioned (of pilot-db crashing in Up/Down arrow).
> 
> The bug is (mainly, maybe not only) in SetupRecordData:
> It goes over the Schema's fields rather than over the View's fields.
> The place in which the actual crash happens is in EditViewScroll,
> in the line 'str = LockMemHandle(fields[fieldIndex].editor->h);' (847).
> fieldIndex is counted in the View, but fields was initialized according
> to the DB Schema.

Well, I am very happy to announce a fix. It wasn't, after all, in
SetupRecordData - the description above was a bit harsh and stupid of
me. It was a simple bug directly in the place of the crash, but is only
revealed in very specific cases (described below).
The patch is this one-liner:
--- ../../../t/pilot-db/src/edit.c      Fri Nov 14 18:14:06 2003
+++ edit.c      Mon May  3 18:58:04 2004
@@ -844,7 +844,7 @@
 
                 switch (CurrentSource->schema.fields[ActiveView->cols[fieldIndex].fieldNum].type) {
                 case FIELD_TYPE_STRING:
-                    str = LockMemHandle(fields[fieldIndex].editor->h);
+                    str = LockMemHandle(fields[ActiveView->cols[fieldIndex].fieldNum].editor->h);
                     height += FldCalcFieldHeight(str, columnWidth)
                         * FntLineHeight();
                     UnlockMemPtr(str);

Later,
-- 
Didi

> 
> A trivial DB that shows the bug:
> Create a DB with enough rows (num of screen lines +, say, 2. I tried
> it with a 12 field DB), make the second a boolean (or any other type
> with no editor) and the others string, then create a listview in which
> the second field is e.g. the first DB's field (a string), edit a row,
> press Down, Up, it will crash. Why? Because it tries to access the
> second field's editor, because it's a string, but it was initialized
> without an editor, because it's boolean.
> You can get my minimal db in <http://www.cs.tau.ac.il/~didi/testdb.pdb>.
> It took me several hours to find this, and I'm going to sleep now (it's
> 01:30 now and I work tomorrow). If you want I can try to write a patch.
> Unless it's only in SetupRecordData, it's going to be quite complex -
> it seems as though the original code was for a DB without a listview
> object, in which a listview is the same as the DB (at least in terms
> of field order), and later a listview was added, without taking care
> of all the places. What I do not understand yet is why PgDn/PgUp do
> work (and that's what I told my brother-in-law to do for the time being).
> -- 
> Didi
>