Bug 288291

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.