[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: (ITS#7627) [Patch] Fix segfault in slaptest

To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#7627) [Patch] Fix segfault in slaptest
From: hyc@symas.com
Date: Mon, 24 Jun 2013 02:49:21 GMT
Auto-submitted: auto-generated (OpenLDAP-ITS)
jsynacek@redhat.com wrote:
> Full_Name: Jan Synacek
> Version: master
> OS: Linux - Fedora 18
> URL: http://jsynacek.fedorapeople.org/openldap/slaptest/0001-Fix-segfault-in-slaptest.patch
> Submission from: (NULL) (209.132.186.34)
>
>
> Consider the following configuration:
> http://jsynacek.fedorapeople.org/openldap/slaptest/slapd-segfault.conf
>
> When an overlay is specified after the 'database monitor', slaptest segfaults.
> I'm not sure whether such configuration makes much sense, however I think that
> slaptest shouldn't segfault.
>
> To reproduce, use the above config and run:
> slapd -Tt -f slapd-segfault.conf -F /path/to/a/dir

Unable to reproduce any of this. No crash, and no uninit'd memory references 
in valgrind. I think something is corrupted in your source or build tree.
>
> Backtrace:
> #0  0x0000003385009b70 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0
> #1  0x00007ffff7da524d in ldap_pvt_thread_mutex_lock (mutex=0x25) at
> thr_posix.c:296
> #2  0x00000000005574b9 in monitor_cache_get (mi=0x1d, ndn=0x7fffffffde30,
> ep=0x7fffffffde28) at cache.c:161
> #3  0x000000000051a10d in monitor_back_unregister_entry_attrs (ndn_in=0x908230,
> target_a=0x0, target_cb=0xa70030,
>      nbase=0x0, scope=0, filter=0x0) at init.c:1520
> #4  0x000000000051a5b0 in monitor_back_unregister_entry_callback (ndn=0x908230,
> cb=0xa70030, nbase=0x0, scope=0,
>      filter=0x0) at init.c:1632
> #5  0x00000000004f6f19 in bdb_monitor_db_close (be=0x907d70) at monitor.c:500
> #6  0x00000000004ef0b4 in bdb_db_close (be=0x907d70, cr=0x0) at init.c:595
> #7  0x0000000000454ad5 in backend_shutdown (be=0x907d70) at backend.c:383
> #8  0x00000000004814a9 in slap_shutdown (be=0x0) at init.c:232
> #9  0x00000000004de90d in slap_tool_destroy () at slapcommon.c:936
> #10 0x00000000004e0435 in slaptest (argc=6, argv=0x7fffffffe228) at
> slaptest.c:116
> #11 0x000000000041a9f5 in main (argc=6, argv=0x7fffffffe228) at main.c:665
>
> Notice the corrupt 'mi' pointer in frame #2.
>
> The segfault does not always appear, so here is the corresponding valgrind
> output:
> ==6751== Memcheck, a memory error detector
> ==6751== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==6751== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==6751== Command: /home/jsynacek/work/2-upstream/openldap-git/servers/slapd/.libs/lt-slapd
> -Tt -f slapd-segfault.conf -F ./testconf
> ==6751==
> 51c1a34e bdb_db_open: database "dc=example,dc=com": unclean shutdown detected;
> attempting recovery.
> 51c1a34e bdb_db_open: warning - no DB_CONFIG file found in directory
> /var/lib/ldap: (2).
> Expect poor performance for suffix "dc=example,dc=com".
> 51c1a34e bdb_db_open: database "dc=example,dc=com": recovery skipped in
> read-only mode. Run manual recovery if errors are encountered.
> config file testing succeeded
> ==6751== Conditional jump or move depends on uninitialised value(s)
> ==6751==    at 0x519E9D: monitor_back_unregister_entry_attrs (init.c:1473)
> ==6751==    by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632)
> ==6751==    by 0x4F6F18: bdb_monitor_db_close (monitor.c:500)
> ==6751==    by 0x4EF0B3: bdb_db_close (init.c:595)
> ==6751==    by 0x454AD4: backend_shutdown (backend.c:383)
> ==6751==    by 0x4814A8: slap_shutdown (init.c:232)
> ==6751==    by 0x4DE90C: slap_tool_destroy (slapcommon.c:936)
> ==6751==    by 0x4E0434: slaptest (slaptest.c:116)
> ==6751==    by 0x41A9F4: main (main.c:665)
> ==6751==
> ==6751== Conditional jump or move depends on uninitialised value(s)
> ==6751==    at 0x5573EA: monitor_cache_get (cache.c:150)
> ==6751==    by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520)
> ==6751==    by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632)
> ==6751==    by 0x4F6F18: bdb_monitor_db_close (monitor.c:500)
> ==6751==    by 0x4EF0B3: bdb_db_close (init.c:595)
> ==6751==    by 0x454AD4: backend_shutdown (backend.c:383)
> ==6751==    by 0x4814A8: slap_shutdown (init.c:232)
> ==6751==    by 0x4DE90C: slap_tool_destroy (slapcommon.c:936)
> ==6751==    by 0x4E0434: slaptest (slaptest.c:116)
> ==6751==    by 0x41A9F4: main (main.c:665)
> ==6751==
> ==6751== Use of uninitialised value of size 8
> ==6751==    at 0x3385009B70: pthread_mutex_lock (in
> /usr/lib64/libpthread-2.16.so)
> ==6751==    by 0x4C2524C: ldap_pvt_thread_mutex_lock (thr_posix.c:296)
> ==6751==    by 0x5574B8: monitor_cache_get (cache.c:161)
> ==6751==    by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520)
> ==6751==    by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632)
> ==6751==    by 0x4F6F18: bdb_monitor_db_close (monitor.c:500)
> ==6751==    by 0x4EF0B3: bdb_db_close (init.c:595)
> ==6751==    by 0x454AD4: backend_shutdown (backend.c:383)
> ==6751==    by 0x4814A8: slap_shutdown (init.c:232)
> ==6751==    by 0x4DE90C: slap_tool_destroy (slapcommon.c:936)
> ==6751==    by 0x4E0434: slaptest (slaptest.c:116)
> ==6751==    by 0x41A9F4: main (main.c:665)
> ==6751==
> ==6751== Invalid read of size 4
> ==6751==    at 0x3385009B70: pthread_mutex_lock (in
> /usr/lib64/libpthread-2.16.so)
> ==6751==    by 0x4C2524C: ldap_pvt_thread_mutex_lock (thr_posix.c:296)
> ==6751==    by 0x5574B8: monitor_cache_get (cache.c:161)
> ==6751==    by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520)
> ==6751==    by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632)
> ==6751==    by 0x4F6F18: bdb_monitor_db_close (monitor.c:500)
> ==6751==    by 0x4EF0B3: bdb_db_close (init.c:595)
> ==6751==    by 0x454AD4: backend_shutdown (backend.c:383)
> ==6751==    by 0x4814A8: slap_shutdown (init.c:232)
> ==6751==    by 0x4DE90C: slap_tool_destroy (slapcommon.c:936)
> ==6751==    by 0x4E0434: slaptest (slaptest.c:116)
> ==6751==    by 0x41A9F4: main (main.c:665)
> ==6751==  Address 0x37 is not stack'd, malloc'd or (recently) free'd
> ==6751==
> ==6751==
> ==6751== Process terminating with default action of signal 11 (SIGSEGV)
> ==6751==  Access not within mapped region at address 0x37
> ==6751==    at 0x3385009B70: pthread_mutex_lock (in
> /usr/lib64/libpthread-2.16.so)
> ==6751==    by 0x4C2524C: ldap_pvt_thread_mutex_lock (thr_posix.c:296)
> ==6751==    by 0x5574B8: monitor_cache_get (cache.c:161)
> ==6751==    by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520)
> ==6751==    by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632)
> ==6751==    by 0x4F6F18: bdb_monitor_db_close (monitor.c:500)
> ==6751==    by 0x4EF0B3: bdb_db_close (init.c:595)
> ==6751==    by 0x454AD4: backend_shutdown (backend.c:383)
> ==6751==    by 0x4814A8: slap_shutdown (init.c:232)
> ==6751==    by 0x4DE90C: slap_tool_destroy (slapcommon.c:936)
> ==6751==    by 0x4E0434: slaptest (slaptest.c:116)
> ==6751==    by 0x41A9F4: main (main.c:665)
> ==6751==  If you believe this happened as a result of a stack
> ==6751==  overflow in your program's main thread (unlikely but
> ==6751==  possible), you can try to increase the size of the
> ==6751==  main thread stack using the --main-stacksize= flag.
> ==6751==  The main thread stack size used in this run was 8388608.
> ==6751==
> ==6751== HEAP SUMMARY:
> ==6751==     in use at exit: 1,784,260 bytes in 10,532 blocks
> ==6751==   total heap usage: 20,806 allocs, 10,274 frees, 4,333,045 bytes
> allocated
> ==6751==
> ==6751== LEAK SUMMARY:
> ==6751==    definitely lost: 16 bytes in 1 blocks
> ==6751==    indirectly lost: 0 bytes in 0 blocks
> ==6751==      possibly lost: 0 bytes in 0 blocks
> ==6751==    still reachable: 1,784,244 bytes in 10,531 blocks
> ==6751==         suppressed: 0 bytes in 0 blocks
> ==6751== Rerun with --leak-check=full to see details of leaked memory
> ==6751==
> ==6751== For counts of detected and suppressed errors, rerun with: -v
> ==6751== Use --track-origins=yes to see where uninitialised values come from
> ==6751== ERROR SUMMARY: 11 errors from 9 contexts (suppressed: 2 from 2)
>
> I'm not sure if my patch is correct. I feel it's more like a workaround, so feel
> free to modify it if that's the case.
>
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
Prev by Date: Re: (ITS#7628) back-mdb bug with test064-constraint
Next by Date: (ITS#7631) Overlay to rewrite value of attribute using regex
Index(es):
- Chronological
- Thread