Spam detection software, running on the system "fw2.vse.sk", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see postmaster for details. Content preview: Quoting Doug White <dwhite_at_gumbysoft.com>: > hey folks, > > Looks like the OpenLDAP server, slapd, and KSE don't get along too well. I may have missed the end of this thread, if I did I apologize. Is the above still an issue? [...] Content analysis details: (5.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.1 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [200.78.46.212 listed in dnsbl.sorbs.net] [200.95.35.233 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_NJABL_DIALUP RBL: NJABL: dialup sender did non-local SMTP [200.78.46.212 listed in dnsbl.njabl.org] 0.1 RCVD_IN_SORBS RBL: SORBS: sender is listed in SORBS [200.78.46.212 listed in dnsbl.sorbs.net] [200.95.35.233 listed in dnsbl.sorbs.net] 0.1 RCVD_IN_NJABL RBL: Received via a relay in dnsbl.njabl.org [200.78.46.212 listed in dnsbl.njabl.org] [200.95.35.233 listed in dnsbl.njabl.org] 1.1 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org [<http://dsbl.org/listing?ip=200.95.35.233>] 1.1 RCVD_IN_NJABL_PROXY RBL: NJABL: sender is an open proxy [200.78.46.212 listed in dnsbl.njabl.org] [200.95.35.233 listed in dnsbl.njabl.org] 1.1 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server [200.78.46.212 listed in dnsbl.sorbs.net] [200.95.35.233 listed in dnsbl.sorbs.net] Tato posta je pravdepodobne nevyziadana. Povodna sprava bola umiestnena do prilohy, aby ste mohli podobnu postu v buducnosti bezpecne rozpoznat. Ak chcete, aby tato posta bola automaticky mazana, nastavte si pravidla na postovom servri (navod najdete na http://vsedw.inet.vse.sk/dokumenty/rozne/help/antispam/antispam.htm ) UPOZORNENIE: nezverejnujte svoju e-mail adresu na internete Nahlad obsahu: ed > > I can reliably segfault slapd by doing a few requests of it on a -CURRENT > machine built this morning PST. TLS seems to accelerate things, but it > can be done without. I have this backtrace, with a debugging libpthread, > but I'm not sure how useful it is to you folks. > > This is 100% reproducible, although initially it was croaking in > pthread_testcancel() instead of a kse function. This leads me to suspect > strange mutex corruption, but I'd like someone who understands kse to at > least spot-check. > > I thought at first it might be some strange interaction between berkeley > db 4.2's special assembly mutexes and kse, but I rebuilt db42 with pthread > mutexes and rebuilt openldap to use DB_PRIVATE so the db would mount, but > no change in status. > > Here's the trace from gdb: > > #0 0x284374a7 in kse_release () at {standard input}:15 > #1 0x28431fed in kse_wait (kse=0x8102000, td_wait=0x0, sigseqno=0) > at /usr/src/lib/libpthread/thread/thr_kern.c:1816 > #2 0x28430485 in kse_sched_multi (kmbx=0x0) > at /usr/src/lib/libpthread/thread/thr_kern.c:1011 > #3 0x28434014 in _i386_enter_uts () at {standard input}:25 > #4 0x2842fa4e in _thr_sched_switch (curthread=0x8260000) > at /usr/src/lib/libpthread/thread/thr_kern.c:596 > #5 0x2842c905 in mutex_lock_common (curthread=0x8260000, m=0x810e304, > abstime=0x0) at /usr/src/lib/libpthread/thread/thr_mutex.c:555 > #6 0x2842d633 in __pthread_mutex_lock (m=0x810e304) > at /usr/src/lib/libpthread/thread/thr_mutex.c:796 > #7 0x2839634f in pthread_mutex_lock () from /lib/libc.so.5 > #8 0x281288b3 in ldap_pvt_thread_mutex_lock () > from /usr/local/lib/libldap_r.so.202 > #9 0x28127b23 in ldap_pvt_thread_pool_submit () > from /usr/local/lib/libldap_r.so.202 > #10 0x08059d23 in ldap_str2matchingrule () > #11 0x080599d5 in ldap_str2matchingrule () > #12 0x08059525 in ldap_str2matchingrule () > #13 0x08056fe5 in ldap_str2matchingrule () > #14 0x28425595 in thread_start (curthread=0x8260000, > start_routine=0x8055a4c <ldap_str2matchingrule+34120>, arg=0x0) > at /usr/src/l [...] Detaily vysledkov analyzy: (5.1 points, 5.0 required) 1.1 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [200.78.46.212 listed in dnsbl.sorbs.net] [200.95.35.233 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_NJABL_DIALUP RBL: NJABL: dialup sender did non-local SMTP [200.78.46.212 listed in dnsbl.njabl.org] 0.1 RCVD_IN_SORBS RBL: SORBS: sender is listed in SORBS [200.78.46.212 listed in dnsbl.sorbs.net] [200.95.35.233 listed in dnsbl.sorbs.net] 0.1 RCVD_IN_NJABL RBL: Received via a relay in dnsbl.njabl.org [200.78.46.212 listed in dnsbl.njabl.org] [200.95.35.233 listed in dnsbl.njabl.org] 1.1 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org [<http://dsbl.org/listing?ip=200.95.35.233>] 1.1 RCVD_IN_NJABL_PROXY RBL: NJABL: sender is an open proxy [200.78.46.212 listed in dnsbl.njabl.org] [200.95.35.233 listed in dnsbl.njabl.org] 1.1 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server [200.78.46.212 listed in dnsbl.sorbs.net] [200.95.35.233 listed in dnsbl.sorbs.net]
attached mail follows:
Quoting Doug White <dwhite_at_gumbysoft.com>:
> hey folks,
>
> Looks like the OpenLDAP server, slapd, and KSE don't get along too well.
I may have missed the end of this thread, if I did I apologize. Is the above
still an issue?
Thanks,
ed
>
> I can reliably segfault slapd by doing a few requests of it on a -CURRENT
> machine built this morning PST. TLS seems to accelerate things, but it
> can be done without. I have this backtrace, with a debugging libpthread,
> but I'm not sure how useful it is to you folks.
>
> This is 100% reproducible, although initially it was croaking in
> pthread_testcancel() instead of a kse function. This leads me to suspect
> strange mutex corruption, but I'd like someone who understands kse to at
> least spot-check.
>
> I thought at first it might be some strange interaction between berkeley
> db 4.2's special assembly mutexes and kse, but I rebuilt db42 with pthread
> mutexes and rebuilt openldap to use DB_PRIVATE so the db would mount, but
> no change in status.
>
> Here's the trace from gdb:
>
> #0 0x284374a7 in kse_release () at {standard input}:15
> #1 0x28431fed in kse_wait (kse=0x8102000, td_wait=0x0, sigseqno=0)
> at /usr/src/lib/libpthread/thread/thr_kern.c:1816
> #2 0x28430485 in kse_sched_multi (kmbx=0x0)
> at /usr/src/lib/libpthread/thread/thr_kern.c:1011
> #3 0x28434014 in _i386_enter_uts () at {standard input}:25
> #4 0x2842fa4e in _thr_sched_switch (curthread=0x8260000)
> at /usr/src/lib/libpthread/thread/thr_kern.c:596
> #5 0x2842c905 in mutex_lock_common (curthread=0x8260000, m=0x810e304,
> abstime=0x0) at /usr/src/lib/libpthread/thread/thr_mutex.c:555
> #6 0x2842d633 in __pthread_mutex_lock (m=0x810e304)
> at /usr/src/lib/libpthread/thread/thr_mutex.c:796
> #7 0x2839634f in pthread_mutex_lock () from /lib/libc.so.5
> #8 0x281288b3 in ldap_pvt_thread_mutex_lock ()
> from /usr/local/lib/libldap_r.so.202
> #9 0x28127b23 in ldap_pvt_thread_pool_submit ()
> from /usr/local/lib/libldap_r.so.202
> #10 0x08059d23 in ldap_str2matchingrule ()
> #11 0x080599d5 in ldap_str2matchingrule ()
> #12 0x08059525 in ldap_str2matchingrule ()
> #13 0x08056fe5 in ldap_str2matchingrule ()
> #14 0x28425595 in thread_start (curthread=0x8260000,
> start_routine=0x8055a4c <ldap_str2matchingrule+34120>, arg=0x0)
> at /usr/src/lib/libpthread/thread/thr_create.c:353
> #15 0x283e4807 in _ctx_start () from /lib/libc.so.5
>
>
> --
> Doug White | FreeBSD: The Power to Serve
> dwhite_at_gumbysoft.com | www.FreeBSD.org
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
_______________________________________________
freebsd-current_at_freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
Received on Mon Feb 23 2004 - 04:06:54 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:44 UTC