New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 18 users

Issue metadata

Status: PendingFurtherInfo
Owner:
Last visit > 30 days ago
Closed: Jul 2014
HW: x64
NextAction: ----
OS: ----
Priority: 3
Type: Bug



Sign in to add a comment

v8 Build error in FreeBSD 8.1

Reported by yaowei...@gmail.com, Dec 9 2010

Issue description

I checkout the v8 source:
svn checkout http://v8.googlecode.com/svn/trunk/ v8

then build v8 like this:
scons mode=debug library=shared snapshot=on

then encounter this build error:
...
g++ -o obj/debug/platform-freebsd.os -c -Wall -Werror -W -Wno-unused-parameter -Wnon-virtual-dtor -m32 -g -O0 -ansi -fno-rtti -fno-exceptions -fvisibility=hidden -Wall -Werror -W -Wno-unused-parameter -Wnon-virtual-dtor -m32 -g -O0 -ansi -fPIC -DV8_TARGET_ARCH_IA32 -DENABLE_DISASSEMBLER -DDEBUG -DENABLE_VMSTATE_TRACKING -DENABLE_LOGGING_AND_PROFILING -DV8_ENABLE_CHECKS -DENABLE_DEBUGGER_SUPPORT -I/usr/local/include -Isrc src/platform-freebsd.cc
src/platform-freebsd.cc: In static member function 'static v8::internal::Mutex* v8::internal::OS::CreateMutex()':
src/platform-freebsd.cc:509: error: cannot allocate an object of abstract type 'v8::internal::FreeBSDMutex'
src/platform-freebsd.cc:478: note:   because the following virtual functions are pure within 'v8::internal::FreeBSDMutex':
src/platform.h:441: note:       virtual bool v8::internal::Mutex::TryLock()
src/platform-freebsd.cc: In function 'void v8::internal::ProfilerSignalHandler(int, siginfo_t*, void*)':
src/platform-freebsd.cc:581: error: 'current_state' is not a member of 'v8::internal::VMState'
scons: *** [obj/debug/platform-freebsd.os] Error 1
scons: building terminated because of errors.

 
My g++ version is:
g++ (GCC) 4.2.1 20070719  [FreeBSD]

Comment 2 by joa...@yepmail.net, Dec 12 2010

It looks like the 3.0 update broke v8 on FreeBSD.  I got it to get past these two compile errors with the simple patch that's attached, only to have it stack overflow when mksnapshot tries to generate snapshot.cc.
v8.patch
1.2 KB View Download

Comment 3 by joa...@yepmail.net, Dec 13 2010

I looked into this a bit further: it turns out that the attached patch works on i386, with the resulting v8 3.0 i386 binary passing all the same unit tests as v8 2.5.9.  It's only on amd64 that it leads to stack overflows galore.  I wonder if that has something to do with the new amd64 functions in atomicops_internals_x86_gcc.h, like NoBarrier_CompareAndSwap.  Presumably those functions run fine on amd64 linux though (?): could it be they require a compiler newer than gcc 4.2.1, the system compiler on FreeBSD?

Comment 4 by msc...@gmail.com, Dec 21 2010

I ran into this problem also. Applying this patch and a similar one for OpenBSD allows v8 to compile again on those platforms. However, as noted, v8 on 64-bit FreeBSD dies (with a CALL_AND_RETRY_0 error) if you try to use it.

Comment 5 by cloud...@gmail.com, Dec 21 2010

I'm working on this problem, looks like something wrong inside %_IsConstructCall()

Comment 6 by ager@chromium.org, Dec 21 2010

 Issue 997  has been merged into this issue.
Labels: HelpWanted

Comment 8 by ager@chromium.org, Jan 18 2011

 Issue 1051  has been merged into this issue.
I've attached details of my current progress digging into this bug.

The patch I created to make v8 compile on FreeBSD 8.0 (gcc 4.2.1) is also included. It was made against r6475. I had done it before I was pointed at this bug, but I think I'm on the same track as the patch above. It's a bit of a mashup of the Linux and Solaris platform code to get the ProfilerSignalHandler working.

The output attached looks (to my noobish eyes at least) like a bug in the stack trace generator which is probably masking the real issues.

Can anyone give me a few hints as to where to go next? Is there any other data I could gather which would help?
v8-issue-966.log
3.9 MB View Download
v8-issue-966-r6475.patch
3.3 KB View Download

Comment 10 by lin...@gmail.com, Jan 26 2011

Cool! May I use your patch to ports www/node-devel? Thanks.
It's a bit hard to deduce anything from log alone especially without seeing bottom frames of stack trace.

You should look at the bottom frames and try to walk stack manually checking the disassembly.

Comment 12 by os2n...@gmail.com, Feb 14 2011

I'm running into the same issue... I checked the end of the log file mksnapshot is producing and compared it to one produced with a successful build on a Mac and they are almost identical up until the point where the FreeBSD one crashed. I'm attaching the relevant part of the two logs in case someone might have an idea from the log.  Thought it might be an issue with the stack backtrace grabbing but after testing that does not seem to be the case.
v8-freebsd-and-mac-amd64-snapshot.log
7.1 KB View Download
So I've been looking into this bug recently and the stacktrace is always the same with a debug build of v8:

 ./shell_g --enable-slow-asserts --debug-code --verify-heap -e'print "foo"'
