So, I can't reproduce this *directly* on Oneiric, and I don't have a Lucid test environment right now.  However, I emphasise "directly": with some fiddling, I can indirectly see what's probably going on here, even though the precise circumstances have changed in Oneiric.  If I comment out the bits from debconf's Gnome frontend that hide the cancel button to try to reduce the incidence of this kind of problem, and then attach 'strace -f' to aptdaemon while installing acroread from software-center, I can see the Passthrough frontend failing with similar warning messages, and eventually being killed by SIGPIPE.

What's happening here is that the UI agent (in my case, the Gnome frontend) exits on being cancelled, and therefore stops responding to messages from the Passthrough frontend.  The latter first tries to read, gets end-of-file (rendered in Perl as the <> operator returning undef), fails to handle that specifically, and throws a bunch of uninitialised-value warnings.  When it next tries to write to the UI agent, it gets SIGPIPE as one might expect because all the readers have gone away.

Oneiric (and I suspect also Natty; acroread isn't yet in the Oneiric partner repository, but my test system has the Natty partner repository in sources.list) avoids this problem because acroread 9.4.2-0natty1 changed from asking questions directly in the postinst to asking them in a separate config script.  Asking questions in config rather than postinst is good practice anyway and there's no reason why it shouldn't have been done in previous releases too.  However, there are still situations where there is no alternative to asking a question directly in the postinst, and so we do still need to do something about this.

It's not clear to me how people are seeing the cancel button in Karmic or Lucid, since the change to suppress that in debconf's Gnome frontend was made in the Intrepid cycle.  What does the dialog with the cancel button look like (perhaps a screenshot)?

As to what we can do about this bug report: it's not entirely obvious.  We can certainly suppress the uninitialised-value warnings by handling end-of-file and SIGPIPE-on-write explicitly.  We can try to reduce the incidence of cancellations, or make it more obvious that they constitute cancelling installation of a package and confirm that with the user (see Joey's comment in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501767), but that doesn't deal with the question of what the Passthrough frontend should actually *do* when its UI agent goes away unexpectedly.  It doesn't have the ability to restart it, because it's running in some completely different context (different filesystem namespace, perhaps even a different machine, etc.) that Passthrough isn't allowed to know about.  It can't itself display any UI because Passthrough isn't an X-based frontend, and is just there for shovelling data around.  The only choices I can see are:

 * Exit non-zero (which would show up as a "crash" in much the same way, though perhaps we could handle it more gracefully, and improved cancellation handling in UI agents would certainly help);
 * Continue in noninteractive mode.  On the one hand, this corresponds to the user detaching control.  On the other hand, that really isn't what "cancel" intuitively means!