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

glibc errors on SheevaPlug / Debian Squeeze #3749

Closed
bwrrp opened this issue Jul 20, 2012 · 7 comments
Closed

glibc errors on SheevaPlug / Debian Squeeze #3749

bwrrp opened this issue Jul 20, 2012 · 7 comments

Comments

@bwrrp
Copy link

bwrrp commented Jul 20, 2012

As previously mentioned in issue #2131, I'm having trouble getting node to work on my SheevaPlug with Debian squeeze. I'm working from the latest v0.8 branch checkout, and compiling node using

./configure --without-snapshot
 make CFLAGS+=-march=armv5t CXXFLAGS+=-march=armv5t

After this, running the tests results in several glibc errors:

*** glibc detected *** out/Release/node: free(): invalid next size (fast): 0x006a4040 ***
*** glibc detected *** out/Release/node: free(): invalid next size (normal): 0x007e3180 ***
*** glibc detected *** out/Release/node: free(): invalid pointer: 0x007ec678 ***

As most of these were in tls/https-related tests I tried passing --shared-openssl to configure. This reduced the number of glibc errors in the tests, but I'm still getting the error in test-os.js. Running this through gdb is unfortunately not very useful, as I seem to be hitting some bug where the stack trace is:

#1  0x403bdca4 in abort () from /lib/libc.so.6
No symbol table info available.
#2  0x403bdca4 in abort () from /lib/libc.so.6
No symbol table info available.
#3  0x403bdca4 in abort () from /lib/libc.so.6
No symbol table info available.

followed by the same abort() all the way down. Any suggestions are very welcome.

@bnoordhuis
Copy link
Member

I have no idea what might be causing that. Does it make a difference when you set ulimit -c unlimited and inspect the core dump instead of a live binary?

@pedrolamas
Copy link

Seeing the same message with v0.8.5 on Arch Linux, running in a Raspberry Pi...

@docfaraday
Copy link

Pulled down the stable 0.8.6 tarball, and got this error. Ran the test under valgrind, and it seems that we're walking off the end of an array of size 0 down inside of uv_cpu_info() because /proc/cpuinfo is not formatted as expected. Fixing the code (just a sanity check in the loop on numcpus, with a decrement) prevents the crash, but the test still fails (I'm guessing because 0 cpus is something the test does not like).

@bnoordhuis
Copy link
Member

@docfaraday Can you post the output of cat /proc/cpuinfo?

@docfaraday
Copy link

FWIW, here's my cpuinfo:

Processor       : ARMv7 Processor rev 2 (v7l)
processor       : 0
BogoMIPS        : 596.46

processor       : 1
BogoMIPS        : 599.22

Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x1
CPU part        : 0xc09
CPU revision    : 2

Hardware        : OMAP4 Panda board
Revision        : 0020
Serial          : 0000000000000000

@bnoordhuis
Copy link
Member

@docfaraday Thanks. Continues in joyent/libuv#526.

@bnoordhuis
Copy link
Member

This is fixed in joyent/libuv@9a48381. It will be in the next v0.8 release.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants