[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: possible stack corruption in 2.0.21?



                                                                                
I experienced this same issue on the same arcitecture when I upgraded to        
2.0.21 yesterday..                                                              
                                                                                
Reverting to earlier versions of [pam|nss]_ldap : Problem remains.              
                                                                                
Are any other arcitectures experiencing problems with 2.0.21 I wonder? - Guys?  
                                                                                
Steve                                                               


On Thu, Jan 24, 2002 at 05:47:41PM -0800, Luca Filipozzi wrote:

> I am experiencing problems with 2.0.21 that I suspect are due to stack
> corruption.  Here's my environment:
> 
> Solaris 7 (sparc)
> OpenLDAP 2.0.21 (previous version used was 2.0.17)
> PADL's pam_ldap and nss_ldap
> 
> slapd and slurpd are working fine
> ldapsearch (and the other utilities, I suspect) is working fine
> 
> What's wrong is that utilities that use NSS/nss_ldap on my client
> workstations are sigsegv'ing somewhere between exit() and _exit().
> 
> More specifically,
> Solaris 7's "id" command works
> Solaris 7's "getent" command works
> Solaris 7's "finger" command (uses NSS when no fingerd is up) fails
> GNU's "id" command (sh-utils-2.0.11) fails
> 
> I rebuilt GNU's id with debugging and traced it.  Even though it
> registers an atexit() function, it fails to reach it.  Back trace simply
> shows an address somewhere in libc, for which I have no debugging
> symbols.
> 
> I've tried all versions between 2.0.17 and 2.0.21 with these results:
> 
> 2.0.17 ok
> 2.0.18 ok
> 2.0.19 ok
> 2.0.20 not ok
> 2.0.21 not ok
> 
> The only thing that is changing is OpenLDAP.
> 
> I know this is not a very useful problem report, but it's the best I can
> offer at this point.  Any ideas would be appreciated.