Pages:
Author

Topic: Building headless Bitcoin and Bitcoin-qt on Windows - page 50. (Read 419389 times)

full member
Activity: 131
Merit: 108
legendary
Activity: 1708
Merit: 1020
Has anybody ever managed to build with gcc 4.8?
newbie
Activity: 8
Merit: 0
I'm having some problems compiling.

First, mingw-get-setup.exe doesn't have the option to select prepackaged repository catalogues so it installs gcc 4.8.1-3. I selected all from Basic setup.

Then on the step where I compile OpenSSL:

Code:
cd /c/deps/
tar xvfz openssl-1.0.1e.tar.gz
cd openssl-1.0.1e
./config
make

all goes well until i type make and get these errors at the end:

...
make[1]: gcc: Command not found
make[1]: *** [cryptlib.o] Error 127
make[1]: Leaving directory '/c/deps/openssl-1.0.1e/crypto'
make[1]: *** [build_crypto] Error 1

I've looked everywhere but witout any luck. Anyone know what the problem is?
You got the wrong MinGW installer.... you need this one:

http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw-get-inst-20120426/mingw-get-inst-20120426.exe/download

Unfortunately the file is currently not available  Huh  Please eMail the MinGW guys to put it back up.

Somebody uploaded it here if you dare: https://mega.co.nz/#!iAU1hCoB!aNfcHgZko8U49l3Yf1vXEDhLw2sC4547Odx6M0cn5eg

I thought MinGW had a very bad setup experience before but their new installer is even worse.


Thx Smiley i'll try that.
legendary
Activity: 1708
Merit: 1020
I'm having some problems compiling.

First, mingw-get-setup.exe doesn't have the option to select prepackaged repository catalogues so it installs gcc 4.8.1-3. I selected all from Basic setup.

Then on the step where I compile OpenSSL:

Code:
cd /c/deps/
tar xvfz openssl-1.0.1e.tar.gz
cd openssl-1.0.1e
./config
make

all goes well until i type make and get these errors at the end:

...
make[1]: gcc: Command not found
make[1]: *** [cryptlib.o] Error 127
make[1]: Leaving directory '/c/deps/openssl-1.0.1e/crypto'
make[1]: *** [build_crypto] Error 1

I've looked everywhere but witout any luck. Anyone know what the problem is?
You got the wrong MinGW installer.... you need this one:

http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw-get-inst-20120426/mingw-get-inst-20120426.exe/download

Unfortunately the file is currently not available  Huh  Please eMail the MinGW guys to put it back up.

Somebody uploaded it here if you dare: https://mega.co.nz/#!iAU1hCoB!aNfcHgZko8U49l3Yf1vXEDhLw2sC4547Odx6M0cn5eg

I thought MinGW had a very bad setup experience before but their new installer is even worse.
newbie
Activity: 8
Merit: 0
I'm having some problems compiling.

First, mingw-get-setup.exe doesn't have the option to select prepackaged repository catalogues so it installs gcc 4.8.1-3. I selected all from Basic setup.

Then on the step where I compile OpenSSL:

Code:
cd /c/deps/
tar xvfz openssl-1.0.1e.tar.gz
cd openssl-1.0.1e
./config
make

all goes well until i type make and get these errors at the end:

...
make[1]: gcc: Command not found
make[1]: *** [cryptlib.o] Error 127
make[1]: Leaving directory '/c/deps/openssl-1.0.1e/crypto'
make[1]: *** [build_crypto] Error 1

I've looked everywhere but witout any luck. Anyone know what the problem is?
hero member
Activity: 675
Merit: 514
Quote
I did get a response mentioning symlinks on Linux. Now on windows there has been the .lnk file technology since Win95B at least, that's 18 years!
If you have at least Windows Vista and are using NTFS you can actually create symlinks or hardlinks:
http://technet.microsoft.com/en-us/library/cc753194(v=ws.10).aspx
sr. member
Activity: 260
Merit: 251
Here is a message I posted on the sourceforge bitcoin-development list, hoping for some comments, insight, etc.

Quote
Is it required, presumed, assumed, coincidence, chance or irrelevant that the three different databases in bitcoin:
1. the network addresses database, reflected in peers.dat
2. the levelDB block chain database (blocks/blknnnnn.dat, blocks/revnnnnn.dat, blocks/index/nnnnn.sst et al, chainstate/nnnnn.sst et al)
3. the Berkeley DB wallet database (db.log, wallet.dat, database/log.nnnnnnnnn1)
are all in the "datadir" directory?

I only ask since it would seem that a more mature (?) bitcoind or bitcoin-qt would optionally, like the three (databases) in separate paths or drives, etc. It would seem easier to transport, backup etc. the pieces one wants. I find the block chain database is the most important (time consuming), because of its size, to duplicate and transport in order to backup. This also attacks the "Criticism" section in
https://en.bitcoin.it/wiki/Bitcoin-Qt

The first question is: can one backup by just looking at the dates, and just back up those files with the equal or newer dates, and the "log, current and manifest" files? An initial then incremental backups, as it were.

I am thinking of the frailties of data on OS's such as Windows in the hands of the "less than adept" shall we say. Also if one takes part in backing up one's data, one may actually have some idea where it is!

