Closed Bug 1573 Opened 26 years ago Closed 25 years ago

Attributes only core dumps

Categories

(Directory :: PerLDAP, defect, P2)

Product:
Directory
Component:
PerLDAP
Platform:
All
Solaris
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: leif, Assigned: leif)

Details

From kburns@netscape.com (Kevin L. Burns):

Second, I found a bug in Conn::search().  It seems that if I set $attrsonly to 1
I get a seg fault and a core dump (if you like I'll send you the core file,
though it should be easy to reproduce).  Doing the exact same operation with
$attrsonly set to 0 works fine, so that's what I'll do for now.
Status: NEW → ASSIGNED
Setting all current Open Critical and Major to M3
Clearing "M" field since Directory product is not used for 5.0 specific project
bug metrics and will mess up our queries on milestones.
Severity: major → normal
Priority: P1 → P2
This still doesn't work, but I can't get it to core dump. I'm not sure how we
should handle this, I just haven't thought about. Two possible solutions:

1. We don't do anything, like today. Bad.

2. We give the attributes "empty" values (NULL string). Without a value, they
won't show up in the hash array, which sort of defeats the purpose.

Any suggestions?
I can't get this to core dump.  It seems to work for me - the keys all print out
for me if I do print join(',', keys($%entry)).

If this is touchy on other systems, why not just set a variable in the
connection object noting that the query was for attributes-only.  Then, inside
of nextEntry(), we can set the attribute equal to [] or undef instead of calling
ldap_get_values_len.

Maybe I'm missing the bug though - a code snippet would help.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I can't get it to core dump either, closing bug. Please reopen if it's still
there, I just tested with the v1.3 development branch.
You need to log in before you can comment on or make changes to this bug.