Hello, 

On our platforms HP-UX B.11.00 U 9000/800,
we are using samba version 3.0.21c in which we encounter 
some locking problems (not released locks). 
This made us decide to test version 3.0.23b
which includes the 3587 bug correction (locking problem).

After upgrading, SMBD could not start.
The log file smbd.log tells us that :

       NT user token: (NULL)
     [2006/08/24 16:39:14, 5] auth/auth_util.c:(473)
       UNIX token of user 0
       Primary group is 0 and contains 0 supplementary groups
     [2006/08/24 16:39:14, 5] lib/smbldap.c:(1178)
       smbldap_search_ext: base => [l=mathilde,dc=fedpol,dc=be], filter => 
       [(&(uid=root)(objectclass=sambaSamAccount))], scope => [2]
     [2006/08/24 16:39:14, 2] passdb/pdb_ldap.c:(541)
       init_sam_from_ldap: Entry found for user: root
     [2006/08/24 16:39:15, 0] lib/fault.c:(41)
       ===============================================================
     [2006/08/24 16:39:15, 0] lib/fault.c:(42)
       INTERNAL ERROR: Signal 11 in pid 5422 (3.0.23b)
       Please read the Trouble-Shooting section of the Samba3-HOWTO
     [2006/08/24 16:39:15, 0] lib/fault.c:(44)

       From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf
     [2006/08/24 16:39:15, 0] lib/fault.c:(45)
       ===============================================================
     [2006/08/24 16:39:15, 0] lib/util.c:(1591)
       PANIC (pid 1074551133): ¦^Oá÷Q0"&Øì^C+mTǹÕ@ä¨èa^HkÖÂ^D½-A
     [2006/08/24 16:39:15, 0] lib/util.c:(1749)
       unable to produce a stack trace on this platform
     [2006/08/24 16:39:15, 0] lib/util.c:(1600)
       smb_panic(): calling panic action [/usr/bin/sleep 999999]
 
To get more precisions, we compiled a debugged version of samba,
so gdb tells us :

     Detected 32-bit executable.
     Invoking /tmp/gdb/gdb32.
     HP gdb 5.3.0 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00
     and target hppa1.1-hp-hpux11.00.
     0xc01f8e78 in _waitpid_sys+0x10 () from /usr/lib/libc.2
     (gdb) bt
     #0  0xc01f8e78 in _waitpid_sys+0x10 () from /usr/lib/libc.2
     #1  0xc02060dc in waitpid+0x64 () from /usr/lib/libc.2
     #2  0xc01ef9b4 in _system_sys+0x1b0 () from /usr/lib/libc.2
     #3  0xc0205b24 in system+0x5c () from /usr/lib/libc.2
     #4  0x220410 in smb_panic () at lib/util.c:1601
     #5  0x2078b4 in fault_report () at lib/fault.c:47
     #6  0x207bbc in sig_fault () at lib/fault.c:70
     #7  <signal handler called>
     #8  0x20a908 in timegm () at lib/timegm.c:60
     #9  0x1e30cc in ldapsam_get_entry_timestamp () at passdb/pdb_ldap.c:460
     #10 0x1e391c in init_sam_from_ldap () at passdb/pdb_ldap.c:890
     #11 0x1e5e44 in ldapsam_getsampwnam () at passdb/pdb_ldap.c:1407
     #12 0x1db9fc in pdb_default_uid_to_rid () at passdb/pdb_interface.c:1211
     #13 0x1db288 in pdb_uid_to_rid () at passdb/pdb_interface.c:1021
     #14 0x1e0cbc in uid_to_sid () at passdb/lookup_sid.c:1076
     #15 0x265aec in get_root_nt_token () at auth/auth_util.c:508
     #16 0x1285fc in svcctl_init_keys () at services/services_db.c:415
     #17 0x2ad704 in init_registry () at registry/reg_frontend.c:132
     #18 0x2c0254 in main () at smbd/server.c:948
     (gdb) quit

Thus, something happened during timegm() which is called by ldapsam_get_entry_timestamp() in pdb_ldap.c.
Indeed, timegm() has been modified in 3.0.23b. 
We compiled 3.0.23b using timegm() of version 3.0.21c 
and all worked fine again.

Nonetheless, as new timegm() source code is good, I added debug
information in timegm.c and let call both new and old version
from ldapsam_get_entry_timestamp().

result of debugging :
---------------------

-------------------------------
time_t timegm(struct tm * tm) * 
v.3.0.21c                     *
-------------------------------

as input gets:

tm_sec=-1072146013,
tm_min=-1072156701,
tm_hour=1
tm_wday=16,
tm_yday=1074373832,
tm_isdst=2137731208
tm_mday=0,
tm_mon=1073925788,
tm_year=106

as output returns :

3599

-------------------------------
time_t timegm(struct tm * tm) * 
v.3.0.23c                     *
-------------------------------

as input gets:

tm_sec=-1072146013,
tm_min=-1072156701,
tm_hour=1
tm_mday=0,
tm_mon=1073925788,
tm_year=106
tm_wday=16,
tm_yday=1074373832,
tm_isdst=2137731208

as output returns :
 it loops indefinetely
 and crashes.

So, functions's input seems to be garbage,
to this garbage, version 3.0.21c returns something
which by nature incorrect, and version 3.0.23c 
crashes.

Going back to ldapsam_get_entry_timestamp(), we see the input is generated 
by a calling to :

    strptime(temp, "%Y%m%d%H%M%SZ", &tm);

temp string contains the value of the ldap modifytimestamp attribute
which value is when SMBD crashes : "20060823150548Z"
no problem here,
but the resulting structure tm contains the same garbage as previously
noted.


After adding a space between each conversion character in the format
string and the source string, as specified in the man pages of the function : 

"Each conversion specification is composed of a % character followed by a conversion character which specifies the replacement required. There must be whitespace or other non-alphanumeric characters between any two conversion specifications..."

strptime gave the long awaited result.

I hope that all this can help, maybe there is a more subtle underlying problem
since I could not find anyone else on the net having the same issue. 


Nicolas Labrou