I did get a response mentioning symlinks on Linux. Now on windows there has been the .lnk file technology since Win95B at least, that's 18 years! And I'm not sure how that could fool bitcoin into thinking the files were all in and off the [datadir]? Since the code dynamically creates and destroys files, I don't see how symlinks or .lnk files can be used in the process, without a lot of extra, OS specific code being written? But my way, started way back with
https://github.com/old-c-coder/bitcoin-git/commit/929019012dc7d93fd3ba59d8eb553e390211a713
see message #176, already (optionally) moves wallet.dat anywhere that a C++ fopen() can reach.

But I haven't tested whether C++ fopen() can transparently open what's in a .lnk file. But it would seem wiser to me to do as I suggested. Also since I already have "moved" all three of the Berkeley DB wallet files ... Grin I was just curious if there is any locking ramifications or benefits to this?

Ron
sr. member
Activity: 260
Merit: 251

As for running on another machine, just copy all dlls that the app requests into the same folder like bitcoin-qt.exe, this should do the job.
BTDT, sorry no joy yet.
Joy has been achieved! Though not only the five files mentioned (for me, libgcc_s_dw2-1.dll from the Qt/4.8.4/bin directory) and a sixth dll from MinGW/bin, mingwm10.dll

Now my bitcoin-qt.exe errors at exit the same way, but with 7 identical messages and a poorly done Windows exit message. Splatters the screen and other poorly executed stuff. XP is in better control.
Also as you noted, much earlier I believe, the lower right corner "spinner" is gone.

For me, both the release (~22MB) and my (~8MB) bitcoin-qt.exe are missing the solid orange (?) background in the lower left "progress bar area". I just see a series of what look to be empty character blocks spaced across the area, and faded text sort of behind? I could do a screen capture if anyone cares?
Quote
Quote
I never managed to get a true and full static build on my Win7 machine, but that's no problem as I don't redistribute my exe.
BTW are your Windows 7 bitcoin-qt.exes about 8,192KB - 8,793KB (8,377,856 - 9,004,032 Bytes)?
Quote
Edit 2: These are required even without miniupnp, Qt (QtCore4.dll QtGui4.dll QtNetwork4.dll) and MinGW (libgcc_s_dw2-1.dll and libstdc++-6.dll)!
I hit on this in message #194. And I found that I can 'statically' link libgcc_s_dw2-1.dll. I.e. don't need it at run time in the MinGW/bin nor Qt/4.8.4/bin directories.
Quote
Dia
Thanks again, and if anyone else is reading this and wants to chime in... I do see that this has been read 13927 times Grin
Ron
Ron

Just a heads up to those who experiment to find which dlls are needed for Qt. It seems that doing that can (may have, probably did?) mess up the lastest block in the levelDB database of the blockchain.

For the last few days, I have been unable to get past a startup error. In steps 8 / 9 of AppInit2() in the startup code in init.cpp Between the point where the pwalletMain->SetBestChain() and ConnectBestBlock() which fails with the error message from CLevelDB::Read(), the error was the "interesting" -30974, "panic return", DB_RUNRECOVERY.

I could not get past that until I put a backup blockchain in place. But that required moving the 11GB blockchain database from one machine to another.

After that, everything is going again!

So backup that blockchain database! Locally too, so you can get it back fast.

More on statically "linking" bitcoin-qt later...

Ron
sr. member
Activity: 260
Merit: 251

As for running on another machine, just copy all dlls that the app requests into the same folder like bitcoin-qt.exe, this should do the job.
BTDT, sorry no joy yet.
Joy has been achieved! Though not only the five files mentioned (for me, libgcc_s_dw2-1.dll from the Qt/4.8.4/bin directory) and a sixth dll from MinGW/bin, mingwm10.dll

Now my bitcoin-qt.exe errors at exit the same way, but with 7 identical messages and a poorly done Windows exit message. Splatters the screen and other poorly executed stuff. XP is in better control.
Also as you noted, much earlier I believe, the lower right corner "spinner" is gone.

For me, both the release (~22MB) and my (~8MB) bitcoin-qt.exe are missing the solid orange (?) background in the lower left "progress bar area". I just see a series of what look to be empty character blocks spaced across the area, and faded text sort of behind? I could do a screen capture if anyone cares?
Quote
Quote
I never managed to get a true and full static build on my Win7 machine, but that's no problem as I don't redistribute my exe.
BTW are your Windows 7 bitcoin-qt.exes about 8,192KB - 8,793KB (8,377,856 - 9,004,032 Bytes)?
Quote
Edit 2: These are required even without miniupnp, Qt (QtCore4.dll QtGui4.dll QtNetwork4.dll) and MinGW (libgcc_s_dw2-1.dll and libstdc++-6.dll)!
I hit on this in message #194. And I found that I can 'statically' link libgcc_s_dw2-1.dll. I.e. don't need it at run time in the MinGW/bin nor Qt/4.8.4/bin directories.
Quote
Dia
Thanks again, and if anyone else is reading this and wants to chime in... I do see that this has been read 13927 times Grin
Ron
Ron
sr. member
Activity: 260
Merit: 251
Ron, AFAIK the shutdown flow for Bitcoin-Qt is as follows (example here is RPC stop command):

- stop calls StartShutdown()
- setting fRequestShutdown to true
- detectShutdown() notices, via the if (ShutdownRequested())
- calls QMetaObject::invokeMethod(QCoreApplication::instance(), "quit", Qt::QueuedConnection);

Now go into bitcoin.cpp at the end below app.exec(), there all GUI stuff is hidden, threads are terminated and Shutdown() is called.

