assume you have: ou=neighborhood |- ou=houses all have the objectclass of nsview ou=neighborhood - has NO attribute nsviewfilter ou=houses - has an attribute nsviewfilter of: nsviewfilter: kentucky as soon as you add an object IN ou=houses, the server will crash and restarting it will NOT recover the database Notice that nsviewfilter expects: nsviewfilter: attribute=value In my example: nsviewfilter: value
Created attachment 224951 [details] diffs
Created attachment 225791 [details] cvs commit log Reviewed by: nhosoi (Thanks!) Fix Description: I could not reproduce the problem by simply adding the bogus nsviewfilter. The server seemed to run fine, but I didn't stress it. However, if I restarted the server, the server would core during startup. The last message in the error log would say something about recovering the database, which is probably why the bug reporter said that it will not recover the database. The problem doesn't appear to be with views specifically, but with any internal search which uses the search_internal_callback_pb() (as opposed to the non callback internal search) and there are search base rewriters (such as the views code). The aci code uses this type of search at startup to find the acis, and that's where I saw the crash. I could crash the server at startup regardless of whether the view filter was bogus or not. The problem is that we are not passing in the address of new_base to slapi_ch_free. The fix is to use slapi_ch_free_string and pass in the address of the string. That fixes the crash. I also cleaned up a few places in the views code which was not checking to see if slapi_str2filter returned NULL, which would happen in the case of the bogus search filter. I also added an error message which will tell the user that filter X in entry Y is bogus. Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no
*** Bug 359261 has been marked as a duplicate of this bug. ***
Created attachment 261051 [details] add operation add operation under a nsview ou
Created attachment 261061 [details] delete operation delete operation under nsview ou
Comment on attachment 261051 [details] add operation Still crashing after patching "views" and "replication" plugins. I tryed to apply ldbm patch reported in bug #359261, but i'm not able to compile entire server on CentOS 5. Ex: gmake[2]: se ingresa al directorio `/build/fds104/files/fedora-ds-1.0.4/config' syntax error at -e line 3, near "while" syntax error at -e line 7, near "}" Execution of -e aborted due to compilation errors. Environment: FDS 1.0.4, CentOS 5, GCC 4.1.1, Perl 5.8.8, GNU Make 3.81 Scenario: * View forest under o=my site, dc=my org, dc=es * Many MultiMaster Replications with other sites. Procedure: * Add "plonk" ou _without_ nsview objectclass under level 2 view (att. id 261051) * Delete "plonk" (att. id 261061) Test cases: * Does not crash without MMR's * Does not crash if "plonk" has nsview objetClass. I would appreciate any suggestions on build/compile requirements. Regards.
(In reply to comment #11) > (From update of attachment 261051 [details] [edit]) > Still crashing after patching "views" and "replication" plugins. You mean, this patch - https://bugzilla.redhat.com/attachment.cgi?id=224951&action=diff ? because this patch (the only patch on this bug is for views and the internal server plugin code, not replication. > > I tryed to apply ldbm patch reported in bug #359261, ? there is no patch in bug 359261? > but i'm not able to > compile entire server on CentOS 5. Ex: > gmake[2]: se ingresa al directorio `/build/fds104/files/fedora-ds-1.0.4/config' > syntax error at -e line 3, near "while" > syntax error at -e line 7, near "}" > Execution of -e aborted due to compilation errors. So were you able to apply the patch attached to this bug and recompile? > > Environment: FDS 1.0.4, CentOS 5, GCC 4.1.1, Perl 5.8.8, GNU Make 3.81 > Scenario: > * View forest under o=my site, dc=my org, dc=es > * Many MultiMaster Replications with other sites. > Procedure: > * Add "plonk" ou _without_ nsview objectclass under level 2 view (att. id > 261051) > * Delete "plonk" (att. id 261061) > > Test cases: > * Does not crash without MMR's > * Does not crash if "plonk" has nsview objetClass. > > I would appreciate any suggestions on build/compile requirements. I'm not sure. You should just be able to apply the patches and rebuild using the one step build method. That is, if you were able to build before, I'm not sure why applying any of these patches would alter your ability to build at all. Also, it would be very helpful if you could attach some ldif examples of entries which cause the server to crash. > > Regards. >
(In reply to comment #12) > You mean, this patch - > https://bugzilla.redhat.com/attachment.cgi?id=224951&action=diff > ? because this patch (the only patch on this bug is for views and the internal > server plugin code, not replication. I referred to this one: https://bugzilla.redhat.com/attachment.cgi?id=231611 > So were you able to apply the patch attached to this bug and recompile? Not directly. I had to rewrite Makefiles of the plugin subsystem and link against (db4, etc.) libraries built in the working part of "one step building". > I'm not sure. You should just be able to apply the patches and rebuild using > the one step build method. That is, if you were able to build before, I'm not > sure why applying any of these patches would alter your ability to build at all. The one step build fails for me in the same way as manual method. Maybe it could be a really simple command version dependency, but i was unable to trace it. There are tons of portability scripts in the core to obtain a successfull compilation without a reasonable waste of time. > Also, it would be very helpful if you could attach some ldif examples of entries > which cause the server to crash. I will post that soon. Thank you very much.
(In reply to comment #13) > (In reply to comment #12) > > You mean, this patch - > > https://bugzilla.redhat.com/attachment.cgi?id=224951&action=diff > > ? because this patch (the only patch on this bug is for views and the internal > > server plugin code, not replication. > > I referred to this one: > https://bugzilla.redhat.com/attachment.cgi?id=231611 That issue is not related to the views crashing problem. > > > So were you able to apply the patch attached to this bug and recompile? > > Not directly. I had to rewrite Makefiles of the plugin subsystem and link against (db4, etc.) libraries built > in the working part of "one step building". I see. The one step build procedure does not allow you to rebuild individual plugins. You basically have to rebuild the entire ldapserver. The way you do this is to rm -rf dsbuild-fds104/ds/ldapserver/cookies/build-work rm -rf dsbuild-fds104/ds/ldapserver/cookies/install-custom rm -rf dsbuild-fds104/ds/ldapserver/work/fedora-ds-1.0.4/built Then you should be able to do the one step build again. The one step build Makefile adds all of the dependencies for db4 etc. > > > I'm not sure. You should just be able to apply the patches and rebuild using > > the one step build method. That is, if you were able to build before, I'm not > > sure why applying any of these patches would alter your ability to build at all. > > The one step build fails for me in the same way as manual method. Maybe it could be a really simple > command version dependency, but i was unable to trace it. There are tons of portability scripts in the > core to obtain a successfull compilation without a reasonable waste of time. Fedora DS 1.1 uses standard autotools for building - no more one step build. > > > Also, it would be very helpful if you could attach some ldif examples of entries > > which cause the server to crash. > > I will post that soon. > > Thank you very much. >
Created attachment 263091 [details] crashing demo schema This is the shema which makes the system crash for us. OS Parameters: core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited max nice (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 4096 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 131072 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 max rt priority (-r) 0 stack size (kbytes, -s) 1024 cpu time (seconds, -t) unlimited max user processes (-u) 4096 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Note: I suspected (before i saw 1.0.4) sources, than the current rpm compilation (our base of tests) had solved the memory-free-issue (I see that fixed nor the plugin, so i recompiled only the plugin subsystem). My apologies if i was wrong.
Thanks. I'm not able to reproduce the crash with Fedora DS 1.1. These were the steps I took: 1) setup a server m1 as a replication master with the suffix dc=company,dc=com 2) setup a server m2 also as a replication master with the suffix dc=company,dc=com 3) did a replica init of m2 from m1 4) using ldapadd, add the dc=company,dc=com data you supplied to m1 5) using ldapsearch, verify that the data was replicated to m2 6) restarted both servers - both servers were running - no crash I also used a database import instead of ldapadd - works ok. So at this point I'm not sure what's happening: 1) Did I follow all of the steps to correctly reproduce the problem? Note that I did not use your configuration dse.ldif - I didn't see anything obvious in it that would cause a problem 2) Exactly what patches did you apply to Fedora DS 1.0.4? I'd like to verify them.
I followed your instructions and finally i was able to complete the one step build. I have applied patch id #224951 and also https://bugzilla.redhat.com/attachment.cgi?id=263531 (this second needed for us, so we have about hundreds of replications agreements), It works, and appears not to crash any more before deleting OUs. I'm sorry by the disadvantage.
(In reply to comment #17) > I followed your instructions and finally i was able to complete the one step build. Great! > > I have applied patch id #224951 and also https://bugzilla.redhat.com/attachment.cgi?id=263531 (this > second needed for us, so we have about hundreds of replications agreements), > > It works, and appears not to crash any more before deleting OUs. Excellent. Please let me know (via the fedora-directory-users list) if you have any problems with that replication patch. > > I'm sorry by the disadvantage. No, quite all right. I'm just glad we were able to verify that the original patch did fix the crashing problem.