I was digging around OpenLdap trying to figure out why in the world
things were acting weird. I put in my own printf before this line was
printed: "ldap_connect_to_host: TCP (null):7", and my printf showed
the correct host!
So I edited print.c (ldap_log_printf) to the following and now
everything works perfectly fine! This is very weird!
44 int ldap_log_printf( LDAP *ld, int loglvl, const char *fmt, ... )
45 {
46 char buf[ 1024 ];
47 va_list ap;
48 if ( !ldap_log_check( ld, loglvl )) {
49 return 0;
50 }
51
52 va_start( ap, fmt );
53
54 printf( "J:>>> " ); fflush( stdout );
55 vprintf( fmt, ap ); fflush( stdout );
56 va_end(ap);
57 return 1;
58
59 buf[sizeof(buf) - 1] = '\0';
60 vsnprintf( buf, sizeof(buf)-1, fmt, ap );
61
62 va_end(ap);
63
64 (*ber_pvt_log_print)( buf );
65 return 1;
66 }
On 5/11/06, Jeremiah Martell <[EMAIL PROTECTED]> wrote:
No, I'm trying to connect to a valid ldap server address.
"directory.example.com". And I'm using port 389. I'm not sure why
ldap's debugging says "(null):7".
Has anybody seen this before?
Thanks,
- Jeremiah
On 5/10/06, Aaron Richton <[EMAIL PROTECTED]> wrote:
> > It works fine without debugging though, no crash. Any ideas?
>
> Don't turn on debugging and you won't crash! Of course...
>
> > ldap_connect_to_host: TCP (null):7
>
> is a bit bothersome. Are you really trying to connect to NULL? Even worse,
> are you trying to printf() the NULL, perhaps when debugging? This is well
> known to have Bad Effects.
>
> If it's as simple as starting your program and watching it die, standard
> debugging tools (gdb, dbx, valgrind, libumem, librtc) should be able to
> pinpoint this fairly concretely.
>