If you just click exit in Bitcoin-Qt this triggers the following in bitcoingui.cpp:
connect(quitAction, SIGNAL(triggered()), qApp, SLOT(quit()));

And afterwards we are after the app.exec() call, because app is ending.

That is what I thought too, until I exited normally and saw the error messages! Which suggests to me that shutdown is never called or if called, is never allowed to finish?

Quote
I'm confident, that your observed Bitcoin-Qt crashes are a problem of your build process perhaps.
That is what I like, a "confident" "perhaps"Cheesy
Quote

I never used the UPnP lib for example and don't see such errors with my local builds.
Do you mean warnings instead of errors? The compile finishes and generates an exe.
Quote

As for running on another machine, just copy all dlls that the app requests into the same folder like bitcoin-qt.exe, this should do the job.
BTDT, sorry no joy yet.
Quote

I never managed to get a true and full static build on my Win7 machine, but that's no problem as I don't redistribute my exe.
BTW are your Windows 7 bitcoin-qt.exes about 8,192KB - 8,793KB (8,377,856 - 9,004,032 Bytes)?
Quote

Edit: And to the bitcoind.exe stuff, I'm looking forward to a current version based on latest master Smiley. I would love to see you using some of our coding conventions use f in front of bools for example and no underscores (e.g. bool fStateXYZ) also I think some of the comments are too long and detailed for the core-devs, but I would love to see your patch getting merged, if we HAVE a problem there, which I think we have without beeing able to confirm currently.
Sure I'll do the f-flag, no spaces, camel case (or whatever). I do prefer the GNU indenting style (I hate K&R if you can't tell!), etc. etc. But that code was for the stackoverflow link, and was MS VC++ code, so it was exempt from bitcoin coding guidelines Smiley Or so I thought!
Quote

I found one strange thing, dunno if that is relevant, but bitcoin-qt (code in bitcoin.cpp) calls threadGroup.join_all(); on exit, which bitcoind (code in bitcoind.cpp) does NOT. Any idea for this, perhaps related to the error? I have not yet checked, what that call does... Gavin?

Edit 2: These are required even without miniupnp, Qt (QtCore4.dll QtGui4.dll QtNetwork4.dll) and MinGW (libgcc_s_dw2-1.dll and libstdc++-6.dll)!
I hit on this in message #194. And I found that I can 'statically' link libgcc_s_dw2-1.dll. I.e. don't need it at run time in the MinGW/bin nor Qt/4.8.4/bin directories.
Quote
Dia

Thanks again, and if anyone else is reading this and wants to chime in... I do see that this has been read 13927 times Grin

Ron
hero member
Activity: 772
Merit: 500
Ron, AFAIK the shutdown flow for Bitcoin-Qt is as follows (example here is RPC stop command):

- stop calls StartShutdown()
- setting fRequestShutdown to true
- detectShutdown() notices, via the if (ShutdownRequested())
- calls QMetaObject::invokeMethod(QCoreApplication::instance(), "quit", Qt::QueuedConnection);

Now go into bitcoin.cpp at the end below app.exec(), there all GUI stuff is hidden, threads are terminated and Shutdown() is called.

If you just click exit in Bitcoin-Qt this triggers the following in bitcoingui.cpp:
connect(quitAction, SIGNAL(triggered()), qApp, SLOT(quit()));

And afterwards we are after the app.exec() call, because app is ending.

I'm confident, that your observed Bitcoin-Qt crashes are a problem of your build process perhaps.
I never used the UPnP lib for example and don't see such errors with my local builds.
As for running on another machine, just copy all dlls that the app requests into the same folder like bitcoin-qt.exe, this should do the job.
I never managed to get a true and full static build on my Win7 machine, but that's no problem as I don't redistribute my exe.

Edit: And to the bitcoind.exe stuff, I'm looking forward to a current version based on latest master Smiley. I would love to see you using some of our coding conventions use f in front of bools for example and no underscores (e.g. bool fStateXYZ) also I think some of the comments are too long and detailed for the core-devs, but I would love to see your patch getting merged, if we HAVE a problem there, which I think we have without beeing able to confirm currently.

I found one strange thing, dunno if that is relevant, but bitcoin-qt (code in bitcoin.cpp) calls threadGroup.join_all(); on exit, which bitcoind (code in bitcoind.cpp) does NOT. Any idea for this, perhaps related to the error? I have not yet checked, what that call does... Gavin?

Edit 2: These are required even without miniupnp, Qt (QtCore4.dll QtGui4.dll QtNetwork4.dll) and MinGW (libgcc_s_dw2-1.dll and libstdc++-6.dll)!

Dia
sr. member
Activity: 260
Merit: 251
Let's try again.



and the six together look like this:


They all dismiss when any one is clicked.

The 22MB bitcoin-qt.exe (0.8.4 & 0.8.5) release code (bitcoin-0.8.5-win32-setup.exe from sourceforge) exits OK on my machine, but previous versions were not reliable, as I remember.

Now as to your explanation of the execution of the code on shutdown.

Quote
I don't see, why the RPC stop would cause issues, I tried it with Bitcoin-Qts debug window and saw a clean shutdown. Can you explain why you think that doesn't work?

Stop calls StartShutdown(), which just sets fRequestShutdown = true;, which get's catched by the void BitcoinGUI::detectShutdown() thread for Bitcoin-Qt AFAIK.

I see that stop calls StartShutdown(), setting  fRequestShutdown to true, which detectShutdown() notices, via the if (ShutdownRequested()), which does
        QMetaObject::invokeMethod(QCoreApplication::instance(), "quit", Qt::QueuedConnection);

