SN-10163 附来源、原文与上下文。
我确认 ParseString 存在这个问题，并已把修复后的 util.cpp 上传到 SVN。
I confirmed that ParseString has this problem, and uploaded the fixed util.cpp to SVN.
string::npos == -1
string::npos == -1
比较 unsigned int 的 -1（0xffffffff）与 long unsigned int 的 -1（0xffffffffffffffff）时，unsigned int 会被提升为 64 位，也就是 0x00000000ffffffff != 0xffffffffffffffff。
Comparing unsigned int -1 (0xffffffff) with long unsigned int -1 (0xffffffffffffffff) results in the unsigned int being promoted to 64-bit, which is 0x00000000ffffffff != 0xffffffffffffffff.
引用 Martti Malmi 的文字Martti Malmi来源 ↗这是我用 gdb 调试时得到的另一次测试运行的 debug.log。程序在“irc 8”这条调试信息之后开始吞噬内存，几秒内就崩溃，报错为“terminate called after throwing an instance of 'std::bad_alloc'”。
Here's another test run debug.log I got when debugging with gdb. The program started eating memory after the debug line "irc 8" and within a few seconds crashed with "terminate called after throwing an instance of 'std::bad_alloc'".
引用中本聪此前的文字中本聪来源 ↗问题在 RecvUntil 里，但我还是看不出有什么不对。我唯一能想到的，是套接字正在接收大量字符。
It's in RecvUntil, but I still can't see anything wrong with it. The only thing I can think of is if the socket is receiving a spew of characters.
试试这个 irc.cpp。debug.log 可能迅速增长，要随时准备强制终止程序。
Try this irc.cpp. debug.log may grow rapidly so be ready to kill it.
引用 Martti Malmi 的文字Martti Malmi来源 ↗已附上 debug.log
debug.log attached
引用中本聪此前的文字中本聪来源 ↗这样范围缩小了很多。debug.log 中没有打印任何 IRC 活动，所以我猜它不可能执行过 RecvUntil。粗看没有发现明显的问题。我想应该在 ConnectSocket 或 RecvUntil 其中之一。
That narrows it down a lot. It didn't print any IRC activity in debug.log, so I guess it couldn't have gotten past the RecvUntil. Eyeballing it I don't see anything obvious. I guess it would have to be either in ConnectSocket or RecvUntil.
用附上的 irc.cpp 和 net.cpp 试试，再把 debug.log 发给我。
Try it with the attached irc.cpp and net.cpp and send me the debug.log.
或者你可以在 gdb 中运行，逐步执行 ThreadIRCSeed gdb --args bitcoin [switches] b ThreadIRCSeed run step 或用 u 来单步越过，并从子程序中返回上层。
Or you could run it in gdb and step through ThreadIRCSeed gdb --args bitcoin [switches] b ThreadIRCSeed run step or u to step over and up out of routines.
引用 Martti Malmi 的文字Martti Malmi来源 ↗不管有没有 getinfo，我都会遇到这个错误。注释掉 ThreadIRCSeed 后，问题解决了。
I get the error regardless of the getinfo. Commenting out ThreadIRCSeed fixed the problem.
引用中本聪此前的文字中本聪来源 ↗如果不执行 getinfo，还会发生吗？
Does it still do it if you didn't do getinfo?
你可以把下面列出的 CreateThreads 注释掉，然后逐个重新启用，直到问题再次出现。这样就能知道问题在哪个线程中。
You could comment out the CreateThreads listed below, then re-enable them one at a time until it does it again. Then we would know which thread the problem is in.
net.cpp，在 // Start threads 下方 CreateThread(ThreadIRCSeed, NULL) CreateThread(ThreadSocketHandler, NULL, true) CreateThread(ThreadOpenConnections, NULL) CreateThread(ThreadMessageHandler, NULL)
net.cpp, under // Start threads CreateThread(ThreadIRCSeed, NULL) CreateThread(ThreadSocketHandler, NULL, true) CreateThread(ThreadOpenConnections, NULL) CreateThread(ThreadMessageHandler, NULL)
init.cpp： CreateThread(ThreadRPCServer, NULL);
init.cpp: CreateThread(ThreadRPCServer, NULL);
引用 Martti Malmi 的文字Martti Malmi来源 ↗发来了。我忘了说崩溃的错误消息：
Here goes. I forgot to mention the crash error message:
terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc
terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc
引用中本聪此前的文字中本聪来源 ↗能把 debug.log 发给我吗？
Could you send me the debug.log?
引用 Martti Malmi 的文字Martti Malmi来源 ↗我试着用 ddd 调试器调试自己编译的 bitcoind，不过 目前还没取得什么进展。它最后总是占用全部系统内存，然后崩溃。能否请你再发给我最新的 64 位 bitcoind 构建，好让我看看问题是否出在我自己编译的版本上？
I tried debugging my build of bitcoind with ddd debugger, but didn't have much success yet. It always ends up taking all the system's memory and finally crashes. Could you please send me again the latest 64 bit build of bitcoind, so I can see if the problem is about my build?
