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?
Bitcoind
Private email with Martti Malmi (sirius-m) · 16 messages · from 28 February 2010 · with Satoshi Nakamoto, mmalmi@cc.hut.fi
Read in Satoshi Mail Archive source
I put it at bitcoin.org/download/linux64-0.2.7.1.tar.gz. You can delete
it when you've got it.
I thought about what might cause the problem you're having and made a
change that this build includes. This might have been unsafe code,
although it would probably always get lucky.
in util.cpp, old:
const char* wxGetTranslation(const char* pszEnglish)
{
// Wrapper of wxGetTranslation returning the same const char* type
as was passed in
static CCriticalSection cs;
CRITICAL_BLOCK(cs)
{
// Look in cache
static map<string, char*> mapCache;
map<string, char*>::iterator mi = mapCache.find(pszEnglish);
if (mi != mapCache.end())
return (*mi).second;
// wxWidgets translation
const char* pszTranslated =
wxGetTranslation(wxString(pszEnglish, wxConvUTF8)).utf8_str();
// We don't cache unknown strings because caller might be
passing in a
// dynamic string and we would keep allocating memory for each
variation.
if (strcmp(pszEnglish, pszTranslated) == 0)
return pszEnglish;
// Add to cache, memory doesn't need to be freed. We only
cache because
// we must pass back a pointer to permanently allocated memory.
char* pszCached = new char[strlen(pszTranslated)+1];
strcpy(pszCached, pszTranslated);
mapCache[pszEnglish] = pszCached;
return pszCached;
}
return NULL;
}
new:
const char* wxGetTranslation(const char* pszEnglish)
{
// Wrapper of wxGetTranslation returning the same const char* type
as was passed in
static CCriticalSection cs;
CRITICAL_BLOCK(cs)
{
// Look in cache
static map<string, char*> mapCache;
map<string, char*>::iterator mi = mapCache.find(pszEnglish);
if (mi != mapCache.end())
return (*mi).second;
// wxWidgets translation
wxString strTranslated = wxGetTranslation(wxString(pszEnglish,
wxConvUTF8));
// We don't cache unknown strings because caller might be
passing in a
// dynamic string and we would keep allocating memory for each
variation.
if (strcmp(pszEnglish, strTranslated.utf8_str()) == 0)
return pszEnglish;
// Add to cache, memory doesn't need to be freed. We only
cache because
// we must pass back a pointer to permanently allocated memory.
char* pszCached = new char[strlen(strTranslated.utf8_str())+1];
strcpy(pszCached, strTranslated.utf8_str());
mapCache[pszEnglish] = pszCached;
return pszCached;
}
return NULL;
}
If you still suspect this code, for testing you could change it to:
const char* wxGetTranslation(const char* pszEnglish)
{
return pszEnglish;
}
mmalmi@cc.hut.fi wrote: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?
Could you send me the debug.log?
mmalmi@cc.hut.fi wrote: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?
Here goes. I forgot to mention the crash error message:
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Could you send me the debug.log? mmalmi@cc.hut.fi wrote: > 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? >
This was from the compilation you sent, the same problem occurred with it.
Here goes. I forgot to mention the crash error message: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc > Could you send me the debug.log? > > mmalmi@cc.hut.fi wrote: >> 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? >>
Does it still do it if you didn't do getinfo?
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, under // Start threads
CreateThread(ThreadIRCSeed, NULL)
CreateThread(ThreadSocketHandler, NULL, true)
CreateThread(ThreadOpenConnections, NULL)
CreateThread(ThreadMessageHandler, NULL)
init.cpp:
CreateThread(ThreadRPCServer, NULL);
mmalmi@cc.hut.fi wrote:Here goes. I forgot to mention the crash error message: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc > Could you send me the debug.log? > > mmalmi@cc.hut.fi wrote: >> 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? >>
I get the error regardless of the getinfo. Commenting out
ThreadIRCSeed fixed the problem.
Does it still do it if you didn't do getinfo? 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, under // Start threads CreateThread(ThreadIRCSeed, NULL) CreateThread(ThreadSocketHandler, NULL, true) CreateThread(ThreadOpenConnections, NULL) CreateThread(ThreadMessageHandler, NULL) init.cpp: CreateThread(ThreadRPCServer, NULL); mmalmi@cc.hut.fi wrote: > Here goes. I forgot to mention the crash error message: > > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > >> Could you send me the debug.log? >> >> mmalmi@cc.hut.fi wrote: >>> 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? >>> > > >
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.
Try it with the attached irc.cpp and net.cpp and send me the debug.log.
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.
mmalmi@cc.hut.fi wrote:I get the error regardless of the getinfo. Commenting out ThreadIRCSeed fixed the problem. > Does it still do it if you didn't do getinfo? > > 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, under // Start threads > CreateThread(ThreadIRCSeed, NULL) > CreateThread(ThreadSocketHandler, NULL, true) > CreateThread(ThreadOpenConnections, NULL) > CreateThread(ThreadMessageHandler, NULL) > > init.cpp: > CreateThread(ThreadRPCServer, NULL); > > mmalmi@cc.hut.fi wrote: >> Here goes. I forgot to mention the crash error message: >> >> terminate called after throwing an instance of 'std::bad_alloc' >> what(): std::bad_alloc >> >>> Could you send me the debug.log? >>> >>> mmalmi@cc.hut.fi wrote: >>>> 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? >>>> >> >> >>
debug.log attached
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. Try it with the attached irc.cpp and net.cpp and send me the debug.log. 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. mmalmi@cc.hut.fi wrote: > I get the error regardless of the getinfo. Commenting out > ThreadIRCSeed fixed the problem. > >> Does it still do it if you didn't do getinfo? >> >> 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, under // Start threads >> CreateThread(ThreadIRCSeed, NULL) >> CreateThread(ThreadSocketHandler, NULL, true) >> CreateThread(ThreadOpenConnections, NULL) >> CreateThread(ThreadMessageHandler, NULL) >> >> init.cpp: >> CreateThread(ThreadRPCServer, NULL); >> >> mmalmi@cc.hut.fi wrote: >>> Here goes. I forgot to mention the crash error message: >>> >>> terminate called after throwing an instance of 'std::bad_alloc' >>> what(): std::bad_alloc >>> >>>> Could you send me the debug.log? >>>> >>>> mmalmi@cc.hut.fi wrote: >>>>> 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? >>>>> >>> >>> >>> > > >
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.
Try this irc.cpp. debug.log may grow rapidly so be ready to kill it.
mmalmi@cc.hut.fi wrote:debug.log attached > 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. > > Try it with the attached irc.cpp and net.cpp and send me the debug.log. > > 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. > > mmalmi@cc.hut.fi wrote: >> I get the error regardless of the getinfo. Commenting out >> ThreadIRCSeed fixed the problem. >> >>> Does it still do it if you didn't do getinfo? >>> >>> 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, under // Start threads >>> CreateThread(ThreadIRCSeed, NULL) >>> CreateThread(ThreadSocketHandler, NULL, true) >>> CreateThread(ThreadOpenConnections, NULL) >>> CreateThread(ThreadMessageHandler, NULL) >>> >>> init.cpp: >>> CreateThread(ThreadRPCServer, NULL); >>> >>> mmalmi@cc.hut.fi wrote: >>>> Here goes. I forgot to mention the crash error message: >>>> >>>> terminate called after throwing an instance of 'std::bad_alloc' >>>> what(): std::bad_alloc >>>> >>>>> Could you send me the debug.log? >>>>> >>>>> mmalmi@cc.hut.fi wrote: >>>>>> 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? >>>>>> >>>> >>>> >>>> >> >> >>
Here's the debug.log. I stopped bitcoind before it took up all the memory.
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. Try this irc.cpp. debug.log may grow rapidly so be ready to kill it. mmalmi@cc.hut.fi wrote: > debug.log attached > >> 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. >> >> Try it with the attached irc.cpp and net.cpp and send me the debug.log. >> >> 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. >> >> mmalmi@cc.hut.fi wrote: >>> I get the error regardless of the getinfo. Commenting out >>> ThreadIRCSeed fixed the problem. >>> >>>> Does it still do it if you didn't do getinfo? >>>> >>>> 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, under // Start threads >>>> CreateThread(ThreadIRCSeed, NULL) >>>> CreateThread(ThreadSocketHandler, NULL, true) >>>> CreateThread(ThreadOpenConnections, NULL) >>>> CreateThread(ThreadMessageHandler, NULL) >>>> >>>> init.cpp: >>>> CreateThread(ThreadRPCServer, NULL); >>>> >>>> mmalmi@cc.hut.fi wrote: >>>>> Here goes. I forgot to mention the crash error message: >>>>> >>>>> terminate called after throwing an instance of 'std::bad_alloc' >>>>> what(): std::bad_alloc >>>>> >>>>>> Could you send me the debug.log? >>>>>> >>>>>> mmalmi@cc.hut.fi wrote: >>>>>>> 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? >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > >
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'".
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. Try this irc.cpp. debug.log may grow rapidly so be ready to kill it. mmalmi@cc.hut.fi wrote: > debug.log attached > >> 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. >> >> Try it with the attached irc.cpp and net.cpp and send me the debug.log. >> >> 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. >> >> mmalmi@cc.hut.fi wrote: >>> I get the error regardless of the getinfo. Commenting out >>> ThreadIRCSeed fixed the problem. >>> >>>> Does it still do it if you didn't do getinfo? >>>> >>>> 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, under // Start threads >>>> CreateThread(ThreadIRCSeed, NULL) >>>> CreateThread(ThreadSocketHandler, NULL, true) >>>> CreateThread(ThreadOpenConnections, NULL) >>>> CreateThread(ThreadMessageHandler, NULL) >>>> >>>> init.cpp: >>>> CreateThread(ThreadRPCServer, NULL); >>>> >>>> mmalmi@cc.hut.fi wrote: >>>>> Here goes. I forgot to mention the crash error message: >>>>> >>>>> terminate called after throwing an instance of 'std::bad_alloc' >>>>> what(): std::bad_alloc >>>>> >>>>>> Could you send me the debug.log? >>>>>> >>>>>> mmalmi@cc.hut.fi wrote: >>>>>>> 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? >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > >
It's in util.c ParseString. I'm guessing the problem is incompatibility
between the type "unsigned int" and the type of str.npos, which is
size_type.
Try changing the two "unsigned int"s to "size_type".
old:
void ParseString(const string& str, char c, vector<string>& v)
{
unsigned int i1 = 0;
unsigned int i2;
do
{
i2 = str.find(c, i1);
v.push_back(str.substr(i1, i2-i1));
i1 = i2+1;
}
while (i2 != str.npos);
}
new:
void ParseString(const string& str, char c, vector<string>& v)
{
size_type i1 = 0;
size_type i2;
do
{
i2 = str.find(c, i1);
v.push_back(str.substr(i1, i2-i1));
i1 = i2+1;
}
while (i2 != str.npos);
}
mmalmi@cc.hut.fi wrote: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'". > 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. > > Try this irc.cpp. debug.log may grow rapidly so be ready to kill it. > > mmalmi@cc.hut.fi wrote: >> debug.log attached >> >>> 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. >>> >>> Try it with the attached irc.cpp and net.cpp and send me the debug.log. >>> >>> 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. >>> >>> mmalmi@cc.hut.fi wrote: >>>> I get the error regardless of the getinfo. Commenting out >>>> ThreadIRCSeed fixed the problem. >>>> >>>>> Does it still do it if you didn't do getinfo? >>>>> >>>>> 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, under // Start threads >>>>> CreateThread(ThreadIRCSeed, NULL) >>>>> CreateThread(ThreadSocketHandler, NULL, true) >>>>> CreateThread(ThreadOpenConnections, NULL) >>>>> CreateThread(ThreadMessageHandler, NULL) >>>>> >>>>> init.cpp: >>>>> CreateThread(ThreadRPCServer, NULL); >>>>> >>>>> mmalmi@cc.hut.fi wrote: >>>>>> Here goes. I forgot to mention the crash error message: >>>>>> >>>>>> terminate called after throwing an instance of 'std::bad_alloc' >>>>>> what(): std::bad_alloc >>>>>> >>>>>>> Could you send me the debug.log? >>>>>>> >>>>>>> mmalmi@cc.hut.fi wrote: >>>>>>>> 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? >>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >> >> >>
Actually, please try this instead, this is more correct:
void ParseString(const string& str, char c, vector<string>& v)
{
string::size_type i1 = 0;
string::size_type i2;
loop
{
i2 = str.find(c, i1);
if (i2 == str.npos)
{
v.push_back(str.substr(i1));
return;
}
v.push_back(str.substr(i1, i2-i1));
i1 = i2+1;
}
}
Satoshi Nakamoto wrote:It's in util.c ParseString. I'm guessing the problem is incompatibility between the type "unsigned int" and the type of str.npos, which is size_type. Try changing the two "unsigned int"s to "size_type". old: void ParseString(const string& str, char c, vector<string>& v) { unsigned int i1 = 0; unsigned int i2; do { i2 = str.find(c, i1); v.push_back(str.substr(i1, i2-i1)); i1 = i2+1; } while (i2 != str.npos); } new: void ParseString(const string& str, char c, vector<string>& v) { size_type i1 = 0; size_type i2; do { i2 = str.find(c, i1); v.push_back(str.substr(i1, i2-i1)); i1 = i2+1; } while (i2 != str.npos); } mmalmi@cc.hut.fi wrote: > 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'". > >> 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. >> >> Try this irc.cpp. debug.log may grow rapidly so be ready to kill it. >> >> mmalmi@cc.hut.fi wrote: >>> debug.log attached >>> >>>> 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. >>>> >>>> Try it with the attached irc.cpp and net.cpp and send me the >>>> debug.log. >>>> >>>> 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. >>>> >>>> mmalmi@cc.hut.fi wrote: >>>>> I get the error regardless of the getinfo. Commenting out >>>>> ThreadIRCSeed fixed the problem. >>>>> >>>>>> Does it still do it if you didn't do getinfo? >>>>>> >>>>>> 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, under // Start threads >>>>>> CreateThread(ThreadIRCSeed, NULL) >>>>>> CreateThread(ThreadSocketHandler, NULL, true) >>>>>> CreateThread(ThreadOpenConnections, NULL) >>>>>> CreateThread(ThreadMessageHandler, NULL) >>>>>> >>>>>> init.cpp: >>>>>> CreateThread(ThreadRPCServer, NULL); >>>>>> >>>>>> mmalmi@cc.hut.fi wrote: >>>>>>> Here goes. I forgot to mention the crash error message: >>>>>>> >>>>>>> terminate called after throwing an instance of 'std::bad_alloc' >>>>>>> what(): std::bad_alloc >>>>>>> >>>>>>>> Could you send me the debug.log? >>>>>>>> >>>>>>>> mmalmi@cc.hut.fi wrote: >>>>>>>>> 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? >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > >
Great! Works fine now.
Actually, please try this instead, this is more correct: void ParseString(const string& str, char c, vector<string>& v) { string::size_type i1 = 0; string::size_type i2; loop { i2 = str.find(c, i1); if (i2 == str.npos) { v.push_back(str.substr(i1)); return; } v.push_back(str.substr(i1, i2-i1)); i1 = i2+1; } } Satoshi Nakamoto wrote: > It's in util.c ParseString. I'm guessing the problem is > incompatibility between the type "unsigned int" and the type of > str.npos, which is size_type. > > Try changing the two "unsigned int"s to "size_type". > > old: > void ParseString(const string& str, char c, vector<string>& v) > { > unsigned int i1 = 0; > unsigned int i2; > do > { > i2 = str.find(c, i1); > v.push_back(str.substr(i1, i2-i1)); > i1 = i2+1; > } > while (i2 != str.npos); > } > > new: > void ParseString(const string& str, char c, vector<string>& v) > { > size_type i1 = 0; > size_type i2; > do > { > i2 = str.find(c, i1); > v.push_back(str.substr(i1, i2-i1)); > i1 = i2+1; > } > while (i2 != str.npos); > } > > > mmalmi@cc.hut.fi wrote: >> 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'". >> >>> 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. >>> >>> Try this irc.cpp. debug.log may grow rapidly so be ready to kill it. >>> >>> mmalmi@cc.hut.fi wrote: >>>> debug.log attached >>>> >>>>> 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. >>>>> >>>>> Try it with the attached irc.cpp and net.cpp and send me the debug.log. >>>>> >>>>> 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. >>>>> >>>>> mmalmi@cc.hut.fi wrote: >>>>>> I get the error regardless of the getinfo. Commenting out >>>>>> ThreadIRCSeed fixed the problem. >>>>>> >>>>>>> Does it still do it if you didn't do getinfo? >>>>>>> >>>>>>> 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, under // Start threads >>>>>>> CreateThread(ThreadIRCSeed, NULL) >>>>>>> CreateThread(ThreadSocketHandler, NULL, true) >>>>>>> CreateThread(ThreadOpenConnections, NULL) >>>>>>> CreateThread(ThreadMessageHandler, NULL) >>>>>>> >>>>>>> init.cpp: >>>>>>> CreateThread(ThreadRPCServer, NULL); >>>>>>> >>>>>>> mmalmi@cc.hut.fi wrote: >>>>>>>> Here goes. I forgot to mention the crash error message: >>>>>>>> >>>>>>>> terminate called after throwing an instance of 'std::bad_alloc' >>>>>>>> what(): std::bad_alloc >>>>>>>> >>>>>>>>> Could you send me the debug.log? >>>>>>>>> >>>>>>>>> mmalmi@cc.hut.fi wrote: >>>>>>>>>> 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? >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >> >> >> > >
I confirmed that ParseString has this problem, and uploaded the fixed
util.cpp to SVN.
string::npos == -1
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.
mmalmi@cc.hut.fi wrote: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'". > 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. > > Try this irc.cpp. debug.log may grow rapidly so be ready to kill it. > > mmalmi@cc.hut.fi wrote: >> debug.log attached >> >>> 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. >>> >>> Try it with the attached irc.cpp and net.cpp and send me the debug.log. >>> >>> 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. >>> >>> mmalmi@cc.hut.fi wrote: >>>> I get the error regardless of the getinfo. Commenting out >>>> ThreadIRCSeed fixed the problem. >>>> >>>>> Does it still do it if you didn't do getinfo? >>>>> >>>>> 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, under // Start threads >>>>> CreateThread(ThreadIRCSeed, NULL) >>>>> CreateThread(ThreadSocketHandler, NULL, true) >>>>> CreateThread(ThreadOpenConnections, NULL) >>>>> CreateThread(ThreadMessageHandler, NULL) >>>>> >>>>> init.cpp: >>>>> CreateThread(ThreadRPCServer, NULL); >>>>> >>>>> mmalmi@cc.hut.fi wrote: >>>>>> Here goes. I forgot to mention the crash error message: >>>>>> >>>>>> terminate called after throwing an instance of 'std::bad_alloc' >>>>>> what(): std::bad_alloc >>>>>> >>>>>>> Could you send me the debug.log? >>>>>>> >>>>>>> mmalmi@cc.hut.fi wrote: >>>>>>>> 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? >>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >> >> >>