search

keybase / node-client

CLI for keybase.io written in/for Node.js
BSD 3-Clause "New" or "Revised" License
300 stars 32 forks source link

Segfault when id'ing user #201

Closed maleadt closed 9 years ago

maleadt commented 9 years ago

When trying to id myself, I'm getting a segfault using the latest keybase client:

I'm thinking it has something to do with the strange temporary situation I'm currently in concerning my second DNS proof (I already have a file hosted, but also wanted to add a TXT record for _keybase.maleadt.net): the Keybase site hasn't picked-up the TXT record up yet, but it is definitely there and the client should be able to verify it:

$ host -t txt _keybase.maleadt.net
_keybase.maleadt.net descriptive text blabla

However, the keybase homepage hasn't picked this up yet.

NINJA EDIT: I just had a look at what the API (more specifically, lookup.json?usernames=maleadt returns, and it doesn't contain a reference to my secondary DNS proof at _keybase.maleadt.net, so my speculation above likely isn't correct.

Anyhow, here is the crash:

$ keybase id maleadt
✔ public key fingerprint: 7550 6A80 7642 01B4 C9A3 AEEA 1CA4 3519 FA77 B3B5
✔ "maleadt" on twitter: https://twitter.com/maleadt/status/618039524191535104
✔ "maleadt" on github: https://gist.github.com/cd189439470529b2ec48
✔ "maleadt" on reddit: https://www.reddit.com/r/KeybaseProofs/comments/38dehf/my_keybase_proof_redditmaleadt_keybasemaleadt/
✔ "maleadt" on hackernews: https://news.ycombinator.com/user?id=maleadt
✔ admin of blog.maleadt.net via HTTP: http://blog.maleadt.net/keybase.txt
Segmentation fault (core dumped)

The segfault seems to happen just before it would verify the DNS proof.

A GDB backtrace (relatively useless because of the lack of debugging symbols):

Program received signal SIGSEGV, Segmentation fault.
0x0000000000827edc in v8::internal::JSObject::SetFastElement(v8::internal::Handle<v8::internal::JSObject>, unsigned int, v8::internal::Handle<v8::internal::Object>, v8::internal::StrictMode, bool) ()
(gdb) bt
#0  0x0000000000827edc in v8::internal::JSObject::SetFastElement(v8::internal::Handle<v8::internal::JSObject>, unsigned int, v8::internal::Handle<v8::internal::Object>, v8::internal::StrictMode, bool) ()
#1  0x000000000082af75 in v8::internal::JSObject::SetElementWithoutInterceptor(v8::internal::Handle<v8::internal::JSObject>, unsigned int, v8::internal::Handle<v8::internal::Object>, PropertyAttributes, v8::internal::StrictMode, bool, v8::internal::SetPropertyMode) ()
#2  0x000000000082a09e in v8::internal::JSObject::SetElement(v8::internal::Handle<v8::internal::JSObject>, unsigned int, v8::internal::Handle<v8::internal::Object>, PropertyAttributes, v8::internal::StrictMode, bool, v8::internal::SetPropertyMode) ()
#3  0x00000000005df963 in v8::Object::Set(unsigned int, v8::Handle<v8::Value>) ()
#4  0x0000000000968d3c in node::cares_wrap::QueryTxtWrap::Parse(unsigned char*, int) ()
#5  0x00000000009670bc in node::cares_wrap::QueryWrap::Callback(void*, int, int, unsigned char*, int) ()
#6  0x00000000009d42eb in ?? ()
#7  0x00000000009d2b69 in ?? ()
#8  0x00000000009d397c in ?? ()
#9  0x00000000009d3cae in ?? ()
#10 0x00000000009d3e48 in ?? ()
#11 0x00000000009e66ad in uv.io_poll ()
#12 0x00000000009d95a4 in uv_run ()
#13 0x0000000000976439 in node::Start(int, char**) ()
#14 0x00007ffff5a93790 in __libc_start_main () from /usr/lib/libc.so.6
#15 0x00000000005ce669 in _start ()

It also happens when a friend of mine tried to track me (on an identical arch system).

maleadt commented 9 years ago

I just noticed the debug flag, and this is the end of it (I listed both DNS proofs):

debug: ++++++ maleadt: checking remote generic_web_site proof
debug: |||||| remote service desc is {"hostname":"blog.maleadt.net","protocol":"http:"}
debug: +++++++ Calling into scraper -> {"hostname":"blog.maleadt.net","protocol":"http:"}@generic_web_site -> http://blog.maleadt.net/keybase.txt
debug: ------- Called scraper -> 1
debug: |||||| proof checked out
✔ admin of blog.maleadt.net via HTTP: http://blog.maleadt.net/keybase.txt
debug: ------ maleadt: checked remote generic_web_site proof

debug: ++++++ maleadt: checking remote dns proof
debug: |||||| remote service desc is {"domain":"maleadt.net","protocol":"dns"}
debug: +++++++ Calling into scraper -> {"domain":"maleadt.net","protocol":"dns"}@dns -> dns://maleadt.net
debug: ++++++++ DNS check for maleadt.net

Segmentation fault (core dumped)
maxtaco commented 9 years ago

Seems like node still had a bug in their DNS resolver. I filed a bug report a while back.

On Monday, July 6, 2015, Tim Besard notifications@github.com wrote:

When trying to id myself, I'm getting a segfault using the latest keybase client:

  • keybase 0.8.3-1
  • nodejs 0.12.5-1
  • distro: Arch Linux

I'm thinking it has something to do with the strange temporary situation I'm currently in concerning my second DNS proof (I already have a file hosted, but also wanted to add a TXT record for _keybase.maleadt.net): the Keybase site hasn't picked-up the TXT record up yet, but it is definitely there and the client should be able to verify it:

$ host -t txt _keybase.maleadt.net _keybase.maleadt.net descriptive text blabla

However, the keybase homepage hasn't picked this up yet.

NINJA EDIT: I just had a look at what the API (more specifically, lookup.json?usernames=maleadt returns, and it doesn't contain a reference to my secondary DNS proof at _keybase.maleadt.net, so my speculation above likely isn't correct.

Anyhow, here is the crash:

$ keybase id maleadt ✔ public key fingerprint: 7550 6A80 7642 01B4 C9A3 AEEA 1CA4 3519 FA77 B3B5 ✔ "maleadt" on twitter: https://twitter.com/maleadt/status/618039524191535104 ✔ "maleadt" on github: https://gist.github.com/cd189439470529b2ec48 ✔ "maleadt" on reddit: https://www.reddit.com/r/KeybaseProofs/comments/38dehf/my_keybase_proof_redditmaleadt_keybasemaleadt/ ✔ "maleadt" on hackernews: https://news.ycombinator.com/user?id=maleadt ✔ admin of blog.maleadt.net via HTTP: http://blog.maleadt.net/keybase.txt Segmentation fault (core dumped)

The segfault seems to happen just before it would verify the DNS proof.

A GDB backtrace (relatively useless because of the lack of debugging symbols):

Program received signal SIGSEGV, Segmentation fault. 0x0000000000827edc in v8::internal::JSObject::SetFastElement(v8::internal::Handlev8::internal::JSObject, unsigned int, v8::internal::Handlev8::internal::Object, v8::internal::StrictMode, bool) () (gdb) bt

0 0x0000000000827edc in v8::internal::JSObject::SetFastElement(v8::internal::Handlev8::internal::JSObject, unsigned int, v8::internal::Handlev8::internal::Object, v8::internal::StrictMode, bool) ()

1 0x000000000082af75 in v8::internal::JSObject::SetElementWithoutInterceptor(v8::internal::Handlev8::internal::JSObject, unsigned int, v8::internal::Handlev8::internal::Object, PropertyAttributes, v8::internal::StrictMode, bool, v8::internal::SetPropertyMode) ()

2 0x000000000082a09e in v8::internal::JSObject::SetElement(v8::internal::Handlev8::internal::JSObject, unsigned int, v8::internal::Handlev8::internal::Object, PropertyAttributes, v8::internal::StrictMode, bool, v8::internal::SetPropertyMode) ()

3 0x00000000005df963 in v8::Object::Set(unsigned int, v8::Handlev8::Value) ()

4 0x0000000000968d3c in node::careswrap::QueryTxtWrap::Parse(unsigned char, int) ()

5 0x00000000009670bc in node::careswrap::QueryWrap::Callback(void, int, int, unsigned char_, int) ()

6 0x00000000009d42eb in ?? ()

7 0x00000000009d2b69 in ?? ()

8 0x00000000009d397c in ?? ()

9 0x00000000009d3cae in ?? ()

10 0x00000000009d3e48 in ?? ()

11 0x00000000009e66ad in uv.io_poll ()

12 0x00000000009d95a4 in uv_run ()

13 0x0000000000976439 in node::Start(int, char_*) ()

14 0x00007ffff5a93790 in __libc_start_main () from /usr/lib/libc.so.6

15 0x00000000005ce669 in _start ()

It also happens when a friend of mine tried to track me (on an identical arch system).

— Reply to this email directly or view it on GitHub https://github.com/keybase/node-client/issues/201.

maleadt commented 9 years ago

Seems like I missed that, and this bug is duplicate to https://github.com/keybase/keybase-issues/issues/1413 and https://github.com/keybase/keybase-issues/issues/1607. I'll close this issue, while waiting for https://github.com/joyent/node/pull/9300 to land.