Now I have little appreciation for what this compilicated line of code does!

My question is: what is running in the background that can or will see  and will/does call Shutdown(), and the ~CNetCleanup() and ~CMainCleanup() destructors?

I do see them in bitcoind.exe on my Ctl-c, Ctl-break, close window, log off user and program shut down (outside) events.

I don't claim to know how to make bitcoin-qt.exe leave a debug trail the way bitcoind.exe can, but the pop up errors suggest that things ain't right?

On bitcoind.exe, one sees the
        printf("EnvShutdown exception: %s (%d)\n", DbEnv::strerror(ret), ret);
line before I added the missing code (for Windows) to trap the Ctl-c et al events.

Whew. So that's the story! I have a newer version of my code, that traps all 5 events, but as stated previously, I am (only temporarily) locked out of the GitHub "fork-clone-commit" loop and I will resubmit the new changes soon,  with a newer identity (!), but the old pull is still there.

Ron


sr. member
Activity: 260
Merit: 251
Hello Gavin,

I read your code comment, but that is how it should work (on Windows) but can't and doesn't with exit/stop for bitcoin-qt nor Ctl-C for bitcoind!

You have to trap the Ctl-C in order to set fRequestShutdown! If you don't, Windows boots you out, which is what happens now with the current code. There is nothing trapping Ctl-C in the Windows code.

All I'm doing is trapping the Ctl-C and calling the current HandleSIGTERM().

And I respectfully disagree with your comments on bitcoin-qt. It should but never calls HandleSIGTERM() on Windows anyway. All of which I stated in my change.

Ron

I don't see, why the RPC stop would cause issues, I tried it with Bitcoin-Qts debug window and saw a clean shutdown. Can you explain why you think that doesn't work?

Stop calls StartShutdown(), which just sets fRequestShutdown = true;, which get's catched by the void BitcoinGUI::detectShutdown() thread for Bitcoin-Qt AFAIK.

I'm with you that a Ctrl+C in a console window is another story and I see your patch could prevent bad things from happening there by ensuring a clean shutdown for bitcoind.exe.

Quote
Preliminary tests show interestingly that on XP, all 5 cases obtain, but on Windows 7, only Ctl-C and Ctl-break are trapped, the other cases are not.
As we currently have no code anyway to handle Windows shutdown I would vote for only adding the cases in the code we CAN handle and mention the other cases only in a comment. If you are fine with it, I would take your patch, modify it to fit what I said and create a pull-request.

Dia

Thanks Dia for looking at my code. As per message #179 & #180, i.e. I unknowingly fork-cloned the wrong thing in GitHub, using GitHub for Windows, I was locked out of further fork-clone-commits. This does not mean I havent downloaded the zips. And I do have 0.8.5 versions of my changes. I just can't create a commit-pull request until I create another identity! See mesage #184.

In any event, the story is complicated. Using Nitrogenetics prescription, the Qt exe is not ~22MB in size but only ~8MB in size. This is due, I presume to the fact that that exe requires the presence of (at least) 5 .DLLs,

...MinGW/bin/libstdc++-6.dll  {LFLAGS += -static in makefile.release fixes this one!!!!)

...Qt\4.8.4\bin\libgcc_s_dw2-1.dll

...Qt\4.8.4\bin\QtCore4.dll
...Qt\4.8.4\bin\QtGui4.dll
...Qt\4.8.4\bin\QtNetwork4.dll

But nitrogenetics said this in message #1, which I will quote:
Code:
"USE_UPNP=-" will build bitcoin-qt without UPNP support.
Compiling with UPNP support will require miniupnpc libraries. See: http://miniupnp.tuxfamily.org/files/
Qt (QtCore4.dll QtGui4.dll QtNetwork4.dll) and MinGW (libgcc_s_dw2-1.dll and libstdc++-6.dll) libraries will need to be distributed along with the executable.

It isn't clear to me whether these dlls are needed because of UPNP being on or not?
As above the Qt.exe grows ~700KB with the -static gcc argument and the
MinGW/bin/libstdc++-6.dll requirement vanishes.

This precludes me testing my code on my other W7 machine, at the moment, since I haven't been able to place those DLLs where the QT exe can find them or W7 will allow them to be seen, or some other strange requirement (register server stuff, etc.).

I can only test my Qt builds on my machine. And when I do a normal File->Exit, i.e. Ctl-Q or a stop, I get, and have always gotten 4, 5 or 6 identical error dialog boxes, sometime with a short delay in the last one or two of them. They each look like

great! can't seem to imbed the pix in a response? Will continue in the next message...

Ron
hero member
Activity: 772
Merit: 500
Hello Gavin,

I read your code comment, but that is how it should work (on Windows) but can't and doesn't with exit/stop for bitcoin-qt nor Ctl-C for bitcoind!

You have to trap the Ctl-C in order to set fRequestShutdown! If you don't, Windows boots you out, which is what happens now with the current code. There is nothing trapping Ctl-C in the Windows code.

All I'm doing is trapping the Ctl-C and calling the current HandleSIGTERM().

And I respectfully disagree with your comments on bitcoin-qt. It should but never calls HandleSIGTERM() on Windows anyway. All of which I stated in my change.

Ron

I don't see, why the RPC stop would cause issues, I tried it with Bitcoin-Qts debug window and saw a clean shutdown. Can you explain why you think that doesn't work?

