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)
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
thanks
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2996
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Log in to comment on this ticket.