Currently I'm trying to reproduce this in the test environment, but it
will take some time. Are you getting the same error using regular user
account (with sufficient rights to move an object) and directory
manager?
On Wed, 2012-11-14 at 16:56 +0100, Ludwig Krispenz wrote:
On 11/14/2012 04:39
On 11/14/2012 02:05 AM, Vladimir Elisseev wrote:
Obviously, I've tried ldapmodify and, as expected, it ends with an
error, no segfaults. However, I just tried
ldapmodrdn -r -h localhost -p 389 -D cn=xxx -W
cn=0207,ou=1,ou=Users,ou=132252,ou=Tenants,dc=CIDS
I wasn't able to reproduce this segfault using CentOS:
Name: 389-ds-base
Arch: x86_64
Version : 1.2.9.14
Release : 1.el6
However, when I updated to
Name: 389-ds-base
Arch: x86_64
Version : 1.2.10.2
Release : 20.el6_3
I've got the same segfault.
Here is the full stacktrace of this segfault: http://pastebin.com/ReqQU3mM
Regards,
Vlad.
--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
Hello,
First of all I'd say that most likely this segfault is a result of
badly designed application and/or bad coding. The segfault occurs while
this application tries to move an entry to non-existing LDAP container.
Unfortunately I don't have access to the source code of this app. The
segfault
(2012/11/13 05:22), Rich Megginson wrote:
On 11/13/2012 03:30 AM, Vladimir Elisseev wrote:
Hello,
First of all I'd say that most likely this segfault is a result of
badly designed application and/or bad coding. The segfault occurs while
this application tries to move an entry to non-existing
Edward Z. Yang wrote:
Excerpts from Rich Megginson's message of Fri Oct 08 18:59:52 -0400 2010:
Try running with the SHELL (1024) debug error log level. This should
give more information about the principal, keytab, etc. that directory
server is using.
More logs:
Done.
https://bugzilla.redhat.com/show_bug.cgi?id=642046
Cheers,
Edward
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
Excerpts from Rich Megginson's message of Fri Oct 08 18:59:52 -0400 2010:
Try running with the SHELL (1024) debug error log level. This should
give more information about the principal, keytab, etc. that directory
server is using.
More logs:
[09/Oct/2010:04:29:48 -0400] - Listening on
Edward Z. Yang wrote:
After manually attaching GDB, we caught a segfault on one of the dirsrvs. The
server's name is old-faithful. Here's the backtrace (with one set of
debugging
info missing; I can grab that and reload the core dump if you want me to.)
File a bug, or do you think it's an
Ok, I backtraced the coredump, the problem was in /usr/lib64/libssl3.so.
I updated from nss-3.12.6-1.el5_4.x86_64 to nss-3.12.7-2.el5.x86_64
and now all seems to work fine!
Thank you.
Regards,
Dael Maselli.
On 08/09/10 15.16, Rich Megginson wrote:
Dael Maselli wrote:
It worked!
I
Dael Maselli wrote:
Ok, I backtraced the coredump, the problem was in /usr/lib64/libssl3.so.
I updated from nss-3.12.6-1.el5_4.x86_64 to
nss-3.12.7-2.el5.x86_64 and now all seems to work fine!
Thanks, good to know.
Thank you.
Regards,
Dael Maselli.
On 08/09/10 15.16, Rich
Excerpts from Rich Megginson's message of Mon Sep 20 11:37:32 -0400 2010:
What platform? What version of 389-ds-base? Can you install the
389-ds-base-debuginfo package?
You will have to enable the directory server to produce a core dump.
1) edit /etc/sysconfig/dirsrv-instancename - add
Edward Z. Yang wrote:
Excerpts from Rich Megginson's message of Mon Sep 20 11:37:32 -0400 2010:
What platform? What version of 389-ds-base? Can you install the
389-ds-base-debuginfo package?
You will have to enable the directory server to produce a core dump.
1) edit
Excerpts from Rich Megginson's message of Mon Sep 20 11:37:32 -0400 2010:
What platform? What version of 389-ds-base? Can you install the
389-ds-base-debuginfo package?
Platform: Fedora 11 (yes, I know it's EOL'd, we're migrating this weekend)
[r...@pancake-bunny etc]# ns-slapd --version
Edward Z. Yang wrote:
We've had ns-slapd segfault on us recently twice; we don't have
a core dump (since the daemon script turns off core dumps, but
hopefully we'll have one next time it happens) and I was wondering
if anyone had seen this before:
ns-slapd[2725]: segfault at 10a310af ip
Excerpts from Rich Megginson's message of Mon Sep 20 09:19:50 -0400 2010:
ns-slapd[2725]: segfault at 10a310af ip 003d58c95785 sp
7ff2abf04040 error 4 in libcrypto.so.0.9.8n[3d58c0+15b000]
ns-slapd[2727]: segfault at 10a310af ip 003d58c95785 sp
7ff2aab02040
On Tuesday 07 September 2010 17:25:05 Dael Maselli wrote:
.. I can simulate a crash with kill -QUIT.
maybe the sleep command doesn't trap this signal, thus generating a core file
like in # man 7 signal.
But if I kill -QUIT ns-slapd no file is created.
slapd will trap the QUIT and treat it as
It worked!
I wrote fs.suid_dumpable=1 in /etc/sysctl.conf, `sysctl -p` and
restarted dirsrv. Now it dumps.
Thank you!
I will report here the backtrace when it occurs.
Regards,
Dael Maselli.
On 07/09/10 19.44, Ulf Weltman wrote:
On 9/7/2010 8:25 AM, Dael Maselli wrote:
Hi Rich,
Hi Rich,
On 07/09/10 16.56, Rich Megginson wrote:
Do you see seg fault messages in /var/log/messages?
Sure: ns-slapd[13737]: segfault at 00bc rip 003abb420375
rsp 580d85d0 error 4
The directory server dumps core in the log file directory, which by
default is
...@lists.fedoraproject.org] On Behalf Of Rich Megginson
Sent: Tuesday, September 07, 2010 10:56 AM
To: General discussion list for the 389 Directory server project.
Subject: Re: [389-users] Segfault Core Dumps
Dael Maselli wrote:
Hi,
I'm experiencing a lot of segmentation fault on my installations, I
have
Dael Maselli wrote:
Hi,
I'm experiencing a lot of segmentation fault on my installations, I have
the latest release on EPEL on SL 5.4 (389-Directory/1.2.5 B2010.012.2034).
Do you see seg fault messages in /var/log/messages?
I'm trying to get core dumps but without success. Is there a
On 9/7/2010 8:25 AM, Dael Maselli wrote:
Hi Rich,
On 07/09/10 16.56, Rich Megginson wrote:
Do you see seg fault messages in /var/log/messages?
Sure: ns-slapd[13737]: segfault at 00bc rip 003abb420375
rsp 580d85d0 error 4
The directory server dumps core in the log
Hi,
I'm experiencing a lot of segmentation fault on my installations, I have
the latest release on EPEL on SL 5.4 (389-Directory/1.2.5 B2010.012.2034).
I'm trying to get core dumps but without success. Is there a specific
configuration that prevents/allows 389-ds to core dump?
The default on
24 matches
Mail list logo
