When reporting bugs against Fedora, the BugsAndFeatureRequests wiki page is a great place to get some information on the kind of things you can do to provide useful information in the bug report.
I've just added a page on reporting virtualization bugs. Hopefully it'll help people find narrow down bugs, log files, get debug spew etc.
And, of course, it's a wiki page - so go ahead and add your own tips!
I've posted description to the Fedora wiki about how we're implementing the cached client part of Stateless Linux in FC6.
Pile onto the stateless-list if you want to yak about it.
Yesterday I posted some code which shows how to use Fedora Directory Server's "persistent searches" using OpenLDAP's client library. Here's that same code, but as a Python module.
Figuring out what the story is with LDAP notifications isn't terribly easy. There are a number of different protocol extensions out there:
The strangest thing about all this is that LCUP is the only one of these that progressed from Internet Draft to RFC, yet neither OpenLDAP nor Fedora Directory Server implement it. SYNC seems to have been proposed by the OpenLDAP crew because when they went to implement LCUP they found that it "requires server implementations to maintain complete history information in order to provide eventually convergent incremental refreshes", which presumably wasn't something that OpenLDAP already did. Yet the working group went ahead and progressed LCUP to RFC and not SYNC.
Anyway, moral of the story is that if you want notifications, then you want PSEARCH if you're using Fedora Directory Server and SYNC if you're using OpenLDAP.
If you're using OpenLDAP's client library, rather than the Mozilla LDAP C SDK, then it's a little tricky since you have to manually create the psearch control and parse the entryChange controls. Here's some example code.
The most interesting little tidbit I learnt from the memory usage
debugging
yesterday was
about the "stack guard page". Look at this bit in the strace:
mmap2(NULL, 10489856, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7219000
mprotect(0xb7219000, 4096, PROT_NONE) = 0
clone(child_stack=0xb7c194c4, flags=CLONE_VM|...) = 2282
What's going on here is that libc is mapping an area for the thread's
stack, just before spawning thread. The interesting bit is that, using
mprotect(), it also changes the permissions on the first page
(the page at the top of the stack) such that any instruction which
attempts to write to the page will cause a segmentation fault.
That's your stack guard page; it means that your infinitely recursing
function won't go off an scribble over its neighbouring thread's stack,
it'll just segfault like a good little thread.
(In true pthreads tradition, you can even configure the size of
this guard area - see the pthread_attr_setguardsize() manpage)