(ITS#5015) pcache caches results of aborted searches
by rhafer＠suse.de
Full_Name: Ralf Haferkamp
Version: RE23
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (89.166.165.45)
Pcache will store the results of a search that got aborted (e.g. by hitting
Ctrl+c during ldapsearch, oder using ldap_abandon) in it database. The next time
the some query is issued it will answer the query from the cache, resulting in a
incomplete result set.
HEAD doesn't show this problem. Applying the changes from result.c r.1.289 to
RE23 seems to fix this problem.
15 years, 9 months
RE: Native Win32 build with WGCC/Interix (ITS#4825)
by Markus.Duft＠salomon.at
Hi!
First thanks for reviewing the patch!
Howard Chu <mailto:openldap-its@OpenLDAP.org> wrote:
> I have not tested this patch, but it does not appear to be correct.
>
> In ldap_cdefs.h, you should not be testing the PIC macro since that
> controls whether the current source file is being built as
> position-independent. The macro you actually need to test is
> LDAP_LIBS_DYNAMIC, just as the regular WIN32 case tests. Note that
> the current macros work fine for both MSVC and MinGW/gcc; I don't see
> why you've chosen to change the LBER_F definitions for your wgcc.
Uh.. I'd have to look into that again ;o) Still this works fine since
some time now, and the libraries are under heavy usage at our company...
>
> Likewise, your hack to portable.hin should not be necessary, as all
> of the places that use sockets or timevals already include the
> appropriate header files.
Again, i'd have to look at this again...
>
> The patch to ure.h seems unnecessary, since the file exists at both
> locations (the original, and via symlink).
Smylinks are not supported when windows building on interix ;o// This
caused some troubles as far as i remember.
>
> Finally, unless you're using a flag to force all symbols to be
> exported, I think omitting slapd.exp in the slapd/Makefile.in is a
> mistake.
WGCC automatically exports/imports correctly.
>
> Really, the comments in ldap_cdefs.h are pretty explicit about why
> each piece of the current Windows support is as it is. Your patch
> seems to preclude some of the combinations of DLL/static linking that
> we went to great pains to support.
WGCC claims to support (with this patch) *all* possible static/shared
combinations (without pain ;o)). WGCC generates code to support static
libraries, even if it was compiled like a shared library (with
__declspec(dllimport)'s, etc.), so most of the painfull stuff is not
needed. On the other hand to support *all* configurations, one needs to
allway dllimport, so both shared and static work ...
>
> For the include/Makefile.in it would probably have made more sense to
> define a WINPATH macro to either "cygpath -w" or "unixpath2win" and
> use that, rather than repeating all of the SED invocations.
Yes, it would have been better, but it's a long time since i wrote the
patch, and now i'd propably do more things differently ;o)
>
> These days I wonder whether it wouldn't be smarter to just remove all
> of the special casing for braindead backslash directory separators.
> Since Windows now supports forward slashes everywhere, it would make
> life easier to just use forward slashes consistently throughout.
Would be cool, but still path handling functions from windows return
paths with backslashes, so those would need to be handled too..
Cheers, Markus
--
20. Juni 2007
Salomon Automation am 2. Schweizerischen Supply Chain Management Forum der GS1 Schweiz in Baden. Tagungsort: Trafohalle Baden, Schweiz
20. Juni 2007
MoveRetail-Handelstag, Hamburg
Die MoveRetail Partner, Salomon Automation, maxess systemhaus, Superdata, Remira, POS Systemhaus und Mosaic veranstalten den 1. MoveRetail-Handelstag.
Tagungsort: Steigenberger Hotel, Hamburg
28. Juni 2007
6. BVL Logistiktag Steiermark in der WAMAS City, Friesach bei Graz
"Trends in der Logistik ": hoch automatisierte Systeme, mobile Waren- und Leergutverfolgung im Lebensmittelhandel und Generalunternehmerschaft versus Einzelprojekte.
Termin: 28. Juni 2007, ab 15.00 Uhr
Ort: Salomon Automation, Friesachstra?e 15, 8114 Friesach bei Graz, Osterreich
Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz
15 years, 9 months
Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com
Hallvard B Furuseth wrote:
> hyc(a)symas.com writes:
>> h.b.furuseth(a)usit.uio.no wrote:
>>> * When a thread is finishing, make it go active for context_reset().
>>> Should make slapi module destructors safer, and I don't see that it
>>> can hurt.
>> I don't understand this.
>
> Let me dig a bit back in the ITS...
> "context_reset() can call connection_fake_destroy(), which via
> slapi_int_free_object_extensions() calls slapi module destructors,
> which can do who-knows-what."
context_reset() can only be called from the main thread. It can (must) never be
called by anything running from the pool.
>>> * Scheduling: If several threads call pool_pause(), then once there is a
>>> pause tpool does not schedule them all. They could get handled then,
>>> or another thread could undo the pause so tpool would wait to pause
>>> again. Is that deliberate?
>> I don't understand the question. The point of the pause is to prevent
>> any other thread (in the pool) from running. Why should tpool schedule
>> any other threads at this point?
>
> Two threads call pool_pause(). Eventually the pool gets paused, and one
> pool_pause() call returns. When that thread calls pool_resume(), the
> other thread waiting in pool_pause() may or may not get scheduled.
OK, that sounds like a bug.
>>> - pool_context() breaks if several ldap_pvt_thread_t bit patterns can
>>> represent the same thread ID: TID_HASH() would give different hashes
>>> for the same thread, and pool_context() stops searching when it hits
>>> a slot with ctx == NULL. (My previous bug report was a bit wrong.)
>> How can a single thread ID be represented by multiple bit patterns?
>
> A struct/union with padding bytes seems the least unlikely possibility.
Any implementation that leaves uninitialized padding bytes would be a bug.
Tools like valgrind would barf all over them.
> A pointer in hardware where several address representations map to the
> same physical address, and the compiler handles that by normalizing
> pointers when they are compared/subtracted. Like DOS "huge" pointers
> would have been if the compiler normalized them when comparing them
> instead of when incrementing/decrementing them. 20-bit address bus,
> 32-bit pointers, physical address = 16 * <segment half of pointer> +
> <offset half of pointer>.
Nobody voluntarily uses such memory models today. The very mention of "DOS"
invalidates this discussion since there is no threading environment there.
>>> The best fix would be to use use real thread-specific data instead.
>>> Just one key with the ctx for now, that minimizes the changes. OTOH
>>> it also means we'll do thread-specific key lookup twice - first in
>>> pthread to get the ctx, and then in ltu_key[] to find our data.
>>> Anyway, I said I'd do that later but might as well get on with it,
>>> at least for pthreads. Except I don't know if that's OS-dependent
>>> enough that it should wait for RE24?
>> The best fix may be to just use the address of the thread's stack as the
>> thread ID. That's actually perfect for our purpose.
>
> How does a function called from somewhere inside the thread know that
> address? That's almost what the user context is, and thus what
> thread_keys[] maps the thread ID to.
It requires some degree of machine-dependence, which is why I never bothered to
code it. The principle is simple though - all of our thread stacks are some
multiple of 1MB in size. Take the address of any local variable, mask off the
low 20 bits, and you have a unique thread ID (+/- some additional
masking/shifting based on the actual thread stack size).
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 9 months
Re: (ITS#4983) libldap_r/tls.c compile failure
by h.b.furuseth＠usit.uio.no
I wrote:
> For whatever isn't handled above, my suggestion for now is to keep the
> failure if ldap_pvt_thread_t is a struct/union or wider than long, and
> see if anyone still complains.
Done. Compiles unless pointers are wider than long, but the basic
problem remains.
--
Regards,
Hallvard
15 years, 9 months
(ITS#5014) syncrepl failure syslog
by donn＠u.washington.edu
Full_Name: Donn Cave
Version: 2.4.4
OS: Red Hat RHEL 3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (128.95.135.150)
Hard to tell why syncrepl isn't working, if it discards error messages.
*** servers/slapd/syncrepl.c.dist 2007-02-15 17:53:39.000000000 -0800
--- servers/slapd/syncrepl.c 2007-06-12 13:35:22.000000000 -0700
***************
*** 688,694 ****
struct sync_cookie syncCookie_req = { NULL };
struct berval cookie = BER_BVNULL;
! int rc, err;
ber_len_t len;
struct berval *psub;
--- 688,694 ----
struct sync_cookie syncCookie_req = { NULL };
struct berval cookie = BER_BVNULL;
! int rc, err, rrc;
ber_len_t len;
struct berval *psub;
***************
*** 704,709 ****
--- 704,710 ----
BerVarray syncUUIDs = NULL;
ber_tag_t si_tag;
+ rrc = LDAP_SUCCESS;
if ( slapd_shutdown ) {
rc = -2;
goto done;
***************
*** 727,732 ****
--- 728,734 ----
while ( ( rc = ldap_result( si->si_ld, LDAP_RES_ANY, LDAP_MSG_ONE,
tout_p, &res ) ) > 0 )
{
+ ldap_parse_result( si->si_ld, res, &rrc, 0, 0, 0, 0, 0 );
if ( slapd_shutdown ) {
rc = -2;
goto done;
***************
*** 1061,1066 ****
--- 1063,1076 ----
}
done:
+ if ( rrc != LDAP_SUCCESS ) {
+ const char *errstr;
+ ldap_get_option( si->si_ld, LDAP_OPT_ERROR_NUMBER, &rrc );
+ errstr = ldap_err2string( rrc );
+
+ Debug( LDAP_DEBUG_ANY,
+ "syncrepl %s result: %s\n", si->si_ridtxt, errstr, 0 );
+ }
slap_sync_cookie_free( &syncCookie, 0 );
slap_sync_cookie_free( &syncCookie_req, 0 );
15 years, 9 months
Re: (ITS#4996) Use SRV records to locate local server for command-line clients
by rra＠stanford.edu
ando <ando(a)sys-net.it> writes:
> Committed to HEAD. Command-line clients now use DNS SRV to look up the
> host names related to a DN and build a list of URIs for subsequent use.
> To trigger, use -H "<proto>:///DN". The <host> portion must be empty,
> and a DN must be present. The DN must be in the "dc=<component>" form;
> it's turned into a domain and the host list is looked up using DNS SRV.
> After that, a list of URIs is built using the returned host/ports, and
> using <proto> as the LDAP scheme.
Thank you! I've forwarded this information to the original Debian bug
reporter who was interested in the feature in the hopes that he'll be able
to test and provide feedback on the implementation.
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
15 years, 9 months
Re: (ITS#5011) loglevel packet doesn't work
by ando＠sys-net.it
ando(a)sys-net.it wrote:
> ... it's "packets". The man page (or the code) is wrong.
... but the man page is correct in HEAD; so it was fixed, but not
backported.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 9 months
Re: (ITS#5011) loglevel packet doesn't work
by ando＠sys-net.it
quanah(a)zimbra.com wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.3.35
> OS: mac os x
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (66.92.25.194)
>
>
> The slapd.conf man page says:
>
> loglevel <integer> [...]
> 2 (0x2 packet) debug packet handling
>
> but if you specify packet, slapd refuses to start, stating:
>
> /opt/zimbra/openldap-2.3.35.7/etc/openldap/slapd.conf: line 53: <loglevel>
> unknown level "packet"
... it's "packets". The man page (or the code) is wrong.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 9 months
(ITS#5011) loglevel packet doesn't work
by quanah＠zimbra.com
Full_Name: Quanah Gibson-Mount
Version: 2.3.35
OS: mac os x
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (66.92.25.194)
The slapd.conf man page says:
loglevel <integer> [...]
2 (0x2 packet) debug packet handling
but if you specify packet, slapd refuses to start, stating:
/opt/zimbra/openldap-2.3.35.7/etc/openldap/slapd.conf: line 53: <loglevel>
unknown level "packet"
--Quanah
15 years, 9 months
