Ok, thank you both! The last part of the bounty will be payed as soon as i have the confirmation from hexafraction.
It is sometime hard for me to get projects like this on the road. I had a little c++ in the university but the stuff needed to create a new coin, the phyton to fit p2pool for FRC/WLC and the Java/android stuff for the wallet now i had to teach me myself (good thing to have you on board for this, i tried it before and failed epicaly ;-).
So to answer hexafraction "I'm really excited to see where this coin (..WLC..) might go." It will go as far as i can. The vision is to supply communities all over the world with coins. This was already tried by many but the demurrage WLC got from Freicoin guaranties a stable monthly payout.
What WLC really needs at the moment are common good initiatives all over the globe.. So if any of you know some feel free to invite them to the WLC homepage (www.winc-ev.org).
@hexafraction thanks for the offer i will send you a message if i need help again.
Topic: [BOUNTY] fix mobile WLCj wallet for android (Read 7371 times)
So guys, now it works with additional largeHeap="true" the memory increases to 190 mb and the wallet loads fine.
I dont know why largeHeap did not work with the earlier version but hey.... you 2 rock!!
Now i just have to adjust some pics and stuff but thats it..
@hexafraction: jk14 send me a private message about a wallet for a bounty i said he maybe could ask you about. Just in case..
Now that you fixed that, is that all that needed to be done? Or are there other problems that need to be fixed before you can pay the bounty?I dont know why largeHeap did not work with the earlier version but hey.... you 2 rock!!
Now i just have to adjust some pics and stuff but thats it..
@hexafraction: jk14 send me a private message about a wallet for a bounty i said he maybe could ask you about. Just in case..
Nope just send me your addresses, as for my personal opinion hexafraction should get a bigger portion of the bounty but please let me know your opinion how to split the bounty.
@hexafraction, ok maybe i can help him i am much better at c++ than i am at java and now i have a little bit more time.
So guys, now it works with additional largeHeap="true" the memory increases to 190 mb and the wallet loads fine.
I dont know why largeHeap did not work with the earlier version but hey.... you 2 rock!!
Now i just have to adjust some pics and stuff but thats it..
@hexafraction: jk14 send me a private message about a wallet for a bounty i said he maybe could ask you about. Just in case..
Now that you fixed that, is that all that needed to be done? Or are there other problems that need to be fixed before you can pay the bounty? I dont know why largeHeap did not work with the earlier version but hey.... you 2 rock!!
Now i just have to adjust some pics and stuff but thats it..
@hexafraction: jk14 send me a private message about a wallet for a bounty i said he maybe could ask you about. Just in case..
So guys, now it works with additional largeHeap="true" the memory increases to 190 mb and the wallet loads fine.
I dont know why largeHeap did not work with the earlier version but hey.... you 2 rock!!
Now i just have to adjust some pics and stuff but thats it..
@hexafraction: jk14 send me a private message about a wallet for a bounty i said he maybe could ask you about. Just in case..
I dont know why largeHeap did not work with the earlier version but hey.... you 2 rock!!
Now i just have to adjust some pics and stuff but thats it..
@hexafraction: jk14 send me a private message about a wallet for a bounty i said he maybe could ask you about. Just in case..
Thanks; please let us know if anything is needed. I did get in touch with jk14; the job ended up changing to the point where it involved the C++ side of things, so I had to decline as I do not know enough C++ to make changes and make the resulting code remain secure and reliable.
So guys, now it works with additional largeHeap="true" the memory increases to 190 mb and the wallet loads fine.
I dont know why largeHeap did not work with the earlier version but hey.... you 2 rock!!
Now i just have to adjust some pics and stuff but thats it..
@hexafraction: jk14 send me a private message about a wallet for a bounty i said he maybe could ask you about. Just in case..
I dont know why largeHeap did not work with the earlier version but hey.... you 2 rock!!
Now i just have to adjust some pics and stuff but thats it..
@hexafraction: jk14 send me a private message about a wallet for a bounty i said he maybe could ask you about. Just in case..
Sorry about the delay. I took a look at the heap dumps you sent, and I don't see anything abnormal, or an abnormally large heap. It's all around 40-50MB as with my dumps. However, a difference I cannot test directly is dalvik vs ART. Your heap dump reports the environment as Dalvik (if I'm interpreting mixed messages correctly), while my devices uses ART instead.
Not a deal. Yes the heap is just at 40-50 mb and when the block download reaches 12k it loads 2k blocks in the cache and that is too much, because somehow on older phones the heap memory seems to be restricted to 64 mb (sorry i dont know about whic test app is running at my anfdroid studio).
So there are 2 ways: 1. increase heap
2. reduce blocks in cache.
The second one seems to be more convienient scince older devices maybe get to slow if one app use all ram (although it is just for the download).
@ kinght
This goes straight in the right direction but memory usage is still high and it crashes at 12k (going down to 500 with DEFAULT_NUM_HEADERS and to 260 with the blockCache).
3rd Edit: Every new transaction has a size of 80 byte. The problem is that the wallet loads 2k blocks at once. After the block 10k the merge mining starts and the Parent header has 250+ Coinbase transactions per block. Keeping them all inside the heap memory seems to be hard for small devices but after block 12k every block is MM, so the memoryload is even bigger and the app crashes. so reducing the blocks to be loaded at once should solve the problem i guess.
...hmm when i reduce the MAX_HEADERS in HeaderMassage to 500 it completely refuses to download blocks (Error deserializing message)... weird..
Maybe because your device is of a newer generation, so newer phones can handle the memoryerror?
The main memory consumer is org.bitcoinj.core.Block with:
- org.bitcoinj.core.TransactionOutput with 167.034 objects and 13.362.720 heap swallow and
- byte[] with 176.775 objects and 7.195.488 heap swallow
EDIT: Inbound connection was to HeaderMessage if i am reading it correctly.
2nd Edit: The BlockMergeMinedPayload loads Transaction and this loads a TransactionOutput and this creates byte[] which has 80 byte of space, so it looks like every transaction in the Parent chain gets 80 bytes assigned.. And this leads to a high memoryload after it reaches block 10k and loading 2k more blocks (including mmBlocks)..
So the question seems to be why does the wallet sees parentcoinbase transaction as headersJ?
3rd Edit: Every new transaction has a size of 80 byte. The problem is that the wallet loads 2k blocks at once. After the block 10k the merge mining starts and the Parent header has 250+ Coinbase transactions per block. Keeping them all inside the heap memory seems to be hard for small devices but after block 12k every block is MM, so the memoryload is even bigger and the app crashes. so reducing the blocks to be loaded at once should solve the problem i guess.
...hmm when i reduce the MAX_HEADERS in HeaderMassage to 500 it completely refuses to download blocks (Error deserializing message)... weird..
The main memory consumer is org.bitcoinj.core.Block with:
- org.bitcoinj.core.TransactionOutput with 167.034 objects and 13.362.720 heap swallow and
- byte[] with 176.775 objects and 7.195.488 heap swallow
EDIT: Inbound connection was to HeaderMessage if i am reading it correctly.
2nd Edit: The BlockMergeMinedPayload loads Transaction and this loads a TransactionOutput and this creates byte[] which has 80 byte of space, so it looks like every transaction in the Parent chain gets 80 bytes assigned.. And this leads to a high memoryload after it reaches block 10k and loading 2k more blocks (including mmBlocks)..
So the question seems to be why does the wallet sees parentcoinbase transaction as headersJ?
3rd Edit: Every new transaction has a size of 80 byte. The problem is that the wallet loads 2k blocks at once. After the block 10k the merge mining starts and the Parent header has 250+ Coinbase transactions per block. Keeping them all inside the heap memory seems to be hard for small devices but after block 12k every block is MM, so the memoryload is even bigger and the app crashes. so reducing the blocks to be loaded at once should solve the problem i guess.
...hmm when i reduce the MAX_HEADERS in HeaderMassage to 500 it completely refuses to download blocks (Error deserializing message)... weird..
Sorry about the delay. I took a look at the heap dumps you sent, and I don't see anything abnormal, or an abnormally large heap. It's all around 40-50MB as with my dumps. However, a difference I cannot test directly is dalvik vs ART. Your heap dump reports the environment as Dalvik (if I'm interpreting mixed messages correctly), while my devices uses ART instead.
Maybe because your device is of a newer generation, so newer phones can handle the memoryerror?
The main memory consumer is org.bitcoinj.core.Block with:
- org.bitcoinj.core.TransactionOutput with 167.034 objects and 13.362.720 heap swallow and
- byte[] with 176.775 objects and 7.195.488 heap swallow
EDIT: Inbound connection was to HeaderMessage if i am reading it correctly.
2nd Edit: The BlockMergeMinedPayload loads Transaction and this loads a TransactionOutput and this creates byte[] which has 80 byte of space, so it looks like every transaction in the Parent chain gets 80 bytes assigned.. And this leads to a high memoryload after it reaches block 10k and loading 2k more blocks (including mmBlocks)..
So the question seems to be why does the wallet sees parentcoinbase transaction as headersJ?
3rd Edit: Every new transaction has a size of 80 byte. The problem is that the wallet loads 2k blocks at once. After the block 10k the merge mining starts and the Parent header has 250+ Coinbase transactions per block. Keeping them all inside the heap memory seems to be hard for small devices but after block 12k every block is MM, so the memoryload is even bigger and the app crashes. so reducing the blocks to be loaded at once should solve the problem i guess.
...hmm when i reduce the MAX_HEADERS in HeaderMassage to 500 it completely refuses to download blocks (Error deserializing message)... weird..
The main memory consumer is org.bitcoinj.core.Block with:
- org.bitcoinj.core.TransactionOutput with 167.034 objects and 13.362.720 heap swallow and
- byte[] with 176.775 objects and 7.195.488 heap swallow
EDIT: Inbound connection was to HeaderMessage if i am reading it correctly.
2nd Edit: The BlockMergeMinedPayload loads Transaction and this loads a TransactionOutput and this creates byte[] which has 80 byte of space, so it looks like every transaction in the Parent chain gets 80 bytes assigned.. And this leads to a high memoryload after it reaches block 10k and loading 2k more blocks (including mmBlocks)..
So the question seems to be why does the wallet sees parentcoinbase transaction as headersJ?
3rd Edit: Every new transaction has a size of 80 byte. The problem is that the wallet loads 2k blocks at once. After the block 10k the merge mining starts and the Parent header has 250+ Coinbase transactions per block. Keeping them all inside the heap memory seems to be hard for small devices but after block 12k every block is MM, so the memoryload is even bigger and the app crashes. so reducing the blocks to be loaded at once should solve the problem i guess.
...hmm when i reduce the MAX_HEADERS in HeaderMassage to 500 it completely refuses to download blocks (Error deserializing message)... weird..
Ok i have 3 heap dumps now:
- After the block 10k is reached the memory usage goes up from 16 Mb to 50 Mb. I took the first here.
- At some point the wallet loads again and the memory is at 50 Mb still. I took the second here (Block ~11400)
- When the block 12k is reached i took the 3 heap here.
After that the memoryusage reduces to 30 Mb and crashes then without loading further blocks.
The heaps are uploaded here: https://drive.google.com/file/d/0Bzt8Hb4nQtyhQ0FxU3kzT0hkbTQ/view?usp=sharing
I am trying, but to make an app with android studio out of a maven project. On my laptop the main you created is also crashing and at the first run it has produced an otOfMemoryError: Java heap space So maybe i can capture a heap dump.
It's hard to tell what is going on without a heap dump. Would you mind sending me the apk you have, and trying to run the one that I built? I have a special build process I already use for other android projects used for robotic applications that I used.
Ok i have 3 heap dumps now:
- After the block 10k is reached the memory usage goes up from 16 Mb to 50 Mb. I took the first here.
- At some point the wallet loads again and the memory is at 50 Mb still. I took the second here (Block ~11400)
- When the block 12k is reached i took the 3 heap here.
After that the memoryusage reduces to 30 Mb and crashes then without loading further blocks.
The heaps are uploaded here: https://drive.google.com/file/d/0Bzt8Hb4nQtyhQ0FxU3kzT0hkbTQ/view?usp=sharing
I am trying, but to make an app with android studio out of a maven project. On my laptop the main you created is also crashing and at the first run it has produced an otOfMemoryError: Java heap space So maybe i can capture a heap dump.
It's hard to tell what is going on without a heap dump. Would you mind sending me the apk you have, and trying to run the one that I built? I have a special build process I already use for other android projects used for robotic applications that I used.
I am trying, but to make an app with android studio out of a maven project. On my laptop the main you created is also crashing and at the first run it has produced an otOfMemoryError: Java heap space So maybe i can capture a heap dump.
I do see slow block sync after 10K. I'm also investigating that, although my Android abilities are somewhat more limited than my understanding of Java. Would you be able to capture a heap dump and email it to me/upload it somewhere if it is of a reasonable size? (there should be a button called "capture heap dump" or similar to the left of the logcat window in IDEA/Android Studio.
I'm going to see if I can get a reasonable heap snapshot and a profiler working to see what's up with the block sync.
Edit: I've taken a few heap dumps around blocks 10K, 11400, and 14000. All of them report heap sizes of no more than 60 MB (44MB at block 10K). I'll upload an APK tonight.
Edit: I've taken a few heap dumps around blocks 10K, 11400, and 14000. All of them report heap sizes of no more than 60 MB (44MB at block 10K). I'll upload an APK tonight.
Thanks.. Enlarging the heap size by adding android:largeHeap="true" did not change anything in the behaviour.
I'm going to see if I can get a reasonable heap snapshot and a profiler working to see what's up with the block sync.
Edit: I've taken a few heap dumps around blocks 10K, 11400, and 14000. All of them report heap sizes of no more than 60 MB (44MB at block 10K). I'll upload an APK tonight.
Edit: I've taken a few heap dumps around blocks 10K, 11400, and 14000. All of them report heap sizes of no more than 60 MB (44MB at block 10K). I'll upload an APK tonight.
The Bounty is at 1.2 BTC 400 WLC 10k FRC.
What is left to be done:
The Wallet crashes at 10k blocks (sometimes at 12k or even more) and is loading extreme slow compared to the original namecoinj wallet. The crashes seem to be dependend on the memory of the device. So somehow the wallet is using very much memory leads to a crash on the most devices.
Here are a few of my errormessages (if it helps)
After the memory-fix there is no reason on my side to keep the bounty from payout.
Rik
What is left to be done:
The Wallet crashes at 10k blocks (sometimes at 12k or even more) and is loading extreme slow compared to the original namecoinj wallet. The crashes seem to be dependend on the memory of the device. So somehow the wallet is using very much memory leads to a crash on the most devices.
Here are a few of my errormessages (if it helps)
Code:
=== stack trace ===
%0A%0Ajava.lang.OutOfMemoryError
%0A%09at java.io.ByteArrayOutputStream.(ByteArrayOutputStream.java:63)
%0A%09at org.bitcoinj.core.UnsafeByteArrayOutputStream.(UnsafeByteArrayOutputStream.java:39)
%0A%09at org.bitcoinj.core.Message.unsafeBitcoinSerialize(Message.java:361)
%0A%09at org.bitcoinj.core.Message.bitcoinSerialize(Message.java:323)
%0A%09at org.bitcoinj.core.Transaction.getHash(Transaction.java:259)
%0A%09at org.bitcoinj.core.Transaction.getHashAsString(Transaction.java:276)
%0A%09at org.bitcoinj.core.Transaction.toString(Transaction.java:666)
%0A%09at org.bitcoinj.core.Transaction.toString(Transaction.java:656)
%0A%09at org.bitcoinj.core.BlockMergeMinedPayload.parseMergedMineInfo(BlockMergeMinedPayload.java:95)
%0A%09at org.bitcoinj.core.BlockMergeMinedPayload.parse(BlockMergeMinedPayload.java:41)
%0A%09at org.bitcoinj.core.BlockMergeMinedPayload.(BlockMergeMinedPayload.java:32)
%0A%09at org.bitcoinj.core.BlockMergeMined.(BlockMergeMined.java:53)
%0A%09at org.bitcoinj.core.Block.parseHeader(Block.java:215)
%0A%09at org.bitcoinj.core.Block.parse(Block.java:278)
%0A%09at org.bitcoinj.core.Message.(Message.java:171)
%0A%09at org.bitcoinj.core.Block.(Block.java:136)
%0A%09at org.bitcoinj.core.HeadersMessage.parse(HeadersMessage.java:85)
%0A%09at org.bitcoinj.core.Message.(Message.java:117)
%0A%09at org.bitcoinj.core.Message.(Message.java:149)
%0A%09at org.bitcoinj.core.HeadersMessage.(HeadersMessage.java:42)
%0A%09at org.bitcoinj.core.BitcoinSerializer.makeMessage(BitcoinSerializer.java:228)
%0A%09at org.bitcoinj.core.BitcoinSerializer.deserializePayload(BitcoinSerializer.java:191)
%0A%09at org.bitcoinj.core.PeerSocketHandler.receiveBytes(PeerSocketHandler.java:139)
%0A%09at org.bitcoinj.net.ConnectionHandler.handleKey(ConnectionHandler.java:217)
%0A%09at org.bitcoinj.net.NioClientManager.handleKey(NioClientManager.java:75)
%0A%09at org.bitcoinj.net.NioClientManager.run(NioClientManager.java:111)
%0A%09at com.google.common.util.concurrent.AbstractExecutionThreadService$1$2.run(AbstractExecutionThreadService.java:60)
%0A%09at com.google.common.util.concurrent.Callables$3.run(Callables.java:93)
%0A%09at java.lang.Thread.run(Thread.java:856)%0A%0A%0A%0A
Code:
=== stack trace ===
%0A%0Ajava.lang.OutOfMemoryError
%0A%09at org.bitcoinj.core.BitcoinSerializer.deserializePayload(BitcoinSerializer.java:172)
%0A%09at org.bitcoinj.core.PeerSocketHandler.receiveBytes(PeerSocketHandler.java:139)
%0A%09at org.bitcoinj.net.ConnectionHandler.handleKey(ConnectionHandler.java:217)
%0A%09at org.bitcoinj.net.NioClientManager.handleKey(NioClientManager.java:75)
%0A%09at org.bitcoinj.net.NioClientManager.run(NioClientManager.java:111)
%0A%09at com.google.common.util.concurrent.AbstractExecutionThreadService$1$2.run(AbstractExecutionThreadService.java:60)
%0A%09at com.google.common.util.concurrent.Callables$3.run(Callables.java:93)
%0A%09at java.lang.Thread.run(Thread.java:856)%0A%0A%0A%0A
Code:
=== stack trace ===
java.lang.OutOfMemoryError
at org.bitcoinj.core.Utils.copyOf(Utils.java:457)
at org.bitcoinj.core.UnsafeByteArrayOutputStream.toByteArray(UnsafeByteArrayOutputStream.java:117)
at org.bitcoinj.core.Message.unsafeBitcoinSerialize(Message.java:387)
at org.bitcoinj.core.Message.bitcoinSerialize(Message.java:323)
at org.bitcoinj.core.Transaction.getHash(Transaction.java:259)
at org.bitcoinj.core.Transaction.getHashAsString(Transaction.java:276)
at org.bitcoinj.core.Transaction.toString(Transaction.java:666)
at org.bitcoinj.core.Transaction.toString(Transaction.java:656)
at org.bitcoinj.core.BlockMergeMinedPayload.parseMergedMineInfo(BlockMergeMinedPayload.java:95)
at org.bitcoinj.core.BlockMergeMinedPayload.parse(BlockMergeMinedPayload.java:41)
at org.bitcoinj.core.BlockMergeMinedPayload.(BlockMergeMinedPayload.java:32)
at org.bitcoinj.core.BlockMergeMined.(BlockMergeMined.java:53)
at org.bitcoinj.core.Block.parseHeader(Block.java:215)
at org.bitcoinj.core.Block.parse(Block.java:278)
at org.bitcoinj.core.Message.(Message.java:171)
at org.bitcoinj.core.Block.(Block.java:136)
at org.bitcoinj.core.HeadersMessage.parse(HeadersMessage.java:85)
at org.bitcoinj.core.Message.(Message.java:117)
at org.bitcoinj.core.Message.(Message.java:149)
at org.bitcoinj.core.HeadersMessage.(HeadersMessage.java:42)
at org.bitcoinj.core.BitcoinSerializer.makeMessage(BitcoinSerializer.java:228)
at org.bitcoinj.core.BitcoinSerializer.deserializePayload(BitcoinSerializer.java:191)
at org.bitcoinj.core.PeerSocketHandler.receiveBytes(PeerSocketHandler.java:139)
at org.bitcoinj.net.ConnectionHandler.handleKey(ConnectionHandler.java:217)
at org.bitcoinj.net.NioClientManager.handleKey(NioClientManager.java:75)
at org.bitcoinj.net.NioClientManager.run(NioClientManager.java:111)
at com.google.common.util.concurrent.AbstractExecutionThreadService$1$2.run(AbstractExecutionThreadService.java:60)
at com.google.common.util.concurrent.Callables$3.run(Callables.java:93)
at java.lang.Thread.run(Thread.java:856)
After the memory-fix there is no reason on my side to keep the bounty from payout.
Rik
Hi i am building it with maven. I just downloaded it / git clone it and then i compile it.
A problem could be with support-v4 and v13 artifacts they are somehow not loading from online repository. I installed them manually again from the local repository by using
After that the libs folder in the wallet has to be moved to src/main/libs and then the namecoinj is compiling with and the wallet with
A problem could be with support-v4 and v13 artifacts they are somehow not loading from online repository. I installed them manually again from the local repository by using
Code:
mvn install:install-file -DgroupId=com.android.support -DartifactId=support-v4 -Dfile=support-v4-19.1.0.jar -Dversion=19.1.0 -Dpackaging=jar -DgeneratePom=true -D
After that the libs folder in the wallet has to be moved to src/main/libs and then the namecoinj is compiling with
Code:
mvn clean install -Dmaven.test.skip=true
Code:
mvn clean install -DskipTests=true -Dandroid.sdk.path=/path_to_sdk
I got it building and debugging with IDEA after a few changes:
Remove support-v4. It conflicted with v13 at the dex stage.
Add
Build as Android Application (nothing Maven specific) in IDEA.
Would you mind updating us on what is left to do, and the state of the bounty?
Hi i am building it with maven. I just downloaded it / git clone it and then i compile it.
A problem could be with support-v4 and v13 artifacts they are somehow not loading from online repository. I installed them manually again from the local repository by using
After that the libs folder in the wallet has to be moved to src/main/libs and then the namecoinj is compiling with and the wallet with
A problem could be with support-v4 and v13 artifacts they are somehow not loading from online repository. I installed them manually again from the local repository by using
Code:
mvn install:install-file -DgroupId=com.android.support -DartifactId=support-v4 -Dfile=support-v4-19.1.0.jar -Dversion=19.1.0 -Dpackaging=jar -DgeneratePom=true -D
After that the libs folder in the wallet has to be moved to src/main/libs and then the namecoinj is compiling with
Code:
mvn clean install -Dmaven.test.skip=true
Code:
mvn clean install -DskipTests=true -Dandroid.sdk.path=/path_to_sdk
I'm trying to build it but it doesn't work. I tried using maven and through android studio but neither seems to build it. How did you build the app that is on the website?
I'm also having trouble building on my end. The android project structure is reported as non-standard, which I can override, but there are many package name mismatches and other errors.
Jump to: