See <http://jenkins.cloud.fedoraproject.org/job/389-ds-base/348/>
------------------------------------------
Started by an SCM change
Building remotely on Fedora20 in workspace <http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/>
Wiping out workspace first.
Cloning the remote Git repository
Cloning repository http://git.fedorahosted.org/git/389/ds.git/
Fetching upstream changes from http://git.fedorahosted.org/git/389/ds.git/
ERROR: Timeout after 10 minutes
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git fetch --tags --progress http://git.fedorahosted.org/git/389/ds.git/ +refs/heads/*:refs/remotes/origin/*" returned status code 143:
stdout:
stderr:
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1276)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1146)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:87)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:254)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:410)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:328)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
ERROR: null
There are still scenarios where replication can lead to inconsistent
states for single valued attributes, which I think has two reasons:
- for single valued attributes there are scenarios where modifications
applied concurrently cannot be simply resolved without violating the schema
- the code to handle single valued attribute resolution is quite complex
and has always been extended to resolve reported issues, not making it
simpler
I tried to specify all potential scenarios which should be handled and
what the expected consistent state should be. In parallel writing a test
suite based on lib389 test framework to provide testcases for all
scenarios and then test the current implementation. The doc and test
suite can be used as a reference for a potential rework of the update
resolution code.
Please have a look at:
http://port389.org/wiki/Update_resolution_for_single_valued_attributes
comments, corrections, additonal requirements are welcome - the doc is
not final :-)
Thanks,
Ludwig
https://fedorahosted.org/389/ticket/47707https://fedorahosted.org/389/attachment/ticket/47707/0001-Ticket-47707-389-…
Bug Description: If a simple paged search request was sent to the server
and the request was abandoned, the paged result slot in the connection
table was not properly released by setting NULL to pr_current_be. Since
the slot did not look available for the next request even though it was,
the next request failed to get the valid slot number, and the initial slot
number -1 failed to be replaced with the real slot number. Until the fix
for "Ticket #47623 fix memleak caused by 47347" was made, it overrode the
allocated array's [-1] location, which usually stores the meta data of the
allocated memory. That crashed the server in the next realloc since the
corrupted memory was passed to the function.
Fix Description: This patch cleans up the abandoned/cleaned up slot for
reuse. Also, more check not to break the meta data is added.
Special thanks to German Parente (gparente(a)redhat.com) for providing the
reproducer and analysing the crash.