Stop calls StartShutdown(), which just sets fRequestShutdown = true;, which get's catched by the void BitcoinGUI::detectShutdown() thread for Bitcoin-Qt AFAIK.

I'm with you that a Ctrl+C in a console window is another story and I see your patch could prevent bad things from happening there by ensuring a clean shutdown for bitcoind.exe.

Quote
Preliminary tests show interestingly that on XP, all 5 cases obtain, but on Windows 7, only Ctl-C and Ctl-break are trapped, the other cases are not.
As we currently have no code anyway to handle Windows shutdown I would vote for only adding the cases in the code we CAN handle and mention the other cases only in a comment. If you are fine with it, I would take your patch, modify it to fit what I said and create a pull-request.

Dia
sr. member
Activity: 260
Merit: 251
I really only use bitcoin-qt.exe, so I can't comment on bitcoind.exe. But I think it's worth opening an issue ticket on Github so that other devs get attention and can take a look.
You also should take a look here: http://stackoverflow.com/questions/3640633/c-setconsolectrlhandler-routine-issue

Dia

Hello Dia

Thanks for responding. As to that stackoverflow thread, what a disjointed thread that is. The code is incomplete and the answers are mostly half truths! The code should look like this (for VC++ Express 2005, but would work with most VCs):
Code:
#include "stdafx.h"

#include
#include

bool
   we_had_better_quit = false;

BOOL WINAPI ConsoleHandlerRoutine(DWORD the_signal)
{
switch( the_signal )
    {

    case CTRL_C_EVENT:          //A CTRL+c signal was received,
                                //either from keyboard input     
                                //or from a signal generated by the   
                                //GenerateConsoleCtrlEvent function   

    case CTRL_BREAK_EVENT:      //A CTRL+BREAK signal was received,
                                //either from keyboard input     
                                //or from a signal generated by the   
                                //GenerateConsoleCtrlEvent function   

    case CTRL_CLOSE_EVENT:      // A signal that the system sends to all processes
                                // attached to a console when the user closes
                                // the console (either by choosing the Close
                                // command from the console window's System menu,
                                // or by choosing the End Task command from the
                                // Task List).

    case CTRL_LOGOFF_EVENT:     //A signal that the system sends to all console
                                // processes when a user is logging off. This
                                // signal does not indicate which user is
                                // logging off, so no assumptions can be made.

    case CTRL_SHUTDOWN_EVENT:   // I think we should do something here too?   

         we_had_better_quit = true;
        return true;

    default:                    // any other (strange) signal we pass on
        break;                  // and just let it happen?
    }

//    if (dwCtrlType == CTRL_CLOSE_EVENT)
//    {
//        return true;
//    }
return false;
}

int _tmain(int argc, _TCHAR* argv[])
{
BOOL
   ret = SetConsoleCtrlHandler(ConsoleHandlerRoutine, true);
// we apparently don't care if it fails or not, but we should!

while (true)
   {
   //Sleep(1000);
   Sleep(15000);     // 15 seconds just to see what Windows7 is up to!
   if( true == we_had_better_quit )
      {
      (void)printf( "\x7" );  // let you know that you trapped it!
      break;
      }
   }
return 0;
}
The 15 seconds is just to show that the 10 seconds mentioned for Windows 7 is wrong. The bell code is to show one that it did pick up the signal.

Preliminary tests show interestingly that on XP, all 5 cases obtain, but on Windows 7, only Ctl-C and Ctl-break are trapped, the other cases are not.

Ron
sr. member
Activity: 260
Merit: 251
sr. member
Activity: 260
Merit: 251
Am I really the only one who ever exits bitcoind.exe on a windows machine, or shuts that machine down, or closes bitcoind.exe's window or ends the bitcoind.exe process (task manager, etc.)?
There has to be someone who has seen this on bitcoind.exe 0.8.2, 0.8.3, 0.8.4, 0.8.5?
Well, I usually use the stop command with bitcoind.
But if I use crtl C then it happens here too.
This is what Dr. Mingw reports after the crash:
Code:
bitcoind.exe caused an Access Violation at location 8D32C000 Writing to location 8D32C000.

Registers:
eax=0a08fad8 ebx=00a62300 ecx=00b98bd0 edx=8d32c000 esi=00b9f714 edi=00b9f714
eip=8d32c000 esp=0a08fa30 ebp=0a08faec iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202

AddrPC   Params
8D32C000 00B98BD0 0A08FAD8 00B9F714
0057F569 0A08FC50 0A08FD0C 00B98BD0 bitcoind.exe
0057F89B 00B9F714 00B9F760 0A08FD0C bitcoind.exe
00417339 00A62300 00000000 00000001 bitcoind.exe
00417424 00A62300 00000000 0A08FDBC bitcoind.exe
00417690 5F61F810 00000000 0A08FE30 bitcoind.exe
769FC3E9 00000000 00000000 00000001 msvcrt.dll!isspace
76A037DF 00000001 0A08FE3C 774999A0 msvcrt.dll!_cexit
769FA48C 769F0000 00000000 00000001 msvcrt.dll!_lock
774999A0 769FA472 769F0000 00000000 ntdll.dll!RtlQueryEnvironmentVariable
774AD702 00000000 00000000 00000000 ntdll.dll!LdrShutdownProcess
774AD5A4 00000000 76476E51 00000000 ntdll.dll!RtlExitUserProcess
76476C96 00000000 0A08FFD4 77499F72 kernel32.dll!AttachConsole
763D336A 00000000 7D5DBFDA 00000000 kernel32.dll!BaseThreadInitThunk
77499F72 76476C9C 00000000 00000000 ntdll.dll!RtlInitializeExceptionChain
77499F45 76476C9C 00000000 00000000 ntdll.dll!RtlInitializeExceptionChain

