https://bugzilla.redhat.com/show_bug.cgi?id=967719
Bug ID: 967719 Summary: Segfault in Perl_gv_fetchpvn_flags when trying to initialize back_perl openldap backend Product: Fedora Version: 19 Component: perl Severity: unspecified Priority: unspecified Assignee: mmaslano@redhat.com Reporter: jsynacek@redhat.com QA Contact: extras-qa@fedoraproject.org CC: cweyl@alumni.drew.edu, iarnell@gmail.com, jplesnik@redhat.com, kasal@ucw.cz, lkundrak@v3.sk, mmaslano@redhat.com, perl-devel@lists.fedoraproject.org, ppisar@redhat.com, psabata@redhat.com, rc040203@freenet.de, tcallawa@redhat.com
Created attachment 753756 --> https://bugzilla.redhat.com/attachment.cgi?id=753756&action=edit Reproducer pack
Description of problem: When trying to initialize back_perl, a segfault occurs deep in perl itself.
Version-Release number of selected component (if applicable): perl-5.16.3-264.fc19.x86_64 openldap-2.4.35-4.fc19.x86_64
How reproducible: Almost always.
Steps to Reproduce: 1. Install fresh F19 2. If you try the reproducer here, all goes well 3. yum install perl-A* (I have no idea why I needed to do this to get it to segfault) 4. Try reproducer 5. Observe the segfault 6. From now on, reproducer works *without* producing any segfaults. I had to reboot the machine to be able to reproduce the issue again.
Note on how to use the reproducer: 1. Unpack 2. Run go.sh (warning: it will wipe your /var/lib/ldap/* and your /etc/openldap/*, so don't run if you use openldap in production) This will run slapd in debug mode, so you will need another console to run the rest. 3. Run try.sh 4. If you want to repeat, go to 2.
You can modify go.sh to run slapd through a debugger. However, you will probably need to set LD_PRELOAD=/usr/lib64/perl5/CORE/libperl.so to be able to run try.sh.
Actual results: Perl segfaults.
Expected results: The back_perl gets initialized without any problems.
Additional info: This also happens on my production F18, but it happens always. It looks like it might have something to do with Bug 960048.
https://bugzilla.redhat.com/show_bug.cgi?id=967719
--- Comment #1 from Jan Synacek jsynacek@redhat.com --- Created attachment 753757 --> https://bugzilla.redhat.com/attachment.cgi?id=753757&action=edit full backtrace during the crash
Note that in the frame #3, the my_perl variable changes from a (probably valid) pointer to 0x0.
https://bugzilla.redhat.com/show_bug.cgi?id=967719
--- Comment #2 from Petr Pisar ppisar@redhat.com --- What's expected output on the client site?
I have patched perl so that it links all XS modules to libperl.so explicitly in my private F20 machine, and I do not get any segfaults. Instead I just get an error message from the second command:
$ sh try.sh SASL/EXTERNAL authentication started SASL username: gidNumber=500+uidNumber=500,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=module,cn=config" ldap_add: Insufficient access (50)
SASL/EXTERNAL authentication started SASL username: gidNumber=500+uidNumber=500,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase=perl,cn=config" ldap_add: Invalid syntax (21) additional info: objectClass: value #1 invalid per syntax
I guess this is how to should work.
If this is the real fix, than this issue will be fixed in F20.
https://bugzilla.redhat.com/show_bug.cgi?id=967719
--- Comment #3 from Jan Synacek jsynacek@redhat.com --- All LDAP operations should succeed without any errors. You don't have sufficient access rights to modify the LDAP database. Running the script as root should do it.
You should see something like this: # ./try.sh SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=module,cn=config"
SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase=perl,cn=config" ldap_result: Can't contact LDAP server (-1)
The last line indicates the termination (you can see that slapd segfaulted in the console where you ran go.sh). Expected output would look like the one above minus the 'ldap_result: ...' line. Plus there may be one additional 'adding new entry' line.
https://bugzilla.redhat.com/show_bug.cgi?id=967719
--- Comment #4 from Petr Pisar ppisar@redhat.com --- I run it as a non-root. I get much better results as a root:
# ./try.sh SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=module,cn=config"
SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase=perl,cn=config"
adding new entry "dc=perl-example,dc=com"
However the server sometimes segfaults as you reported.
https://bugzilla.redhat.com/show_bug.cgi?id=967719
--- Comment #5 from Jan Synacek jsynacek@redhat.com --- (In reply to Petr Pisar from comment #4)
I run it as a non-root. I get much better results as a root:
Yes, that's how the output is supposed to look.
However the server sometimes segfaults as you reported.
Ok, it's strange that it segfaults only sometimes. Does this mean that you can reproduce it even with all the perl modules linked to libperl.so explicitly?
https://bugzilla.redhat.com/show_bug.cgi?id=967719
--- Comment #6 from Petr Pisar ppisar@redhat.com --- I recompiled only modules in perl binary package and openldap for the test. Not yet all modules that exist. I also reverted the RTLD_GLOBAL patch and checked slapd does not crashes on linkage error. So the test does not use any not-yet-rebuild modules.
I conclude this issue is independent on the linking bug #960048. But we will see more after rebuilding everything.
https://bugzilla.redhat.com/show_bug.cgi?id=967719
Fedora Admin XMLRPC Client fedora-admin-xmlrpc@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|mmaslano@redhat.com |jplesnik@redhat.com
--- Comment #7 from Fedora Admin XMLRPC Client fedora-admin-xmlrpc@redhat.com --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
https://bugzilla.redhat.com/show_bug.cgi?id=967719
Howard Chu hyc@symas.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hyc@symas.com
--- Comment #8 from Howard Chu hyc@symas.com --- Please also followup to OpenLDAP ITS#7573 with any conclusions you reach, thanks.
https://bugzilla.redhat.com/show_bug.cgi?id=967719
Jan Synacek jsynacek@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- External Bug ID| |OpenLDAP ITS 7573
https://bugzilla.redhat.com/show_bug.cgi?id=967719
--- Comment #9 from Jan Synacek jsynacek@redhat.com --- This problem still occurs in F20.
https://bugzilla.redhat.com/show_bug.cgi?id=967719
Jan Synacek jsynacek@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1054061
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1054061 [Bug 1054061] Segfault in Perl_gv_fetchpvn_flags when trying to initialize back_perl openldap backend
https://bugzilla.redhat.com/show_bug.cgi?id=967719
Petr Pisar ppisar@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|1054061 |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1054061 [Bug 1054061] Segfault in Perl_gv_fetchpvn_flags when trying to initialize back_perl openldap backend
https://bugzilla.redhat.com/show_bug.cgi?id=967719
--- Comment #10 from Fedora End Of Life endoflife@fedoraproject.org --- This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
https://bugzilla.redhat.com/show_bug.cgi?id=967719
Fedora End Of Life endoflife@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |EOL Last Closed| |2015-02-17 10:21:22
--- Comment #11 from Fedora End Of Life endoflife@fedoraproject.org --- Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug.
Thank you for reporting this bug and we are sorry it could not be fixed.
perl-devel@lists.fedoraproject.org