abort: Operand is not a smi

==== Stack trace ============================================

Security context: 0x8009aab89 <JS Object>#0#
    1: new Number(this=0x80201e409 <a Number> value = 0x8009ea089 <undefined>>#1#,a=0)
    3: /* anonymous */ [native v8natives.js:994] (this=0x8009abb19 <JS Object>#2#)

==== Details ================================================

[1]: new Number(this=0x80201e409 <a Number> value = 0x8009ea089 <undefined>>#1#,a=0) {
  // stack-allocated locals
  var b = 0x8009ea089 <undefined>
  // expression stack (top to bottom)
  [03] : 1
  [02] : 0

  [01] : 32767
--------- s o u r c e   c o d e ---------
<No Source>
-----------------------------------------
}

[3]: /* anonymous */ [native v8natives.js:994] (this=0x8009abb19 <JS Object>#2#) {
  // stack-allocated locals
  var .result = 0x8009ea089 <undefined>
  // expression stack (top to bottom)
  [03] : 0
  [02] : 0x8009aaef1 <JS Function Number>#3#
  [01] : 0x8009aaef1 <JS Function Number>#3#
--------- s o u r c e   c o d e ---------
????????????????????????????????????????const $isNaN=GlobalIsNaN;?const $isFinite=GlobalIsFinite;???????function InstallFunctions(a,b,c){?if(c.length>=8){?%OptimizeObjectForAddingMultipleProperties(a,c.length>>1);?}?for(var d=0;d<c.length;d+=2){?var e=c[d];?var f=c[d+1];?%FunctionSetName(f,e);?%Func...

-----------------------------------------
}

==== Key         ============================================

 #0# 0x8009aab89: 0x8009aab89 <JS Object>
 #1# 0x80201e409: 0x80201e409 <a Number> value = 0x8009ea089 <undefined>>
           value(): 0x8009ea089 <undefined>
 #2# 0x8009abb19: 0x8009abb19 <JS Object>
 #3# 0x8009aaef1: 0x8009aaef1 <JS Function Number>
=====================

Abort (core dumped)

It always chokes on this line in v8natives.js, going back to the v8 3.0 patch 5922.  Because this is built-in javascript code, v8 3.0 fails on any input, including empty input.  Since v8natives.js wasn't modified with v8 3.0, this function is just triggering a x64 bug elsewhere in that patch, but I thought I'd point this out in case it helps anyone figure out what's going on.
5922 was a pretty big change touching almost every single file in the codebase.

Can you get a backtrace with GDB? It would be also helpful if you provide disassembly around pc's for top 2-3 JS frames. 


Labels: -HelpWanted HW-x64 Type-Bug Priority-Medium
Status: Assigned
We are using SmiCompare to check whether frame is arguments adaptor or not.

__ SmiCompare(Operand(rdx, StandardFrameConstants::kContextOffset),
              Smi::FromInt(StackFrame::ARGUMENTS_ADAPTOR));

But SmiCompare tries to be smart and compares only upper part of the value:

void MacroAssembler::SmiCompare(const Operand& dst, Smi* src) {
  cmpl(Operand(dst, kSmiShift / kBitsPerByte), Immediate(src->value()));
}

Which leads to problems if we allocate contexts at addresses like 0x00000008XXXXXXXX.

Comment 16 by joa...@yepmail.net, Mar 16 2011

I updated to HEAD and now amd64 works and passes pretty much the same unit tests too.  I think this bug can now be marked as Fixed, thanks for taking care of this.  Also, you may want to apply my patch above to the BSDs, otherwise v8 doesn't compile.
If you want Crankshaft to work on FreeBSD you probably want the next BSD change too: http://codereview.chromium.org/6673045/ (not committed yet).
By the way, I fixed the 64 bit build, but not the 32 bit build.  If you want to contribute a patch that fixes the 32 bit build you have to sign the CLA and use the code review tool.  See http://www.chromium.org/developers/contributing-code  If you already signed it then please ping me with the email address you used and I will take another look.

Comment 19 by joa...@yepmail.net, Mar 17 2011

The 32-bit build of v8 3.0 has been working fine with my patch, as noted above.  I have had other patches of mine committed to v8 before, but your BSD patch contains much more than my little patch just to get it to compile, so committing your patch should be all that's necessary.  Glad to see better BSD support for v8. :)
Sorry for this kind of comment, but is there any progress in this? amd64 freebsd (not only 8.1, but other versions, too) version of v8 is uncompilable for half a year... I'd like to be able to compile node again, please. Thanx, herby

Comment 21 by joa...@yepmail.net, Aug 14 2011

herby, what exactly is the problem?  I've been compiling v8-amd64 since March without a problem, ever since the v8 devs fixed this bug.
Labels: -Priority-Medium Priority-Low
Downgrading this to low priority since it apparently only affects the 32 bit build, which is not popular on FreeBSD.  Please reopen if this is not the case since our testing resources are limited for FreeBSD.
Status: PendingFurtherInfo
Does this still happen?
Labels: Priority-3

Sign in to add a comment