Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

Segfault in Readline #1881

Closed
axkibe opened this issue Oct 13, 2011 · 6 comments
Closed

Segfault in Readline #1881

axkibe opened this issue Oct 13, 2011 · 6 comments
Labels

Comments

@axkibe
Copy link

axkibe commented Oct 13, 2011

With node 0.5.9 I get this segfaults, happens 1 out of 5 times shortly after startup. Works flawlessy with 0.5.6. Can provide more info if you want to.

axel@faith:~/Dropbox/Meshcraft$ gdb ~/node-v0.5.9/node core
GNU gdb (GDB) 7.3-debian
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/axel/node-v0.5.9/node...done.
[New LWP 17572]
[New LWP 17573]
[New LWP 17574]

warning: Can't read pathname for load map: Eingabe-/Ausgabefehler.
[Thread debugging using libthread_db enabled]
Core was generated by `/home/axel/node-v0.5.9/node meshmashine.js'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000595c51 in v8::Object::GetIndexedPropertiesExternalArrayDataLength() ()
(gdb) backtrace
#0  0x0000000000595c51 in v8::Object::GetIndexedPropertiesExternalArrayDataLength() ()
#1  0x0000000000552e45 in Length (obj=<optimized out>) at ../src/node_buffer.h:80
#2  Length (b=0x17f3950) at ../src/node_buffer.h:84
#3  NewSlab (wrap_obj=..., global=<optimized out>) at ../src/stream_wrap.cc:133
#4  node::StreamWrap::OnAlloc (handle=<optimized out>, suggested_size=65536) at ../src/stream_wrap.cc:163
#5  0x00000000007d1dc5 in uv__read (stream=0x17f2cc0) at src/unix/stream.c:494
#6  0x00000000007d259b in uv__stream_io (loop=0xc2ffe0, watcher=0x17f2d38, revents=1) at src/unix/stream.c:661
#7  0x00000000007d83d6 in ev_invoke_pending (loop=0xc2ffe0) at src/unix/ev/ev.c:2143
#8  0x00000000007d9181 in ev_run (loop=0xc2ffe0, flags=0) at src/unix/ev/ev.c:2519
#9  0x00000000007c9763 in uv_run (loop=0xc2fcc0) at src/unix/core.c:188
#10 0x000000000053c4b7 in node::Start (argc=<optimized out>, argv=0x7fffed6bf048) at ../src/node.cc:2578
#11 0x00007f9b89c84ead in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#12 0x0000000000537875 in _start ()
@bnoordhuis
Copy link
Member

Can you try it with a debug build of the current master?

./configure --debug && make, then run your script with ./node_g script.js

@axkibe
Copy link
Author

axkibe commented Oct 14, 2011

Doesn't happen with neither the debug build of 0.5.9 or current git-head.
Either its fixed or the race condition doesn't show up.

@bnoordhuis
Copy link
Member

Thanks. Not sure what's causing it. Do you have a test case I can try?

@axkibe
Copy link
Author

axkibe commented Oct 14, 2011

Sure! I uploaded it here: http://meshcraft.net/issue1881.tar.gz

it contains two files "meshmashine.js" and "cmdhistory.txt". The current state of cmdhistory is essential for the crash to appear. It only crashes with non-debug of 0.5.9 for me. And only sometimes on first keystroke after starting up (1 in 5-10 times)

@bnoordhuis
Copy link
Member

Hmm, doesn't seem to crash for me (x86_64 linux).

Just so we're on the same page: you observe this crash with the release build of 0.5.9 but not with the debug build? What about release/debug builds of master? We upgraded V8 yesterday so that probably makes a difference.

@axkibe
Copy link
Author

axkibe commented Oct 14, 2011

Works on GIT, got x86_64 too, its some race condition since it happens only sometimes. Lets just close it and if it happens again, I'm back :-)

@axkibe axkibe closed this as completed Oct 14, 2011
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants