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 6 users
Status: Archived
Last visit > 30 days ago
Closed: Sep 2015
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Sign in to add a comment
mksnapshot reports: "Fatal error in v8::Context::New()" (gcc 4.4, F12)
Reported by, Oct 27 2009 Back to list
I'm filing this on behalf of Tom (spotrh) copied from  issue 23362 , comment 
39. This issue appears to be separate to the problem under discussion 
there, hence the new bug.

Chrome Version : 29513
OS + version : Fedora 12 beta?
CPU architecture (32-bit / 64-bit): 64 bit

[begin quote]
Yes, gcc_version=44 and no_strict_aliasing=1 and target_arch=x64 (it bails 
out much
earlier if you don't pass target_arch=x64)

[spot@f12.x86-64 gyp]$ gdb
GNU gdb (GDB) Fedora (
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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-redhat-linux-gnu".
For bug reporting instructions, please see:
Reading symbols from
(gdb) set args
(gdb) run
Starting program:
[Thread debugging using libthread_db enabled]

# Fatal error in v8::Context::New()
# Error initializing V8

Program received signal SIGABRT, Aborted.
0x0000003681833575 in raise () from /lib64/
(gdb) bt
#0  0x0000003681833575 in raise () from /lib64/
#1  0x0000003681834d55 in abort () from /lib64/
#2  0x000000000066eacb in v8::internal::OS::Abort () at
#3  0x0000000000523964 in API_Fatal (location=0x6dd19d 
format=0x6dbcf3 "Error initializing V8") at
#4  0x00000000004fc824 in v8::DefaultFatalErrorHandler (location=0x6dd19d
"v8::Context::New()", message=0x6dbcf3 "Error initializing V8") at
#5  0x00000000004fc8d8 in v8::Utils::ReportApiFailure (location=0x6dd19d
"v8::Context::New()", message=0x6dbcf3 "Error initializing V8") at
#6  0x00000000004fc924 in v8::ApiCheck (condition=false, location=0x6dd19d
"v8::Context::New()", message=0x6dbcf3 "Error initializing V8") at
#7  0x00000000004fca6d in v8::EnsureInitialized (location=0x6dd19d
"v8::Context::New()") at /mnt/chromium/chromium-
#8  0x0000000000505e7b in v8::Context::New (extensions=0x7fffffffe340,
global_template=..., global_object=...) at
#9  0x00000000004f9b52 in main (argc=2, argv=0x7fffffffe488) at
[end quote]

And after some debugging by Tom:

[begin quote]
And indeed, we get:

Heap::Setup(create_heap_objects) returned 0

A lot more printfs into and I've narrowed down the reason in
Heap::Setup to:

 if (!code_space_->Setup(NULL, 0)) return false;

That goes into PagedSpace::Setup (, and I was able to narrow
it down to this failure case:

 if (!first_page_->is_valid()) {
    return false;
[end quote]

I should note that gcc 4.4.x is in use successfully elsewhere (I run it on 
F9, Joel uses it on Karmic) and mksnapshot seems to work there so the issue 
may be specific to F12 or F12's gcc 4.4 or something ...

Comment 1 by, Oct 27 2009
Comment 2 by, Oct 28 2009
FWIW, I hit this again trying to do the Fedora chromium package builds. My standalone
v8 package built fine, but some part of chromium still tried to make the v8 snapshot
(via mksnapshot) and failed. I'm going to try to patch that out in the morning.

Gory toolchain details:


[spot@f12.x86-64 SPECS]$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=
--enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj- --enable-libgcj-multifile
--enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.2 20091018 (Red Hat 4.4.2-4) (GCC) 

[spot@f12.x86-64 SPECS]$ /lib64/ 
GNU C Library development release version 2.10.90, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
Compiled by GNU CC version 4.4.1 20091008 (Red Hat 4.4.1-20).
Compiled on a Linux >>2.6.18-164.el5<< system on 2009-10-12.
Available extensions:
        The C stubs add-on version 2.1.2.
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        Native POSIX Threads Library by Ulrich Drepper et al
        RT using linux kernel aio
For bug reporting instructions, please see:

Comment 3 by, Oct 28 2009
Status: Assigned
Erik, could you look into this?
spotrh: Since package building used to work for you, I'm wondering if a chromium 
change or a toolchain change is responsible for this.

That toolchain seems to be from 2009-10-19 for example. I'm wondering if you would be 
able to test an earlier version of chromium (ideally something that you have 
successfully built rpms for before) so we can rule out toolchain issues.
Comment 5 by, Oct 28 2009
Actually, I think what happened is that a .gyp change occurred causing the chromium
code to try to build v8 from its local copy (rather than simply using the system 
shared library I built).

When a .gyp file says:


I patch it to say instead:


src/build/linux/system.gyp has also been patched to add:

+      'target_name': 'v8',
+      'type': 'settings',
+      'direct_dependent_settings': {
+        'cflags': [
+        ],
+      },
+      'link_settings': {
+        'ldflags': [
+        ],
+        'libraries': [
+          '-lv8',  
+        ],
+      },
+    },

I missed an invocation in src/third_party/WebKit/WebCore/WebCore.gyp/WebCore.gyp, so
hammer tried to build its local copy of v8 as a dep, which invoked mksnapshot,
revealing this bug again.

It is likely that this issue has been here for some time, but was only visible when I
tried building from an unpatched, unpackaged, vanilla tree.
Comment 6 by, Jun 24 2010
Labels: karen624move Mstone-X
No activity on this issue in 3 years, auto-archiving.
Comment 8 by, Sep 23 2015
Status: Archived
Sign in to add a comment