Segfault when id'ing user

[maleadt]

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::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]

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]

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 [email protected] 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::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).

—
Reply to this email directly or view it on GitHub
#201.

[maleadt]

Seems like I missed that, and this bug is duplicate to keybase/keybase-issues#1413 and keybase/keybase-issues#1607. I'll close this issue, while waiting for nodejs/node-v0.x-archive#9300 to land.