Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Hmm OK I'll try that out, thanks.Setting desired connection count to 100 is not a good idea. It just puts more strain on your client to service all those connections. I'd personally recommend sticking to 20 or even less (for example, 8 is just fine).
any news on this? got the same problem...Are you using 4.12? If not, try that.
This segfault occurs when quitting the GUI (after it has been open for a while).Please let me know if you can repeat this error in further runs. Also, before you shut down, can you check how many connections and how much memory you are using? Are you just operating with default settings, or have you increased node count or anything like that?Code: [Select][Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./BitSharesX'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000aadcfa in boost::asio::detail::task_io_service::post_immediate_completion (this=0x18, op=op@entry=0x7ff070596450,
is_continuation=is_continuation@entry=false) at /usr/include/boost/asio/detail/impl/task_io_service.ipp:264
264 if (one_thread_ || is_continuation)
(gdb) bt
#0 0x0000000000aadcfa in boost::asio::detail::task_io_service::post_immediate_completion (this=0x18, op=op@entry=0x7ff070596450,
is_continuation=is_continuation@entry=false) at /usr/include/boost/asio/detail/impl/task_io_service.ipp:264
#1 0x0000000000aadf00 in boost::asio::detail::epoll_reactor::start_op (this=0x7ff070027380, op_type=op_type@entry=1, descriptor=155,
descriptor_data=@0x7ff07048ff00: 0x7ff04c001250, op=0x7ff070596450, is_continuation=<optimized out>, allow_speculative=true)
at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:253
#2 0x0000000000aaf268 in boost::asio::detail::reactive_socket_service_base::start_op (this=0x7ff07045d168, impl=..., op_type=1, op=<optimized out>,
is_continuation=<optimized out>, is_non_blocking=<optimized out>, noop=false) at /usr/include/boost/asio/detail/impl/reactive_socket_service_base.ipp:214
#3 0x0000000000ab2256 in async_send<boost::asio::const_buffers_1, boost::_bi::bind_t<void, void (*)(fc::shared_ptr<fc::promise<unsigned long> > const&, boost::system::error_code const&, unsigned long), boost::_bi::list3<boost::_bi::value<fc::shared_ptr<fc::promise<unsigned long> > >, boost::arg<1>, boost::arg<2> > > > (handler=...,
flags=0, buffers=..., impl=..., this=0x7ff07045d168) at /usr/include/boost/asio/detail/reactive_socket_service_base.hpp:216
#4 async_send<boost::asio::const_buffers_1, boost::_bi::bind_t<void, void (*)(fc::shared_ptr<fc::promise<unsigned long> > const&, boost::system::error_code const&, unsigned long), boost::_bi::list3<boost::_bi::value<fc::shared_ptr<fc::promise<unsigned long> > >, boost::arg<1>, boost::arg<2> > > > (
handler=<unknown type in /redacted/bitsharesx/programs/qt_wallet/bin/BitSharesX, CU 0x30d2e56, DIE 0x31418e3>, flags=0, buffers=..., impl=...,
this=0x7ff07045d140) at /usr/include/boost/asio/stream_socket_service.hpp:330
#5 async_write_some<boost::asio::const_buffers_1, boost::_bi::bind_t<void, void (*)(fc::shared_ptr<fc::promise<unsigned long> > const&, boost::system::error_code const&, unsigned long), boost::_bi::list3<boost::_bi::value<fc::shared_ptr<fc::promise<unsigned long> > >, boost::arg<1>, boost::arg<2> > > > (
handler=<unknown type in /redacted/bitsharesx/programs/qt_wallet/bin/BitSharesX, CU 0x30d2e56, DIE 0x3115ea8>, buffers=..., this=0x7ff07048fef8)
at /usr/include/boost/asio/basic_stream_socket.hpp:732
#6 fc::asio::write_some<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::const_buffers_1>
(s=..., buf=...) at /redacted/bitsharesx/libraries/fc/include/fc/asio.hpp:122
#7 0x0000000000db0399 in fc::detail::rate_limiting_group_impl::writesome (this=0x7ff070433770, socket=...,
buffer=0x7ff049e6d7a0 "\337\362n\342\360\274\v\005\065\366LJ", length=16) at /redacted/bitsharesx/libraries/fc/src/network/rate_limiting.cpp:249
#8 0x0000000000a5ccc7 in fc::ostream::write (this=this@entry=0x7ff07048fed8, buf=buf@entry=0x7ff049e6d7a0 "\337\362n\342\360\274\v\005\065\366LJ", len=16)
at /redacted/bitsharesx/libraries/fc/src/io/iostream.cpp:365
#9 0x0000000000be22ae in bts::net::stcp_socket::writesome (this=0x7ff07048fe80, buffer=0x7ff070001fb0 "\b", len=<optimized out>)
at /redacted/bitsharesx/libraries/net/stcp_socket.cpp:93
#10 0x0000000000a5ccc7 in fc::ostream::write (this=this@entry=0x7ff07048fe80, buf=buf@entry=0x7ff070001fb0 "\b", len=len@entry=16)
at /redacted/bitsharesx/libraries/fc/src/io/iostream.cpp:365
#11 0x0000000000bc30d0 in bts::net::detail::message_oriented_connection_impl::send_message (this=0x7ff07048fe70, message_to_send=...)
at /redacted/bitsharesx/libraries/net/message_oriented_connection.cpp:251
#12 0x0000000000bc3bb8 in bts::net::message_oriented_connection::send_message (this=this@entry=0x7ff070465af8, message_to_send=...)
at /redacted/bitsharesx/libraries/net/message_oriented_connection.cpp:328
#13 0x0000000000bbda96 in bts::net::peer_connection::send_queued_messages_task (this=0x7ff070465a90)
at /redacted/bitsharesx/libraries/net/peer_connection.cpp:236
#14 0x0000000000bbf5dc in operator() (__closure=<optimized out>) at /redacted/bitsharesx/libraries/net/peer_connection.cpp:301
#15 fc::detail::void_functor_run<bts::net::peer_connection::send_message(const bts::net::message&)::<lambda()> >::run(void *, void *) (functor=<optimized out>,
prom=0x7ff070466660) at /redacted/bitsharesx/libraries/fc/include/fc/thread/task.hpp:83
#16 0x0000000000a4e115 in fc::task_base::run_impl (this=0x7ff070466670) at /redacted/bitsharesx/libraries/fc/src/thread/task.cpp:43
#17 0x0000000000a4cbb3 in run_next_task (this=<optimized out>) at /redacted/bitsharesx/libraries/fc/src/thread/thread_d.hpp:398
#18 fc::thread_d::process_tasks (this=0x7ff0700008c0) at /redacted/bitsharesx/libraries/fc/src/thread/thread_d.hpp:422
#19 0x0000000000a4ce21 in fc::thread_d::start_process_tasks (my=140670647929024) at /redacted/bitsharesx/libraries/fc/src/thread/thread_d.hpp:378
#20 0x0000000000deedee in make_fcontext ()
#21 0x00007ff0700008c0 in ?? ()
#22 0x0000000000000000 in ?? ()
PM with link sent.200 max connections could be quite high. Can you set both desired and max to 40 and make sure you still crash? Also, might be interesting to see how much memory is being used...
I set it to 40 (i think...)
UPDATE:
Exact commands:
(wallet closed) >>> network_get_advanced_node_parameters
{
"peer_connection_retry_timeout": 30,
"desired_number_of_connections": 8,
"maximum_number_of_connections": 200
}
(wallet closed) >>> network_set_advanced_node_parameters { "desired_number_of_connections": 40 }
OK
UPDATE2: No other commands were executed except "info"
The crash with 2b3e00c5a2cbd29f628a8cc3e0a9889a05547775 looks easy to reproduce - 2 out of 4 attempts crashed.What are you setting your desired connections to?
I only need to increase desired_connections.
You can email it to sales at syncad.com. There should be no private data in the logs. We're mostly interested in the p2p log.It's running in gdb now. Do I just wait for a crash?The backtrace will be useful, but probably the most useful thing will be the logs around the time of the crash.
I have my logs directory tar.gz'd. Is there an email I can send them to? Also, is there anything in there I shouldn't be sending? I'm assuming by this point the logs are scrubbed of private data but want to be sure.
It's running in gdb now. Do I just wait for a crash?The backtrace will be useful, but probably the most useful thing will be the logs around the time of the crash.
If you just want to claim your BTSX, check out details in this thread:I registered keyhotee founder "King" and "Value", took part in the 0.5.3 version of the test, but did not participate in the 0.7.x version of the test, in BTSX the genesis block, there is no written my founder, how should I do ?All the unregistered Keyhotee Founder Ids were registered with a placeholder key. Once things cool down a bit, there'll be some instructions about how unregistered founders will be able to claim their IDs. But right now all developers are working 7 days a week on functionality and stability of bitsharesX itself.
Okay, but now I want to get the founder of btsx, how should I do it?
No, I checked the code and it's not used in the key generation itself, so you don't need to remember it for regeneration of your key.
quesiont: is login password part of "profile data" ?
I registered keyhotee founder "King" and "Value", took part in the 0.5.3 version of the test, but did not participate in the 0.7.x version of the test, in BTSX the genesis block, there is no written my founder, how should I do ?All the unregistered Keyhotee Founder Ids were registered with a placeholder key. Once things cool down a bit, there'll be some instructions about how unregistered founders will be able to claim their IDs. But right now all developers are working 7 days a week on functionality and stability of bitsharesX itself.
Dan, what is the status on the updated working version of Keyhote 7.0 for OSX? I am still waiting on a working version to be able to re-register my founder ID.My group finally does have a Mac system to test with, but unfortunately we don't have one that has the problem that some Mac systems have (seems to be some older Macs). I know of one person loosely associated with Hypertas that has a system with the problem, but collecting data from them isn't easy and we don't have anyone to analyze it at the moment anyways. Once BitSharesX development cools down a little, we can assign someone to finally put this issue to bed. For now, I recommend just using a friend's machine to register your founder ID (just make sure you record ALL your profile information, probably take a screenshot even).
Thanks
What is the general status of keyhotee atm? Can you also update us to any revised visions of the product? And offer a timeline for production?Over the past few months, it's mostly just been bug fixes and minor feature improvements in Keyhotee because of the focus on bitsharesX. The last major change of recent times that I'm aware of was code for integrating Keyhotee with the Bitshares wallet (and code to allow integration with other web wallets as well). That code is about 90% done, probably just needs some minor cleanup once we can assign someone to it (recently all the remaining programmers were pulled off to help with the release of BitsharesX and followup releases).
Sent from my iPhone using Tapatalk
If you're getting a different public key, you haven't successfully regenerated your account. To get the correct public key regenerated, you need the exact profile data previously entered (and the exact same KeyhoteeId).Help!1) It sounds like you successfully regenerated your key. If the public key you got matches your old one, then you have regenerated your key sucessfully.
I'm a Keyhotee founder ID user and I'm sure that I registered it suscessfully with 0.7 version. Actually, my founder ID is "Mike HAO" which is listed in btsx genesis block acount list as "mikeh-hao".
My problem is, when I try to log in on my computer today for getting the private key to claim the ID in BTSX, I found I forget my Keyhotee login password, actually I think I remember it but anyway I tried hundreds times but failed.
So per my understanding of the mechanism of Keyhotee ID, I created a new acount w/ exactly same register profile info and brain key so that I believe I could re-generate my acount to get the into it and get the private key for BTSX. I think I succeed to get my acount re-generated since when I create a "new identity" w/ "Mike HAO", system remind me that I've created a similar ID before.. I notice that, both of mail network and btsx network status in right bottom concern of the client is both "disconnected". So maybe that's why my "Mike HAO" ID not shows in the client now...?
So in summary, my question is:
1. As I described above, did I re-generated my acount sucessfully? If not, how can I do?
2. If yes to first quesion, no ID in the re-generated account now is due to no network? If no, then why no ID in the list?
3. If yes to second question, when could we have the newwork available then I could access to my "Mike HAO" ID and get the private key for BTSX...
BTW, at that time, I posted my public key "5cU7QvmB7ZLxcVjm1bwmvSmgZxduqZGFBgMDh8TPhkdYMnjSgS" here and you confirmed it recorded, which is true because it's in BTSX genesis block now. And I'm using the last release windows verions(0.7.230-win32) now.
Appreciated if you could look it and provide me your advice..
Thanks a lot.
2) it's quite possible the mail server for KH is down right now, I've not been involved with mail server handling for a few months now. I logged on to the server just now, and it "appears" to not be running for some reason, don't know why.
3) You don't need the mail server to access your private key. Your private key is stored in your Keyhotee client itself along with your public key. You just need to export this key to your bitshares client. I haven't done this yet myself, but the procedure for it is here:
http://wiki.bitshares.org/index.php/BitShares_X_Solutions#How_to_import_Keyhotee_IDs
Thanks for quick response.
1. The new public key does not match the old one. But the client remind me that I've registered this ID(Mike HAO), and does not allow me to "save" it. The new public key is "76UX9KAnd4Au6d6EDqRSKQQjsLBDqvk8j6UpjaswatEreSVkMb", while the old one is "5cU7QvmB7ZLxcVjm1bwmvSmgZxduqZGFBgMDh8TPhkdYMnjSgS". I still think I've succeeded to re-generate mu account, otherwise how system could identify I(my acount) already had ID "Mike HAO" when the client not being sync to the newwork.
2. I know the process to claim my ID on BTSX, but I could not access to ID "Mike HAO" now, since there is no ID in my new re-generated account and I could not re-create "Mike HAO" in this account due to system identify it's as duplicated... and no private key could be exported...
Any further advice...? Thanks.