This should really be reported to: https://github.com/bitcoin/bitcoin/issues!

Thanks,
Dia

Hi Dia,

See message #164 in this forum (fora) which first mentions:
https://github.com/old-c-coder/bitcoin-git/commit/0bd51c5ddd39e2e5adb1d1455b80c3a9e03b410b

Ron
hero member
Activity: 772
Merit: 500
Am I really the only one who ever exits bitcoind.exe on a windows machine, or shuts that machine down, or closes bitcoind.exe's window or ends the bitcoind.exe process (task manager, etc.)?
There has to be someone who has seen this on bitcoind.exe 0.8.2, 0.8.3, 0.8.4, 0.8.5?
Well, I usually use the stop command with bitcoind.
But if I use crtl C then it happens here too.
This is what Dr. Mingw reports after the crash:
Code:
bitcoind.exe caused an Access Violation at location 8D32C000 Writing to location 8D32C000.

Registers:
eax=0a08fad8 ebx=00a62300 ecx=00b98bd0 edx=8d32c000 esi=00b9f714 edi=00b9f714
eip=8d32c000 esp=0a08fa30 ebp=0a08faec iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202

AddrPC   Params
8D32C000 00B98BD0 0A08FAD8 00B9F714
0057F569 0A08FC50 0A08FD0C 00B98BD0 bitcoind.exe
0057F89B 00B9F714 00B9F760 0A08FD0C bitcoind.exe
00417339 00A62300 00000000 00000001 bitcoind.exe
00417424 00A62300 00000000 0A08FDBC bitcoind.exe
00417690 5F61F810 00000000 0A08FE30 bitcoind.exe
769FC3E9 00000000 00000000 00000001 msvcrt.dll!isspace
76A037DF 00000001 0A08FE3C 774999A0 msvcrt.dll!_cexit
769FA48C 769F0000 00000000 00000001 msvcrt.dll!_lock
774999A0 769FA472 769F0000 00000000 ntdll.dll!RtlQueryEnvironmentVariable
774AD702 00000000 00000000 00000000 ntdll.dll!LdrShutdownProcess
774AD5A4 00000000 76476E51 00000000 ntdll.dll!RtlExitUserProcess
76476C96 00000000 0A08FFD4 77499F72 kernel32.dll!AttachConsole
763D336A 00000000 7D5DBFDA 00000000 kernel32.dll!BaseThreadInitThunk
77499F72 76476C9C 00000000 00000000 ntdll.dll!RtlInitializeExceptionChain
77499F45 76476C9C 00000000 00000000 ntdll.dll!RtlInitializeExceptionChain

This should really be reported to: https://github.com/bitcoin/bitcoin/issues!

Thanks,
Dia
hero member
Activity: 675
Merit: 514
Am I really the only one who ever exits bitcoind.exe on a windows machine, or shuts that machine down, or closes bitcoind.exe's window or ends the bitcoind.exe process (task manager, etc.)?
There has to be someone who has seen this on bitcoind.exe 0.8.2, 0.8.3, 0.8.4, 0.8.5?
Well, I usually use the stop command with bitcoind.
But if I use crtl C then it happens here too.
This is what Dr. Mingw reports after the crash:
Code:
bitcoind.exe caused an Access Violation at location 8D32C000 Writing to location 8D32C000.

Registers:
eax=0a08fad8 ebx=00a62300 ecx=00b98bd0 edx=8d32c000 esi=00b9f714 edi=00b9f714
eip=8d32c000 esp=0a08fa30 ebp=0a08faec iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202

AddrPC   Params
8D32C000 00B98BD0 0A08FAD8 00B9F714
0057F569 0A08FC50 0A08FD0C 00B98BD0 bitcoind.exe
0057F89B 00B9F714 00B9F760 0A08FD0C bitcoind.exe
00417339 00A62300 00000000 00000001 bitcoind.exe
00417424 00A62300 00000000 0A08FDBC bitcoind.exe
00417690 5F61F810 00000000 0A08FE30 bitcoind.exe
769FC3E9 00000000 00000000 00000001 msvcrt.dll!isspace
76A037DF 00000001 0A08FE3C 774999A0 msvcrt.dll!_cexit
769FA48C 769F0000 00000000 00000001 msvcrt.dll!_lock
774999A0 769FA472 769F0000 00000000 ntdll.dll!RtlQueryEnvironmentVariable
774AD702 00000000 00000000 00000000 ntdll.dll!LdrShutdownProcess
774AD5A4 00000000 76476E51 00000000 ntdll.dll!RtlExitUserProcess
76476C96 00000000 0A08FFD4 77499F72 kernel32.dll!AttachConsole
763D336A 00000000 7D5DBFDA 00000000 kernel32.dll!BaseThreadInitThunk
77499F72 76476C9C 00000000 00000000 ntdll.dll!RtlInitializeExceptionChain
77499F45 76476C9C 00000000 00000000 ntdll.dll!RtlInitializeExceptionChain
hero member
Activity: 686
Merit: 504
always the student, never the master.
well i'm not typically a windows user. it just happens to be easire to setup my miners and run stuff like photoshop and fl studio on. recently i've given another go at compiling the two alt coins i develop and maintain(though someone else usually compiles the windows binaries on my behalf) on windows, and i'm stumped with another meaningless error, meanwhile of which both compile succesfully under linux without so much as a hiccup other than a warning about an unused variable in main.cpp. windows is worthless in my opinion, but most people use it.


                     ^
