Re: slapi_ldap_init segmentation fault

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/17/2013 06:15 PM, Russell Beall wrote:
Hi,

I am trying to port a plugin from our Sun DS to 389.  I worked through a number of API differences and got it to compile.  When I tried to run a test I keep getting segmentation faults in the pthread library regardless of how I compile or link the code.  I boiled it down to the following single line-item code which produces the crash:

int main (int argc, char **argv)
{
	 LDAP *ld = slapi_ldap_init( ldaphost, 389, 0, 1);
}

The stack trace is this:

#0  0x0000003c61009220 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1  0x0000003dd3c240b9 in PR_Lock () from /lib64/libnspr4.so
#2  0x0000003dd70ae6b8 in set_snmp_interaction_row ()
    from /usr/lib64/dirsrv/libslapd.so.0
#3  0x0000003dd7066771 in slapi_ldap_init_ext () from /usr/lib64/dirsrv/libslapd.so.0
#4  0x000000000040065f in main (argc=<value optimized out>,
     argv=<value optimized out>) at basictest_crash.c:22

This is under RedHat 6 and this version of the directory:
         389-Directory/1.2.11.23 B2013.275.1555

I had a much longer email here until I dug into the server code where the crash occurs.  I found that when running the plugin code independently of the server, the snmp_collator code was not initialized and a thread mutex was still NULL when attempting to lock it.  I hacked in this to force initialization:

diff ~/Downloads/389-ds-base-1.2.11.23/ldap/servers/slapd/snmp_collator.c ~/Downloads/389-ds-base-1.2.11.23-modified/ldap/servers/slapd/snmp_collator.c
239a240
   if (! interaction_table_mutex) interaction_table_mutex = PR_NewLock();
Linking against the hacked libslapd.so causes my test to function.

So… I've basically figured out what I needed to know by deep hacking, but I thought I should go ahead and post this in case it might be useful for discussion and possible patching.

When developing this plugin for Sun DS I worked with a locally executable version for testing as well as with it installed in the server.  It would definitely be useful to continue being able to develop independently of the server without always having to plug it in to test.

Yeah, the plugin system was not designed to be run standalone. Please file a ticket at https://fedorahosted.org/389/newticket

Regards,
Russ.
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users





[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux