Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash in AppInit() upon start (EXCEPTION: NSt8ios_base7failureE) #115

Closed
pysiak opened this issue Jun 17, 2014 · 9 comments
Closed

Crash in AppInit() upon start (EXCEPTION: NSt8ios_base7failureE) #115

pysiak opened this issue Jun 17, 2014 · 9 comments

Comments

@pysiak
Copy link

pysiak commented Jun 17, 2014

Hi,

On latest git, one of my namecoin installations is crashing upon start.
I suppose it might be reacting this way to corrupt files.

Any way I can help debugging it and hopefully find a way for namecoin to handle this?

solt@dev2:~/namecoin/src$ ./namecoind


************************
EXCEPTION: NSt8ios_base7failureE
CDataStream::read() : end of data
namecoin in AppInit()

terminate called after throwing an instance of 'std::ios_base::failure'
  what():  CDataStream::read() : end of data
Aborted
@domob1812
Copy link
Contributor

This means that one of the unserialisation routines fails. It is probably really related to corrupt data files (or a bug in the format upgrades done recently, but since the upgrade works in general, I don't see why it would fail for you). I don't really see what we could do about corrupt data files.

If you still want to find out more, you can run namecoind in a debugger (e. g., gdb with "catch throw") and see where exactly (backtrace) the exception is thrown.

@phelixbtc
Copy link
Contributor

I ran into this one once when I had renamed/deleted blkindex.dat IIRC. I had to rename my Namecoin directory and redownload the blockchain (once it is finished you can copy the wallet.dat to the new data folder).
Edit: Could be that I also mixed versions to provoke the error. Stick to the new version!

@pysiak
Copy link
Author

pysiak commented Jun 17, 2014

I'll most probably end up doing what phelixbtc suggests.
In the mean time. I recompiled with -ggdb3 and did a backtrace. It's at:

Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1                                                                                        ".
[New Thread 0xb6d5db70 (LWP 8603)]
Catchpoint 1 (exception thrown), 0xb7eff160 in __cxa_throw ()
   from /usr/lib/i386-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0xb7eff160 in __cxa_throw () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#1  0x0806f891 in CDataStream::setstate (
    this=<error reading variable: Unhandled dwarf expression opcode 0xfa>,
    psz=0x83da2ec "CDataStream::read() : end of data", bits=4,
    this=<error reading variable: Unhandled dwarf expression opcode 0xfa>)
    at serialize.h:1028
#2  0x0807a834 in CDataStream::read (this=0xbffff064, pch=0xc390438 "",
    nSize=22) at serialize.h:1056
#3  0x08081bf7 in Unserialize<CDataStream, std::allocator<bool> > (is=...,
    v=..., nType=nType@entry=2, nVersion=nVersion@entry=37500)
    at serialize.h:590
#4  0x08082b5f in SerReadWrite<CDataStream, std::vector<bool> > (
    nVersion=37500, nType=2, obj=..., s=..., ser_action=...) at serialize.h:810
#5  CTxIndex::Unserialize<CDataStream> (this=0xbffff19c, s=..., nType=2,
    nVersion=37500) at main.h:794
#6  0x08082d71 in Unserialize<CDataStream, CTxIndex> (nVersion=37500, nType=2,
    is=..., a=...) at serialize.h:411
#7  operator>><CTxIndex> (obj=..., this=0xbffff064) at serialize.h:1125
#8  CDB::Read<std::pair<std::string, uint256>, CTxIndex> (
    this=this@entry=0xbffff240, key=..., value=...) at db.h:91
#9  0x08078779 in CTxDB::ReadTxIndex (this=0xbffff240, hash=..., txindex=...)
    at db.cpp:424
#10 0x080e2da0 in CWallet::ReacceptWalletTransactions (this=0xc380df0)
    at wallet.cpp:541
#11 0x0815874a in AppInit2 (argc=-1073744776, argv=0xbffff7a4) at init.cpp:467
#12 0x0815a2a8 in AppInit (argc=argc@entry=1, argv=argv@entry=0xbffff7a4)
    at init.cpp:116
#13 0x080536cb in main (argc=1, argv=0xbffff7a4) at init.cpp:102

Going up the trace I found dbset to contain references of blkindex.dat and nameindex.dat.
Can't tell which is having problems.

@pysiak
Copy link
Author

pysiak commented Jun 17, 2014

I know it's bad to suggest root causes, but could it be that a previous blkindex.dat rewrite didn't complete properly? Namecoind isn't running and this is my ~/.namecoin:

I know it's bad to suggest root causes, but could it be that a previous blkindex.dat rewrite didn't complete properly? Namecoind isn't running and this is my ~/.namecoin:
-rw-------  1 user user     630784 Jun 12 16:13 addr.dat
-rw-------  1 user user 1158031186 Jun 12 16:06 blk0001.dat
-rw-------  1 user user  517251072 Jun 17 12:50 blkindex.dat
-rw-------  1 user user  168435712 May 15 15:47 blkindex.dat.rewrite
drwx------  2 user user       4096 Jun 17 11:18 database
-rw-------  1 user user          0 Jun 17 11:21 db.log
-rw-------  1 user user     210693 Jun 17 17:47 debug.log
-rw-------  1 user user          0 Apr 25 13:32 .lock
-rw-r--r--  1 user user         67 Apr 28 09:55 namecoin.conf
-rw-------  1 user user   61640704 Jun 12 16:13 nameindex.dat
-rw-------  1 user user      94208 Jun 17 12:51 wallet.dat

@domob1812
Copy link
Contributor

From your backtrace it is clear that blkindex.dat is the problem. Also, as you observed, the rewrite should have finished. However, actually I believe that even if you killed the daemon while it was rewriting, there "shouldn't" be a problem (the database file would just be larger than necessary and contain lots of empty pages). However, I've not actually tested that, of course. So hopefully this doesn't indicate a "real" bug.

@pysiak
Copy link
Author

pysiak commented Jun 18, 2014

I don't know. Anyway, I removed blkindex.dat and restarted it and it's
synched up now and not crashing.
The incident is resolved, but perhaps the general question remains: how
should namecoind handle exceptions on trying to read a corrupted file.
Maybe an error message saying which file was impossible to read and suggest
removal?

On Tue, Jun 17, 2014 at 6:16 PM, Daniel Kraft [email protected]
wrote:

From your backtrace it is clear that blkindex.dat is the problem. Also, as
you observed, the rewrite should have finished. However, actually I believe
that even if you killed the daemon while it was rewriting, there
"shouldn't" be a problem (the database file would just be larger than
necessary and contain lots of empty pages). However, I've not actually
tested that, of course. So hopefully this doesn't indicate a "real" bug.


Reply to this email directly or view it on GitHub
#115 (comment).

Pysiak

@domob1812
Copy link
Contributor

Note that, as far as my understanding goes, you can't "recover" from a missing/corrupted blkindex.dat in the same way as you can recreate the nameindex. I believe that if you delete blkindex.dat (or have to delete it), then you also should remove the blk*.dat files since the whole blockchain will be downloaded again anyway. (Since I do not yet know fully how the networking code works, this may be wrong - but I believe it is the case. You should be able to see whether or not the blk0001.dat file is double its initial size after you have finished syncing.)

@pysiak
Copy link
Author

pysiak commented Jun 18, 2014

Well, that's what I thought so too and I figured blk.dat files need to go
as well, so I removed them together with blkindex.dat yesterday. I forgot
to mention that. Not sure about the size, I think it's similar size now. I
was low on disk space and I have more now, but I removed the .rewrite.
Perhaps if we know how much disk space is required for the rewrite,
namecoind could check if there's enough?

On Wed, Jun 18, 2014 at 11:15 AM, Daniel Kraft [email protected]
wrote:

Note that, as far as my understanding goes, you can't "recover" from a
missing/corrupted blkindex.dat in the same way as you can recreate the
nameindex. I believe that if you delete blkindex.dat (or have to delete
it), then you also should remove the blk*.dat files since the whole
blockchain will be downloaded again anyway. (Since I do not yet know fully
how the networking code works, this may be wrong - but I believe it is the
case. You should be able to see whether or not the blk0001.dat file is
double its initial size after you have finished syncing.)


Reply to this email directly or view it on GitHub
#115 (comment).

Pysiak

@phelixbtc
Copy link
Contributor

Closing as this issue did not bubble up any more.

domob1812 pushed a commit to domob1812/namecoin that referenced this issue Dec 16, 2014
b0210a9 Merge pull request namecoin#135
ee3eb4b Fix a memory leak and add a number of small tests.
4d879a3 Merge pull request namecoin#134
d5e8362 Merge pull request namecoin#127
7b92cf6 Merge pull request namecoin#132
0bf70a5 Merge pull request namecoin#133
29ae131 Make scalar_add_bit test's overflow detection exact
9048def Avoid undefined shift behaviour
efb7d4b Use constant-time conditional moves instead of byte slicing
d220062 Merge pull request namecoin#131
82f9254 Fix typo
601ca04 Merge pull request namecoin#129
35399e0 Bugfix: b is restricted, not r
c35ff1e Convert lambda splitter to pure scalar code.
cc604e9 Avoid division when decomposing scalars
ff8746d Add secp256k1_scalar_mul_shift_var
bd313f7 Merge pull request namecoin#119
276f987 Merge pull request namecoin#124
25d125e Merge pull request namecoin#126
24b3c65 Add a test case for ECDSA recomputing infinity
32600e5 Add a test for r >= order signature handling
4d4eeea Make secp256k1_fe_mul_inner use the r != property
be82e92 Require that r and b are different for field multiplication.
597128d Make num optional
659b554 Make constant initializers independent from num
0af5b47 Merge pull request namecoin#120
e2e8a36 Merge pull request namecoin#117
c76be9e Remove unused num functions
4285a98 Move lambda-splitting code to scalar.
f24041d Switch all EC/ECDSA logic from num to scalar
6794be6 Add scalar splitting functions
d1502eb Add secp256k1_scalar_inverse_var which delegates to GMP
b5c9ee7 Make test_point_times_order test meaningful again
0b73059 Switch wnaf splitting from num-based to scalar-based
1e6c77c Generalize secp256k1_scalar_get_bits
5213207 Add secp256k1_scalar_add_bit
3c0ae43 Merge pull request namecoin#122
6e05287 Do signature recovery/verification with 4 possible recid case
e3d692f Explain why no y=0 check is necessary for doubling
f7dc1c6 Optimize doubling: secp256k1 has no y=0 point
666d3b5 Merge pull request namecoin#121
2a54f9b Correct typo in comment
9d64145 Merge pull request namecoin#114
99f0728 Fix secp256k1_num_set_bin handling of 0
d907ebc Add bounds checking to field element setters
bb2cd94 Merge pull request namecoin#116
665775b Don't split the g factor when not using endomorphism
9431d6b Merge pull request namecoin#115
e2274c5 build: osx: attempt to work with homebrew keg-only packages

git-subtree-dir: src/secp256k1
git-subtree-split: b0210a95da433e048a11d298efbcc14eb423c95f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants