I diff'd the 93.2 v.s. 93.3 source code to find the bug fix for the URI issue.
I can't see any change that is obviously related to it.

There is a change in jsonrpc_listunspent() at armoryd.py:462 where ".getOutPoint()" has been removed.
462c461
<             curUTXODict['txid'] = binary_to_hex(u.getOutPoint().getTxHash(), \
---
>             curUTXODict['txid'] = binary_to_hex(u.getTxHash(), \

Is this the fix for the URI bug?

In jsonrpc_listaddrunspent() the identical code is used at line 556.
Should that line be patched in the same way as line 462 ?

Since the crash occurs intermittently, I commented out addNewZeroConfTx() in one system and
ran the second system unpatched. The patched system has not crashed so far, but the unpatched
system has crashed several times. So, it looks like the problem is in the "zero confirmations" code.
I will use the fix on both systems. Thanks for providing a good work-around patch.

I reduced MAX_MAPSIZE_INCEREMENT from 256MB to 16MB, re-compiled, and --rebuild.
The databases are now:
  20819968 2015-08-31 00:57 blocks
107724800 2015-08-31 00:57 headers
After a couple of days of uptime I got the std::bad_alloc crash.

I'm running an identical copy of bitcoin-qt/Armory on a newer desktop that has 16GB dram.
I got the std::bad_alloc crash on that machine too, just like the laptop.

I also got the std::alloc crash when sending to a "normal" wallet.

In one instance so far, I started Armory at 23:50 and sent BTC at 00:10 and got std::alloc.
Is there any code in Armory that uses "current time - previous time" and doesn't handle
a negative value?

I got a third crash at 20150825_2016. It looks like Armory has to have been running for 24++ hrs in order to
get to the condition that triggers the std::bad_alloc. The approximate 48 hr interval that I see is probably due to
the fixed times of day that I use the PC. I sent 1.5BTC from bitcoin-qt to Armory-watch. Armory popped up the
std::bad_alloc window a few seconds after bitcoin-qt said it had sent the TX. I think the problem occurs when
Armory receives the raw TX. After restarting, it gets the TX from the block without a problem (but that's not after
a 24++ hr delay).

The memory usage remained fairly constant for the 48 hrs, including after the exception.
  Armory:   VIRT = 1052M  RES = 288M   SHR = 19M
  Bitcoin-qt  VIRT = 1121M  RES = 404M   SHR = 12M

I'm not having any success debuging ArmoryQt.py with gdb. I'll just try to get a crash in less than 48 hrs.

I've been running Armory on the laptop for about a week. The initial scan happened without incident.
It took me a few days to sort out the maxconnections issue. After that I've been running Armory
continuously. The laptop is only used to run bitcoind and Armory.

I got a first std::bad_alloc crash at 20150821_1449.
I restarted Armory under gdb.
I got the second std::bad_alloc crash at 20150823_2125.
Python had exited cleanly so there was nothing for gdb to display.
I restarted Armory under gdb, set a breakpoint at BDM_mainthread.cpp:453, and did run with --netlog.
I am expecting to have to wait a couple of days for another crash. I'll keep on making small value
transfers between Armory and bitcoin-qt. I want to see if the crash is spontaneous, or if it happens during
some user initiated activity.

_CppBlockUtils.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, not stripped

The machine only has 2GB dram, but it also has 12GB swap.
I think you can also get this exception from a realloc with a bad ptr.

I'm using a home-built Linux running on a HP laptop.
Linux sys 2.6.37.6 #11 SMP Sun Apr 14 21:52:49 EDT 2013 x86_64 Intel(R) Core(TM)2 CPU T5300 @ 1.73GHz GenuineIntel GNU/Linux
I used gcc-4.9.2 to build the c++11 bits of Armory. Packages: swig-3.0.6 sip-4.16.9 PyQt-x11-gpl-4.11.4 psutil-2.1.3 Twisted-15.3.0 qt-4.8.6.

When running ffreeze and bitcoind 0.11.0 in Linux I got a "BDM thread failed: std::bad_alloc" crash.
Python traps the exception so gdb has nothing to report.
I was doing a send from bitcoin-qt to Armory-watch-wallet. The exception happened when Armory received
the broadcast transaction. I restarted Armory and it then saw the transaction when the first confirmation block
arrived. Are there any debug printf's for identifying where the bad_alloc is occuring?

I found that "maxconnections=6" in bitcoin.conf was causing bitcoind to reject connections
from Armory on the localhost interface. When I changed it to "maxconnections=30", Armory
started working as expected, and bitcond says it has 9 open connections.

I built the ffreeze version of Armory under Linux and am running it with bitcoind 0.11.0.
So far everything is working fine.

A minor issue happened when I restored a wallet from 0.92 and then
tried "Addresses->View Address Book". Armory threw the following exception:
  File "ArmoryQt.py", line 3902, in execAddressBook
    DlgAddressBook(self, self, None, None, None).exec_()
  File "/home/userid/BitcoinArmory-ffreeze/qtdialogs.py", line 8133, in __init__
    rowHeight = tightSizeStr(self.font, 'XygjpHI')[1]
  File "/home/userid/BitcoinArmory-ffreeze/qtdefines.py", line 215, in tightSizeStr
    fm = QFontMetricsF(QFont(obj))
TypeError: QFont(): argument 1 has unexpected type 'builtin_function_or_method'

However, I keep on getting popups about Armory losing it's connection to bitcoind.
(ERROR) Networking.py:359 - ***Connection to Satoshi client LOST!  Attempting to reconnect...

In ~/.bitcoin/debug.log there are bezillions of lines like this...
....
2015-08-18 00:54:43 keypool reserve 1
2015-08-18 00:54:43 keypool return 1
....
It looks like Armory is polling bitcoind on 127.0.0.1:8332 once a second to get the chain state.
Each poll is a tcp connection; open and close.
The problem is that I get a bucket load of tcp TIME_WAIT entries. Eventually the system runs
out of socket resources, and then I think Armory thows the cannot connect popup.

Is there an option to increase the polling interval to, let's say, 10 second?
Or better still, could Armory open a single tcp connection to bitcoind and keep it open for
the duration of the session?

I like having Armory start bitcoind as a child process, and would prefer to not have to start it
myself, which is the work-around I have seen given in previous posts.