#49937 Crash in vslapd_log_emergency_error
Closed: fixed 6 months ago Opened 6 months ago by mreynolds.

Description of problem:

we can see a crash in directry with this stacktrace:

(gdb) bt
#0  0x00007f748a9c1373 in PR_Write (fd=0x55683c42e4e0, buf=0x7f742b404bd0, amount=107) at ../../../nspr/pr/src/io/priometh.c:114
#1  0x000055683a6458a5 in slapi_write_buffer (fd=<optimized out>, buf=<optimized out>, amount=<optimized out>) at ldap/servers/slapd/fileio.c:48
#2  0x00007f748ca6c66b in vslapd_log_emergency_error (fp=0x55683c42e4e0, msg=0x7f748cade1a8 "Insufficent buffer capacity to fit timestamp and message!", locked=0) at ldap/servers/slapd/log.c:2260
#3  0x00007f748ca73779 in vslapd_log_access (fmt=fmt@entry=0x7f748cadf994 "conn=%lu op=%d MOD dn=\"%s\"%s\n", ap=ap@entry=0x7f742b4064a0) at ldap/servers/slapd/log.c:2535
#4  0x00007f748ca74971 in slapi_log_access (level=level@entry=256, fmt=fmt@entry=0x7f748cadf994 "conn=%lu op=%d MOD dn=\"%s\"%s\n") at ldap/servers/slapd/log.c:2568
#5  0x00007f748ca7c15f in op_shared_modify (pb=pb@entry=0x55683f960ea0, pw_change=pw_change@entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:668
#6  0x00007f748ca7e05b in do_modify (pb=pb@entry=0x55683f960ea0) at ldap/servers/slapd/modify.c:391
#7  0x000055683a63d2ee in connection_dispatch_operation (pb=0x55683f960ea0, op=0x55685ff5aa80, conn=0x55683e872780) at ldap/servers/slapd/connection.c:625
#8  0x000055683a63d2ee in connection_threadmain () at ldap/servers/slapd/connection.c:1785
#9  0x00007f748a9db9bb in _pt_root (arg=0x55683f95ed00) at ../../../nspr/pr/src/pthreads/ptthread.c:216
#10 0x00007f748a37be25 in start_thread (arg=0x7f742b407700) at pthread_create.c:396
#11 0x00007f7489c5d34d in lsetxattr () at ../sysdeps/unix/syscall-template.S:81
#12 0x0000000000000000 in None ()

Version-Release number of selected component (if applicable): 389-ds-base-1.3.7.5-24.el7_5.x86_64

How reproducible: not easily.


c64f7fb..8ff8cb8 master -> master

de03e74..c5e7824 389-ds-base-1.3.8 -> 389-ds-base-1.3.8

79d0b4d..9f28620 389-ds-base-1.3.7 -> 389-ds-base-1.3.7

Metadata Update from @mreynolds:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

6 months ago

Is this correct ?

62 + if (!locked) {
63 + LOG_ERROR_UNLOCK_WRITE();

unlock if not locked ?

:) I had the same trouble
Actually it is correct, 'locked' flag says if the caller acquired or not the lock.
If it did not, then the fix acquires it upper in the function and use the same flag to release it

:) I had the same trouble
Actually it is correct, 'locked' flag says if the caller acquired or not the lock.
If it did not, then the fix acquires it upper in the function and use the same flag to release it

thanks

Login to comment on this ticket.

Metadata