There is a hard memory limit defined in upnpsoap.c of 1MB for the SOAP response. This is reached for large collections, and causes an error message:
[2009/08/07 12:15:48] upnpsoap.c:511: error: UPnP SOAP response is getting too big! [1338 returned]
followed by a segfault and crash of the entire process.
I'm not familiar enough with the UPnP protocols to know whether this is a server bug, client bug (asking for too much at once?) or protocol flaw, but I can reproduce it at will by navigating to the "All Music" folder, for example. The immediate bug seems to be the call to sqlite3_exec() on line 945 of upnpsoap.c, and the resulting calls to the callback function (where the error message is produced). There does not seem to be a failsafe to actually stop the response building and work out an alternative, so the query results happily blaze past the end of passed_args->resp.
Playing with the hard limit would delay the problem, but I'm thinking there must be some way to break up large responses in this situation. OTOH, to reproduce the problem without requiring a large collection of files, one could drop that limit to, say, 10kB, and likely get the same results.
As a short-term workaround, to truncate the search without crashing, the attached patch may be useful. Oddly, on my NAS, it seems to actually catch all the tracks somehow. Slowly.
Fair warning on running it in debug mode, though. That's one heck of a packet :)