0.7rc1 crashing in listtransactions #1768

1. 
   gavinandresen commented at 6:18 PM on August 31, 2012: contributor

   Clean build of git HEAD running on the bitcoin faucet machine is crashing:

   [#1](/bitcoin-bitcoin/1/)  0x082786c1 in AcentryToJSON (acentry=..., strAccount=..., ret=...) at rpcwallet.cpp:972
   972     if (fAllAccounts || acentry.strAccount == strAccount)
   (gdb) p acentry.strAccount
   $1 = {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},   _M_p = 0x1 <Address 0x1 out of bounds>}}
   

   Maybe a stomping-on-memory-from-multiple threads bug? I'll see what I can see in valgrind...

   Faucet machine is running Ubuntu 10.04.4 LTS

2. 
   gavinandresen commented at 6:53 PM on August 31, 2012: contributor

   Valgrind is complaining:

   ==56158== Thread 8:
   ==56158== Conditional jump or move depends on uninitialised value(s)
   ==56158==    at 0x2267CB: CService::SetSockAddr(sockaddr const*) (netbase.cpp:1029)
   ==56158==    by 0x201FB9: ThreadSocketHandler2(void*) (net.cpp:814)
   

   USE_IPV6 versus not USE_IPV6 issue?

   .... no, compiling without USE_IPV6 seems to make no difference...

3. 
   gavinandresen commented at 10:33 PM on August 31, 2012: contributor

   Saving my place in the debugging stack:

   Problem seems to be with call: listtransactions '' n

   valgrind complains:

   ==56158== Thread 3:
   ==56158== Invalid read of size 4
   ==56158==    at 0x1504336: std::string::compare(std::string const&) const (in /usr/lib/libstdc++.6.0.9.dylib)
   ==56158==    by 0x71C33: bool std::operator==<char, std::char_traits<char>, std::allocator<char> >    (std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char,     std::char_traits<char>, std::allocator<char> > const&) (basic_string.h:2154)
   ==56158==    by 0x286B97: AcentryToJSON(CAccountingEntry const&, std::string const&, std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::string> >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::string> > > >&) (rpcwallet.cpp:972)
   ==56158==    by 0x2A8F6B: listtransactions(std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::string> >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::string> > > > const&, bool) (rpcwallet.cpp:1019)
   ==56158==    by 0x5C547: CRPCTable::execute(std::string const&, std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::string> >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::string> > > > const&) const (bitcoinrpc.cpp:1015)
   

   (on my mac)

4. 
   jgarzik commented at 12:49 AM on September 1, 2012: contributor

   As an aside, I am interested in suggestions for testing the RPC calls, so that we may add them to the test suite. Be more rigorous about problems like this.

   My initial idea is that we can skip all the HTTP stuffs, and just internally generate / receive JSON calls. Of course, RPC calls tend to be unit-unfriendly, requiring a full and active node with wallet to be useful.

5. 
   gavinandresen commented at 9:37 PM on September 1, 2012: contributor

   git bisect tells me:

   c3f95ef13f48d21db53992984976eac93e7a08fc is the first bad commit commit c3f95ef13f48d21db53992984976eac93e7a08fc Author: Luke Dashjr luke-jr+git@utopios.org Date: Mon May 28 18:45:12 2012 +0000

   Choose reasonable "smart" times to display for transactions
   

6. 
   gavinandresen commented at 9:57 PM on September 1, 2012: contributor

   CWallet::OrderedTxItems declares a local list<CAccountingEntry> acentries

   Pointers into the items in that list are then added to the txOrdered map.

   Unfortunately, acentries is deleted before returning from that routine, leaving txOrdered pointing to freed memory.

7. luke-jr referenced this in commit b153ff0776 on Sep 1, 2012
8. 
   luke-jr commented at 10:15 PM on September 1, 2012: member

   Sorry about that, I really should have known better :(

9. luke-jr referenced this in commit 37b0def86d on Sep 2, 2012
10. luke-jr referenced this in commit ddb709e9de on Sep 2, 2012
11. 
    Diapolo commented at 8:12 PM on September 3, 2012: none

    Is this one fixed? If yes, we have a blocker less ^^.

12. 
    gavinandresen commented at 3:44 PM on September 5, 2012: contributor

    Fixed.

13. gavinandresen closed this on Sep 5, 2012

    ---

14. owlhooter referenced this in commit f9f28e7c73 on Oct 10, 2018
15. DrahtBot locked this on Sep 8, 2021

Milestone
0.7.0