Did you reinstall or rebuild 9548?
Please rebuild it. Maybe it's something with your environment.
You had already suggested this (maybe you've forgotten it but it's normal because you aren't currently following this only but many other and more complex issues!
) and I had already rebuilt it with my current build environment replacing the printf in MuleUDPsocket.cpp to reproduce the discarded packets (due to disconnections as already understood in this thread) logging. Yesterday I've only reinstalled it but after rebuilding it from scratch only a couple of months ago and with my current build environment: it isn't the 'original' 9548 that I've built as soon as it was released.
By the way, my build environment hasn't never changed since when I've set it up and I successfully used it to build other things too and I continue to do it.
That said, I've used 9556 for eighteen hours (a good test I think) and it has worked very well (like 9548 I could say). The only strange thing happened when I've decided to exit from aMule... I use a little script that kills all the processes related to aMule and, if activated by the startup script, turns the swap off: when called, the 'killall amuled' command failed (all the amuled -f instances could still be seen doing a 'ps') and the successive 'swapoff /dev/sda6' being sda6 my swap partition failed with the recurrent 'Cannot allocate memory' message. This time it was something different though because, as said, aMule was stable: after almost a minute all the amuled instances were terminated then I could call the swapoff command while I think that the other newer versions tested actually crashed and the swap issue was only a side-effect.
I'm starting to think about retrying 9566 making a couple of checks that I've in mind (more or less the ones made with 9556) and see what happens. With the right results, it could be that the 'culprit' is the file autoclose feature as already guessed by StuRedman and I could try to build one of the lastest SVNs disabling the CBB and the file autoclose feature though this could be too reckless...
Thanks to GonoszTopi too for his summarizing, I find it very helpful.