..\deps\boost/boost/iterator/iterator_facade.hpp:814:7: note: in expansion of ma
cro 'BOOST_STATIC_ASSERT'
       BOOST_STATIC_ASSERT((
 \
       ^
..\deps\boost/boost/iterator/iterator_facade.hpp:842:3: note: in expansion of ma
cro 'BOOST_ITERATOR_FACADE_INTEROP'
   BOOST_ITERATOR_FACADE_INTEROP(
   ^
..\deps\boost/boost/iterator/iterator_adaptor.hpp: In function 'void boost::deta
il::iterator_adaptor_assert_traversal()':
..\deps\boost/boost/static_assert.hpp:125:21: warning: typedef 'boost_static_ass
ert_typedef_224' locally defined but not used [-Wunused-local-typedefs]
          BOOST_JOIN(boost_static_assert_typedef_, __LINE__)
                     ^
..\deps\boost/boost/iterator/iterator_adaptor.hpp:224:7: note: in expansion of m
acro 'BOOST_STATIC_ASSERT'
       BOOST_STATIC_ASSERT((is_convertible::value));
       ^
In file included from ..\deps\boost/boost/tuple/tuple.hpp:33:0,
                 from src\serialize.h:20,
                 from src\netbase.h:12,
                 from src\net.h:20,
                 from src\irc.cpp:9:
..\deps\boost/boost/tuple/detail/tuple_basic.hpp: In function 'typename boost::t
uples::access_traitsTT> >::type>::const_type boost::tuples::get(const boost::tuples::cons&)'
:
..\deps\boost/boost/tuple/detail/tuple_basic.hpp:228:45: warning: typedef 'cons_
element' locally defined but not used [-Wunused-local-typedefs]
   typedef BOOST_DEDUCED_TYPENAME impl::type cons_element;
                                             ^
In file included from ..\deps\boost/boost/config.hpp:57:0,
                 from ..\deps\boost/boost/detail/workaround.hpp:41,
                 from ..\deps\boost/boost/array.hpp:33,
                 from src\net.h:11,
                 from src\irc.cpp:9:
..\deps\boost/boost/tuple/detail/tuple_basic.hpp: In member function 'boost::tup
les::cons& boost::tuples::cons::operator=(const std::pair<_U1, _
U2>&)':
..\deps\boost/boost/static_assert.hpp:125:21: warning: typedef 'boost_static_ass
ert_typedef_325' locally defined but not used [-Wunused-local-typedefs]
          BOOST_JOIN(boost_static_assert_typedef_, __LINE__)
                     ^
..\deps\boost/boost/tuple/detail/tuple_basic.hpp:325:5: note: in expansion of ma
cro 'BOOST_STATIC_ASSERT'
     BOOST_STATIC_ASSERT(length::value == 2); // check length = 2
     ^
..\deps\boost/boost/tuple/detail/tuple_basic.hpp: In member function 'boost::tup
les::tuple& boost::tuples::tuple T2, T3, T4, T5, T6, T7, T8, T9>::operator=(const std::pair<_U1, _U2>&)':
..\deps\boost/boost/static_assert.hpp:125:21: warning: typedef 'boost_static_ass
ert_typedef_582' locally defined but not used [-Wunused-local-typedefs]
          BOOST_JOIN(boost_static_assert_typedef_, __LINE__)
                     ^
..\deps\boost/boost/tuple/detail/tuple_basic.hpp:582:5: note: in expansion of ma
cro 'BOOST_STATIC_ASSERT'
     BOOST_STATIC_ASSERT(length::value == 2);// check_length = 2
     ^
..\deps\boost/boost/tuple/tuple_comparison.hpp: In function 'bool boost::tuples:
:operator==(const boost::tuples::cons&, const boost::tuples::cons>&)':
..\deps\boost/boost/static_assert.hpp:125:21: warning: typedef 'boost_static_ass
ert_typedef_114' locally defined but not used [-Wunused-local-typedefs]
          BOOST_JOIN(boost_static_assert_typedef_, __LINE__)
                     ^
..\deps\boost/boost/tuple/tuple_comparison.hpp:114:3: note: in expansion of macr
o 'BOOST_STATIC_ASSERT'
   BOOST_STATIC_ASSERT(length::value == length::value);
   ^
..\deps\boost/boost/tuple/tuple_comparison.hpp: In function 'bool boost::tuples:
:operator!=(const boost::tuples::cons&, const boost::tuples::cons>&)':
..\deps\boost/boost/static_assert.hpp:125:21: warning: typedef 'boost_static_ass
ert_typedef_126' locally defined but not used [-Wunused-local-typedefs]
          BOOST_JOIN(boost_static_assert_typedef_, __LINE__)
                     ^
..\deps\boost/boost/tuple/tuple_comparison.hpp:126:3: note: in expansion of macr
o 'BOOST_STATIC_ASSERT'
   BOOST_STATIC_ASSERT(length::value == length::value);
   ^
..\deps\boost/boost/tuple/tuple_comparison.hpp: In function 'bool boost::tuples:
:operator<(const boost::tuples::cons&, const boost::tuples::cons
&)':
..\deps\boost/boost/static_assert.hpp:125:21: warning: typedef 'boost_static_ass
ert_typedef_136' locally defined but not used [-Wunused-local-typedefs]
          BOOST_JOIN(boost_static_assert_typedef_, __LINE__)
                     ^
..\deps\boost/boost/tuple/tuple_comparison.hpp:136:3: note: in expansion of macr
o 'BOOST_STATIC_ASSERT'
   BOOST_STATIC_ASSERT(length::value == length::value);
   ^
..\deps\boost/boost/tuple/tuple_comparison.hpp: In function 'bool boost::tuples:
:operator>(const boost::tuples::cons&, const boost::tuples::cons
&)':
..\deps\boost/boost/static_assert.hpp:125:21: warning: typedef 'boost_static_ass
ert_typedef_146' locally defined but not used [-Wunused-local-typedefs]
          BOOST_JOIN(boost_static_assert_typedef_, __LINE__)
                     ^
..\deps\boost/boost/tuple/tuple_comparison.hpp:146:3: note: in expansion of macr
o 'BOOST_STATIC_ASSERT'
   BOOST_STATIC_ASSERT(length::value == length::value);
   ^
..\deps\boost/boost/tuple/tuple_comparison.hpp: In function 'bool boost::tuples:
:operator<=(const boost::tuples::cons&, const boost::tuples::cons>&)':
..\deps\boost/boost/static_assert.hpp:125:21: warning: typedef 'boost_static_ass
ert_typedef_156' locally defined but not used [-Wunused-local-typedefs]
          BOOST_JOIN(boost_static_assert_typedef_, __LINE__)
                     ^
..\deps\boost/boost/tuple/tuple_comparison.hpp:156:3: note: in expansion of macr
o 'BOOST_STATIC_ASSERT'
   BOOST_STATIC_ASSERT(length::value == length::value);
   ^
..\deps\boost/boost/tuple/tuple_comparison.hpp: In function 'bool boost::tuples:
:operator>=(const boost::tuples::cons&, const boost::tuples::cons>&)':
..\deps\boost/boost/static_assert.hpp:125:21: warning: typedef 'boost_static_ass
ert_typedef_166' locally defined but not used [-Wunused-local-typedefs]
          BOOST_JOIN(boost_static_assert_typedef_, __LINE__)
                     ^
..\deps\boost/boost/tuple/tuple_comparison.hpp:166:3: note: in expansion of macr
o 'BOOST_STATIC_ASSERT'
   BOOST_STATIC_ASSERT(length::value == length::value);
   ^
In file included from src\compat.h:18:0,
                 from src\netbase.h:13,
                 from src\net.h:20,
                 from src\irc.cpp:9:
c:\mingw\include\ws2tcpip.h: At global scope:
c:\mingw\include\ws2tcpip.h:143:8: error: redefinition of 'struct ip_mreq'
 struct ip_mreq {
        ^
In file included from c:\mingw\include\windows.h:93:0,
                 from ..\deps\ssl\include/openssl/rand.h:67,
                 from src\net.h:13,
                 from src\irc.cpp:9:
c:\mingw\include\winsock.h:315:8: error: previous definition of 'struct ip_mreq'

 struct ip_mreq {
        ^
In file included from src\compat.h:18:0,
                 from src\netbase.h:13,
                 from src\net.h:20,
                 from src\irc.cpp:9:
c:\mingw\include\ws2tcpip.h:386:13: error: expected initializer before 'freeaddr
info'
 void WSAAPI freeaddrinfo (struct addrinfo*);
             ^
c:\mingw\include\ws2tcpip.h:387:12: error: expected initializer before 'getaddri
nfo'
 int WSAAPI getaddrinfo (const char*,const char*,const struct addrinfo*,
            ^
c:\mingw\include\ws2tcpip.h:389:12: error: expected initializer before 'getnamei
nfo'
 int WSAAPI getnameinfo(const struct sockaddr*,socklen_t,char*,DWORD,
            ^
In file included from ..\deps\boost/boost/system/system_error.hpp:14:0,
                 from ..\deps\boost/boost/thread/exceptions.hpp:22,
                 from ..\deps\boost/boost/thread/win32/thread_primitives.hpp:16,

                 from ..\deps\boost/boost/thread/win32/thread_data.hpp:11,
                 from ..\deps\boost/boost/thread/thread.hpp:15,
                 from ..\deps\boost/boost/thread.hpp:13,
                 from src\util.h:23,
                 from src\addrman.h:9,
                 from src\net.h:22,
                 from src\irc.cpp:9:
..\deps\boost/boost/system/error_code.hpp:214:36: warning: 'boost::system::posix
_category' defined but not used [-Wunused-variable]
     static const error_category &  posix_category = generic_category();
                                    ^
..\deps\boost/boost/system/error_code.hpp:215:36: warning: 'boost::system::errno
_ecat' defined but not used [-Wunused-variable]
     static const error_category &  errno_ecat     = generic_category();
                                    ^
..\deps\boost/boost/system/error_code.hpp:216:36: warning: 'boost::system::nativ
e_ecat' defined but not used [-Wunused-variable]
     static const error_category &  native_ecat    = system_category();
                                    ^
makefile.release:1033: recipe for target 'build/irc.o' failed
mingw32-make: *** [build/irc.o] Error 1

C:\nanotoken-master>
Pages:
Jump to: