New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crash when deleting suffix #562
Comments
Comment from mreynolds (@mreynolds389) at 2013-01-24 22:12:19 |
Comment from lkrispen (@elkris) at 2013-01-24 22:44:42 This fix reduces the risk that p->next is modified before it is used, but cannot completely eliminate it. At the time this thread does |
Comment from mreynolds (@mreynolds389) at 2013-01-24 22:57:56 Replying to [comment:2 elkris]:
I guess its possible two threads could be trying to delete the same suffix. I'll look into adding locks, but adding locking around this recursive code is not so easy. Deleting a callback, calls callbacks from the same list, which can then delete callbacks from the same list - and then we call the dse_delete function again, and the cycle continues. |
Comment from nkinder (@nkinder) at 2013-01-25 00:45:37 Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=901507 (''Red Hat Enterprise Linux 7'') |
Comment from mreynolds (@mreynolds389) at 2013-01-25 01:19:34 master git merge ticket562 git push origin master 1.3.0 git push origin 389-ds-base-1.3.0 |
Comment from mreynolds (@mreynolds389) at 2017-02-11 22:48:36 Metadata Update from @mreynolds389:
|
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/562
On 32-bit platforms it's possible that deleting a suffix can crash the DS. The server does not crash on 64-bit platforms. One strange issue with this is that you must NOT have a backend named "userRoot" to trigger the crash. This can not easily be explained since "userRoot" is not a hard-coded value in the source.
Steps to reproduce:
[1] Create 7 suffixes
[2] Add an entry to each suffix
[3] Restart the server
[4] Delete the last suffix that was added --> crash!
Valgrind output:
==790== Invalid read of size 4
==790== at 0x64C289: dse_call_callback (dse.c:2386) --> crash
==790== by 0x64C943: dse_delete (dse.c:2314)
==790== by 0x645E3B: op_shared_delete (delete.c:364)
==790== by 0x646251: do_delete (delete.c:128)
==790== by 0x8059564: connection_threadmain (connection.c:583)
==790== by 0xDE4271: ??? (in /lib/libnspr4.so)
==790== by 0xBC7A48: start_thread (in /lib/libpthread-2.12.so)
==790== by 0xB03AED: clone (in /lib/libc-2.12.so)
==790== Address 0x6003dbc is 4 bytes inside a block of size 36 free'd
==790== at 0x4006C7F: free (vg_replace_malloc.c:446)
==790== by 0x6416EC: slapi_ch_free (ch_malloc.c:363)
==790== by 0x64B354: dse_callback_delete (dse.c:260)
==790== by 0x64B463: dse_remove_callback (dse.c:345)
==790== by 0x64B526: slapi_config_remove_callback (dse.c:2434)
==790== by 0x6CD1E58: vlv_remove_callbacks (vlv.c:469)
==790== by 0x6CB3150: ldbm_instance_post_delete_instance_entry_callback (ldbm_instance_config.c:1062)
==790== by 0x64C32F: dse_call_callback (dse.c:2393)
==790== by 0x64C943: dse_delete (dse.c:2314)
==790== by 0x645E3B: op_shared_delete (delete.c:364)
==790== by 0x646251: do_delete (delete.c:128)
==790== by 0x8059564: connection_threadmain (connection.c:583)
==790== by 0xDE4271: ??? (in /lib/libnspr4.so)
==790== by 0xBC7A48: start_thread (in /lib/libpthread-2.12.so)
==790== by 0xB03AED: clone (in /lib/libc-2.12.so)
The text was updated successfully, but these errors were encountered: