( top) in objectclass...

VERIFIED FIXED

Status

P1
critical
VERIFIED FIXED
20 years ago
20 years ago

People

(Reporter: leif, Assigned: kmccarth)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
Leif,

Below are the pm's that have good cert behavior and bad ( top) behavior.  I
fetched them from the CVS today, but they are certainly the same ones I was
talking about in my original message.  I had fetched them around 02:30 Sunday.
I have some other stuff to work on, and I guess I can stall on the question of
whether I can copy certificates.  I would rather just give a positive answer
when it all works.  I will be focusing on NT from here on.

I don't know if it matters which NT or SDK I'm using.  I'm running NT4 sp4, the
domestic 3.1 SDK, ActivePerl build 509, DS311, and ES 3.6.

Do you have an idea what part of the code this problem is coming from?  I would
like to, at least attempt to, read through the code and see if I can make heads
or tails of it.

Steve

$Id: API.pm,v 1.13.2.4 1999/03/23 21:41:58 leif%netscape.com Exp $
$Id: Conn.pm,v 1.19.2.4 1999/03/23 21:41:58 leif%netscape.com Exp $
 $Id: Entry.pm,v 1.10.2.6 1999/03/26 09:42:31 leif%netscape.com Exp $
 $Id: LDIF.pm,v 1.6.2.8 1999/04/01 19:36:23 kristian%netscape.com Exp $
$Id: Utils.pm,v 1.11.2.3 1999/03/23 21:41:59 leif%netscape.com Exp $

Leif Hedstrom wrote:

> "Steven T. Hatton" wrote:
>
> > I then downloaded from the 1_3 tree.  That seems to work ok for 64-bit
> > encoding of certificates, but (top) is now ( top).
>
> Is that the 1.3 from the CVS server, or from the FTP site? The CVS server
> has new code checked in, but I haven't created a snapshot for the for that
> yet (the FTP server has v1.3.1). I remember having this ( top) problem as
> well, but can not reproduce it anymore.
>
> Let me know what versions you are using (e.g. send me the header IDs). I
> can also send you a patch to go from v1.3.1 to the current CVS state if you
> like. I'm working on a v1.3.2 snapshot, but would like to finish a couple
> of more things before I do.
>
> -- leif
(Reporter)

Updated

20 years ago
Status: NEW → ASSIGNED
(Reporter)

Updated

20 years ago
Priority: P3 → P1
(Reporter)

Updated

20 years ago
Assignee: leif → kmccarth
Status: ASSIGNED → NEW
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 1

20 years ago
The code that was producing this bug was:

{ # Print the entry, grab another and print till done.
      while ($entry)
      {
            print h2("Here's an entry:  ");
           $entry->printLDIF();
           $outConn->add($entry);
           $entry = $inConn->nextEntry();
      }
};

The cause was the $entry->printLDIF(), which was modifying $entry.

This bug was fixed between revision 1.6.2.9 and 1.6.2.10 of LDIF.pm, by
kristian@netscape.com.

The function pack_LDIF() was modifying values in the records passed through,
(by modifying $val).  The comment in Entry.pm getLDIFrecords() mentions the fact
that it is returning a reference to the same values back, which is dangerous.

I confirmed that using LDIF.pm revision 1.6.2.9 exhibited the behaviour of this
bug, but revision 1.6.2.10 works fine.

Steve Hatton also confirmed to me that the bug doesn't exist anymore:

> Kevin,
>
> Thanks very much for the follow up.  It seems to be fixed now.  I haven't
> been messing with it for a long time because I just didn't have time.  I
> hope it is a thing of the past.  If I can reproduce it I will let you
> know.  I am now using the 1_9 branch.  I just compiled it.  The problem was
> on NT.  To tell the truth I don't remember if and when it happened on
> Linux, but I believe at one point it did.  Oh well, I'm glad I now have
> this working.  Perhaps I can go back to playing with perl.
>
> Steve
(Assignee)

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
(Assignee)

Updated

20 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.