Date.getTimezoneOffset always returns 0 |
|
|||||||
Reported by t.ma...@gmail.com, Jul 15 2009 | Back to list | |||||||
Issue descriptionChrome Version : 3.0.194.0 (Official Build 20577) URLs (if applicable) : Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 4: Firefox 3.x: OK IE 7: IE 8: What steps will reproduce the problem? 1. Open a new tab 2. Type javascript:alert(new Date().getTimezoneOffset()) in the address bar What is the expected result? UTC offset of the local time zone is shown in a message box. (-330 for my local time zone, Indian Standard Time.) What happens instead? Alert box shows 0. Please provide any additional information below. Attach a screenshot if possible.
Jul 15 2009
,
Jul 15 2009
,
Works for me with 3.0.195.0 (20600) (built from source). It reports -120 for me and my timezone is gmt+2.
Jul 16 2009
,
There's an interesting timezone related comment here btw.: http://code.google.com/p/chromium/issues/detail?id=16815#c15 Maybe its the sandbox?
Jul 17 2009
,
Ah ... when I enable the sandbox it returns 0 for me. With sandbox disabled it returns the right offset. Adding agl to Cc. Maybe this needs the same sort of fix as r20733 did for LD_LIBRARY_PATH?
Jul 17 2009
,
Indeed, I believe it is.
Jul 17 2009
,
Using corp gmail, I get the wrong date/time displayed for messages in my inbox. Build:3.0.194.0
Jul 18 2009
,
Issue 16633 has been merged into this issue.
Jul 18 2009
,
Jul 20 2009
,
The following revision refers to this bug: http://src.chromium.org/viewvc/chrome?view=rev&revision=21097 ------------------------------------------------------------------------ r21097 | agl@chromium.org | 2009-07-20 13:30:07 -0700 (Mon, 20 Jul 2009) | 18 lines Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_sandbox_host_linux.cc?r1=21097&r2=21096 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/zygote_main_linux.cc?r1=21097&r2=21096 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/sandbox_methods_linux.h?r1=21097&r2=21096 Linux sandbox: plumb timezone calls through the sandbox The localtime (and localtime_r) functions try to access /etc/localtime in the filesystem. For sandboxed renderers, this fails, the the functions default to a UTC timezone. These functions are called from within WebCore and V8 and there's no clean way to patch the source code in place to do a hairpin turn and manage an IPC. Additionally, we cannot overwrite the calls with the usual symbol resolution procedures since the same chrome binary must serve as both the unsandboxed browser and sandboxed renderer. Thus we patch the GOT at runtime if we find, in the zygote process, that we are sandboxed. BUG= 16800 TEST=Run javascript:alert(new Date().getTimezoneOffset()) in a sandboxed renderer. The resulting timezone offset (in minutes) should be correct for the local timezone. ------------------------------------------------------------------------
Jul 20 2009
,
Jul 22 2009
,
The r21097 patch breaks chromium for me - the renderers just seem to hang :( My system is a non-standard in that I use gcc 4.4 and run selinux though. Commenting out the calls to PATCH_GLOBAL_OFFSET_TABLE or disabling the sandbox makes things run again. I haven't tracked it down any further than that yet as 21097 has interesting bits of rocket science that I don't understand fully yet.
Jul 22 2009
,
Issue 17317 has been merged into this issue.
Jul 22 2009
,
criag.schlenter: ah heck. I think had I really broken the world (again) with this patch, I would have heard more noise about it, so hopefully it's minimal. If you can find me on IRC, I can help you track this down.
Jul 22 2009
,
criag.schlenter: we have an FC11 box here, and I cannot reproduce the issue there.
Jul 22 2009
,
Quick update: discussed on IRC (thx agl) ... seems to only affect shared build so it is not something many people are likely to run into at all. Normal build works happily for me.
Jul 28 2009
,
I'm hitting this problem on an r21637 (20090727) build from ubuntu's PPA repository (32-bit system, up-to-date Karmic, 9.10 release). Based on the comment history above, I'm guessing they have enabled the 'shared' build? If this test is expected to fail for the shared build, should I report the bug to the packager instead (and have them do normal builds)? Or should I be patient (also a completely fine answer -- there's still much left to do on Chrome, and this is a pretty small issue). It is an annoying problem as all the displayed message times in gmail are off by my timezone offset, though.
Jul 28 2009
,
We do /not/ support compiling V8 as a shared library. We may in the future, but right now, any packages with a shared V8 are broken. fta (the Ubuntu PPA guy) knows about this.
Jul 28 2009
,
CC'ing fta
Jul 28 2009
,
ok, I see. *sigh* system-v8 disabled in the ubuntu packaging branch. Next build (tomorrow) will catch it. I guess i should file another bug so we remember this when the time comes to re-enable it.
Jul 29 2009
,
I'm using the unofficial Fedora rpms which also use a shared v8 library. I think I can live with the timezone issue for now. Are there other known problems due to using a shared v8 library?
Jul 29 2009
,
eswierk: off the top of my head, i guess o3d won't work, and javascript will be slower
Jul 29 2009
,
I'm not sure its far to call this issue fixed, since we're going to need a shared v8 library to get this into Fedora.
Jul 29 2009
,
Ok, filed issue 17997 about the shared library issue.
Aug 6 2009
,
The following revision refers to this bug: http://src.chromium.org/viewvc/chrome?view=rev&revision=22636 ------------------------------------------------------------------------ r22636 | agl@chromium.org | 2009-08-06 11:44:06 -0700 (Thu, 06 Aug 2009) | 28 lines Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/zygote_main_linux.cc?r1=22636&r2=22635 Linux: don't use GOT patching to intercept localtime(_r) Our current GOT patching code is platform specific and fails to work when V8 is built as a library. Instead we define global functions for those functions which we wish to override. Since we will be first in the dynamic resolution order, the dynamic linker will point callers to our versions of these functions. However, we have the same binary for both the browser and the renderers, which means that our overrides will apply in the browser too. The global |g_am_zygote_or_renderer| is true iff we are in a zygote or renderer process. It's set in ZygoteMain and inherited by the renderers when they fork. (This means that it'll be incorrect for global constructor functions and before ZygoteMain is called - beware). Our replacement functions can check this global and either proxy the call to the browser over the sandbox IPC (http://code.google.com/p/chromium/wiki/LinuxSandboxIPC) or they can use dlsym with RTLD_NEXT to resolve the symbol, ignoring any symbols in the current module. TEST=Run javascript:alert(new Date().getTimezoneOffset()). It shouldn't return 0 unless you're actually in GMT. BUG= 16800 http://codereview.chromium.org/165011 ------------------------------------------------------------------------
Aug 11 2009
,
Looks good, thanks!
Aug 11 2009
,
Aug 25 2009
,
I believe the fix in revision 22636 has introduced a critical bug: the return value of dlsym() is not checked for NULL. When I run chromium on my Linux PC it always crashes within a few seconds of startup. The attached file (gdb.out) is the output of the gdb debugger running chromium. It shows the crash and call backtrace. As you can see, chromium crashed at zygote_main_linux.cc line 312: struct tm* localtime_r(const time_t* timep, struct tm* result) { if (g_am_zygote_or_renderer) { ProxyLocaltimeCallToBrowser(*timep, result, NULL, 0); return result; } else { typedef struct tm* (*LocaltimeRFunction)(const time_t* timep, struct tm* result); static LocaltimeRFunction libc_localtime_r; if (!libc_localtime_r) libc_localtime_r = (LocaltimeRFunction) dlsym(RTLD_NEXT, "localtime_r"); return libc_localtime_r(timep, result); *** <== LINE 312 HERE *** } } Looking at the above code, if dlsym() returns NULL - as it may - then chromium will crash.
Aug 25 2009
,
If you don't have localtime_r or localtime, then Chromium will fail to dynamically link anyway. We require a certain base platform and localtime/localtime_r are certainly included in that requirement.
Aug 25 2009
,
Interestingly I do have both localtime() and localtime_r() in my libc: % objdump --dynamic-syms /lib/libc.so.6 | fgrep localtime 00088660 w DF .text 00000032 GLIBC_2.0 localtime_r 00088620 g DF .text 00000035 GLIBC_2.0 localtime % I have no idea why dlsym() is not finding localtime_r(). My Linux distro is Gentoo and my libc version is glibc-2.9_p20081201-r2.
Aug 25 2009
,
As an experiment I removed the replacement localtime() and localtime_r() functions from zygote_main_linux.cc and rebuilt chromium. It fixed the problem; chromium no longer crashes on startup. It also demonstrated that the (presumed) NULL return from dlsym() was not because localtime_r() was missing from the base platform. Should I file a new bug report?
Aug 25 2009
,
If RTLD_NEXT doesn't work then Chromium won't work. Unless there's a large number of users who are affected by this, then we're not going to change anything I'm afraid. The bottom line is that you need a working dynamic linker.
Aug 26 2009
,
I accept that there may be a problem with glibc's implementation of RTLD_NEXT, or with the dynamic linking loader, or something. If it is out of your control then fair enough. But dlsym() returning a NULL pointer is documented behaviour. Dereferencing a NULL pointer is something I consider to be a critical bug.
Aug 29 2009
,
Same here: objdump --dynamic-syms /lib/libc.so.6 | fgrep localtime 0008a580 w DF .text 00000032 GLIBC_2.0 localtime_r 0008a540 g DF .text 00000035 GLIBC_2.0 localtime with glibc-2.10.1 on Gentoo. Chromium-bin crashes on startup.
Sep 1 2009
,
I'm getting this same crash on Gentoo. If this is really a dynamic linker issue, could you please give us some clues as to how to fix our setups? pzparsons raised some good points in comment #33 and #35, and I'm not sure They have been properly addressed. This is either a bug in chromium or a bug in gentoo (and possibly other distros). So if the bug is not in chromium, what sort of bug report should we be filing with gentoo?
Sep 1 2009
,
It's starting to look like all Gentoo systems are failing here. In which case, I'm ok with adding an exception, but all timezone information will be broken on Gentoo. This simple test case should work. If it doesn't, then it's probably a good start for a bug: #define _GNU_SOURCE #include <stdio.h> #include <dlfcn.h> int main() { void *func = dlsym(RTLD_NEXT, "localtime"); if (func) { printf("dlsym working correctly\n"); return 1; } else { printf("dlsym failed\n"); return 0; } }
Sep 1 2009
,
Anyone who wants to compile this, the compiler flags you need are -ldl, i.e. gcc -ldl gentootestcase.c -o gentootestcase. For me it reported: rogue@ProximaCentauri ~ $ ./gentootestcase dlsym working correctly
Sep 3 2009
,
Issue 20958 has been merged into this issue.
Sep 4 2009
,
This is what I get with gentootestcase: % ./gentootestcase dlsym working correctly
Sep 4 2009
,
Issue 20280 has been merged into this issue.
Sep 4 2009
,
the gentootestcase works correctly for me as well. I am thinking that perhaps it has something to do with the sandboxing.
Sep 8 2009
,
It has something to do with NVIDIA ! Consider this: # gcc -o gentootestcase gentootestcase.c -lGL # eselect opengl list Available OpenGL implementations: [1] nvidia * [2] xorg-x11 # ldd gentootestcase linux-gate.so.1 => (0xb7fd6000) libGL.so.1 => /usr/lib/opengl/nvidia/lib/libGL.so.1 (0xb7f22000) libc.so.6 => /lib/libc.so.6 (0xb7ddf000) libdl.so.2 => /lib/libdl.so.2 (0xb7ddb000) libGLcore.so.1 => /usr/lib/opengl/nvidia/lib/libGLcore.so.1 (0xb6e76000) libnvidia-tls.so.1 => /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 (0xb6e74000) libm.so.6 => /lib/libm.so.6 (0xb6e4d000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb6e3d000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb6d4a000) /lib/ld-linux.so.2 (0xb7fd7000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb6d46000) libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb6d43000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6d28000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6d22000) # ./gentootestcase dlsym failed # eselect opengl set 2 Switching to xorg-x11 OpenGL interface... done # ldd gentootestcase linux-gate.so.1 => (0xb7f51000) libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0xb7ed1000) libc.so.6 => /lib/libc.so.6 (0xb7d8e000) libdl.so.2 => /lib/libdl.so.2 (0xb7d8a000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb7d7a000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb7d74000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb7d70000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7d69000) libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0xb7d66000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7c73000) libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0xb7c60000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7c46000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb7c3b000) libm.so.6 => /lib/libm.so.6 (0xb7c14000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7bfc000) /lib/ld-linux.so.2 (0xb7f52000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb7bf8000) libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb7bf5000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7bef000) librt.so.1 => /lib/librt.so.1 (0xb7be5000) # ./gentootestcase dlsym working correctly # The same applies to chromium; it crashes with the nvidia OpenGL implementation, but works with the xorg-x11 OpenGL implementation.
Sep 8 2009
,
I'm confused. Why did you link gentootestcase.c with the -lGL flag? Could it be that the nvidia opengl implementation doesn't link to the dynamic linking library that -ldl would link to, but that the xorg-x11 implementation does? In other words, the binary fails because it's not correctly linked, unless it gets indirect access to that library using the xorg-x11 OpenGl library. I don't have an nvidia card, so I can't run ldd on the nvidia driver, but here's the dynamic linking for the xorg opengl version: ldd /usr/lib/opengl/xorg-x11/lib/libGL.so.1 linux-gate.so.1 => (0xb7fda000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb7f45000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb7f3f000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb7f3b000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7f35000) libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0xb7f31000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7e60000) libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0xb7e50000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7e39000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb7e2f000) libm.so.6 => /lib/libm.so.6 (0xb7e09000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7df0000) libdl.so.2 => /lib/libdl.so.2 (0xb7dec000) libc.so.6 => /lib/libc.so.6 (0xb7cac000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb7ca8000) libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb7ca5000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7c9e000) librt.so.1 => /lib/librt.so.1 (0xb7c95000) /lib/ld-linux.so.2 (0xb7fdb000) On my system, chromium doesn't work with the xorg-x11 opengl implementation. But I'm not sure it has anything to do with opengl.
Sep 8 2009
,
This may sound like a colossally dumb question, but could someone please verify that chromium is correctly and directly linked to dlfcn.h in all the right places, and that the scons files correctly link chromium directly to libdl.so.2?
Sep 8 2009
,
Response to comment 45. I was examining chromium, stripping away code until it did nothing except call dlsym(). Yet dlsym() still failed to find localtime() and localtime_r(). So I began stripping away libraries until I found the culprit: libGL.so. On my system, libGL.so is pulled in by libgtk-x11-2.0.so and libgdk-x11-2.0.so among others. Since libGL.so pulls in libdl.so, I was able to link gentootestcase to either library. Of course gentootestcase never calls OpenGL code. Yet something about libGL.so is causing dlsym() in both gentootestcase and chromium to fail.
Sep 8 2009
,
That's really strange. I can't see why that would be, unless libGl overrides dlsym() or something, but I don't know why it would do that. If this is really an opengl issue, then I must be having a different issue. I'm not sure how to find out what the issue is because I can't get a backtrace from gdb, even though I've compiled chromium in debug mode.
Sep 8 2009
,
I just googled - nvidia libGL.so dlsym - and found this: http://www.nvnews.net/vbulletin/showthread.php?t=132259 It seems that Nvidia's libGL does indeed override dlsym().
Sep 8 2009
,
As for debugging chromium, I ran the debug build within gdb rather than examine the core dump (which didn't work): % gdb chrome ... (gdb) run ... (gdb) where ... (gdb) quit
Sep 8 2009
,
Ok, here's what I've got: rogue@ProximaCentauri ~/chromium/src/sconsbuild/Debug $ gdb chrome GNU gdb 6.8 Copyright (C) 2008 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 "i686-pc-linux-gnu"... (gdb) run Starting program: /home/rogue/chromium/src/sconsbuild/Debug/chrome [Thread debugging using libthread_db enabled] [New Thread 0xb6e35710 (LWP 5886)] [New Thread 0xb6a58b90 (LWP 5890)] [New Thread 0xb60dcb90 (LWP 5891)] [New Thread 0xb58dbb90 (LWP 5892)] [New Thread 0xb50dab90 (LWP 5893)] [New Thread 0xb50b9b90 (LWP 5894)] [New Thread 0xb5098b90 (LWP 5895)] [New Thread 0xb459eb90 (LWP 5896)] [New Thread 0xb3d43b90 (LWP 5904)] [New Thread 0xb3542b90 (LWP 5905)] [Thread 0xb3d43b90 (LWP 5904) exited] [Thread 0xb3542b90 (LWP 5905) exited] [5886:5892:1728754187749:ERROR:/home/rogue/chromium/src/net/socket/ssl_client_socket_nss.cc(720)] handshake failed; NSS error code -5938, net_error -107 [5886:5892:1728754216246:FATAL:/home/rogue/chromium/src/chrome/browser/renderer_host/async_resource_handler.cc(145)] Check failed: read_buffer_->data(). Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 0xb58dbb90 (LWP 5892)] DebugUtil::BreakDebugger () at /home/rogue/chromium/src/base/debug_util_posix.cc:116 116 } (gdb) where #0 DebugUtil::BreakDebugger () at /home/rogue/chromium/src/base/debug_util_posix.cc:116 #1 0x098ac410 in ~LogMessage (this=0xb58da940) at /home/rogue/chromium/src/base/logging.cc:535 #2 0x096e02ea in AsyncResourceHandler::OnResponseCompleted (this=0xb2902f78, request_id=0, status=@0xb290309c, security_info=@0xb58daa58) at /home/rogue/chromium/src/chrome/browser/renderer_host/async_resource_handler.cc:145 #3 0x096eb3a3 in BufferedResourceHandler::OnResponseCompleted ( this=0xb29031f8, request_id=0, status=@0xb290309c, security_info=@0xb58daa58) at /home/rogue/chromium/src/chrome/browser/renderer_host/buffered_resource_handler.cc:88 #4 0x094d8bce in ResourceDispatcherHost::OnResponseCompleted (this=0xc411908, request=0xb2902fa0) at /home/rogue/chromium/src/chrome/browser/renderer_host/resource_dispatcher_host.cc:1437 #5 0x094d8d59 in ResourceDispatcherHost::StartReading (this=0xc411908, request=0xb2902fa0) at /home/rogue/chromium/src/chrome/browser/renderer_host/resource_dispatcher_host.cc:1333 #6 0x094dc5f9 in ResourceDispatcherHost::OnResponseStarted (this=0xc411908, request=0xb2902fa0) ---Type <return> to continue, or q <return> to quit--- at /home/rogue/chromium/src/chrome/browser/renderer_host/resource_dispatcher_host.cc:1093 #7 0x09b7f42b in URLRequest::ResponseStarted (this=0xb2902fa0) at /home/rogue/chromium/src/net/url_request/url_request.cc:466 #8 0x09b90d21 in URLRequestJob::NotifyHeadersComplete (this=0xb2903328) at /home/rogue/chromium/src/net/url_request/url_request_job.cc:425 #9 0x09357f8e in URLRequestChromeJob::StartAsync (this=0xb2903328) at /home/rogue/chromium/src/chrome/browser/dom_ui/chrome_url_data_manager.cc:387 #10 0x09359abe in DispatchToMethod<URLRequestChromeJob, void (URLRequestChromeJob::*)()> (obj=0xb2903328, method=0x9357f48 <URLRequestChromeJob::StartAsync()>, arg=@0xb290342c) at /home/rogue/chromium/src/base/tuple.h:412 #11 0x09359af9 in RunnableMethod<URLRequestChromeJob, void (URLRequestChromeJob::*)(), Tuple0>::Run (this=0xb2903410) at /home/rogue/chromium/src/base/task.h:307 #12 0x098ae676 in MessageLoop::RunTask (this=0xb58db1c0, task=0xb2903410) at /home/rogue/chromium/src/base/message_loop.cc:314 #13 0x098aed59 in MessageLoop::DeferOrRunPendingTask (this=0xb58db1c0, pending_task=@0xb58daf54) at /home/rogue/chromium/src/base/message_loop.cc:322 #14 0x098aefd8 in MessageLoop::DoWork (this=0xb58db1c0) at /home/rogue/chromium/src/base/message_loop.cc:429 ---Type <return> to continue, or q <return> to quit--- #15 0x098b6c2b in base::MessagePumpLibevent::Run (this=0xc40a470, delegate=0xb58db1c0) at /home/rogue/chromium/src/base/message_pump_libevent.cc:224 #16 0x098af63d in MessageLoop::RunInternal (this=0xb58db1c0) at /home/rogue/chromium/src/base/message_loop.cc:199 #17 0x098af657 in MessageLoop::RunHandler (this=0xb58db1c0) at /home/rogue/chromium/src/base/message_loop.cc:181 #18 0x098af6fb in MessageLoop::Run (this=0xb58db1c0) at /home/rogue/chromium/src/base/message_loop.cc:155 #19 0x098e2d50 in base::Thread::ThreadMain (this=0xc40a350) at /home/rogue/chromium/src/base/thread.cc:156 #20 0x098c2942 in ThreadFunc (closure=0xc40a350) at /home/rogue/chromium/src/base/platform_thread_posix.cc:26 #21 0xb7479160 in start_thread () from /lib/libpthread.so.0 #22 0xb7228e2e in clone () from /lib/libc.so.6
Sep 8 2009
,
Well done to folks to tracking it down to Nvidia's GL library. Without a system to play with, I wouldn't ever have been able to track that down. Obviously, the correct fix is Nvidia's task. They either need to stop playing games with dlsym, or do a better job of it. However, in the mean time, I guess I should drop a NULL check in there as a work around. I can do that now. (jessemichaelwilson: that backtrace looks like a different bug to me. It might make a good start on a new bug report though.)
Sep 8 2009
,
@jessemichaelwilson: that crash is http://code.google.com/p/chromium/issues/detail? id=16371. You can probably fix it by fixing your permissions for /dev/shm.
Sep 8 2009
,
The following revision refers to this bug: http://src.chromium.org/viewvc/chrome?view=rev&revision=25671 ------------------------------------------------------------------------ r25671 | agl@chromium.org | 2009-09-08 15:30:58 -0700 (Tue, 08 Sep 2009) | 13 lines Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/zygote_main_linux.cc?r1=25671&r2=25670 Linux: work around broken dlsym's. It appears that Nvidia's libGL.so is overriding dlopen/dlsym with versions that don't fully function. So far, all the users reporting this have been running Gentoo, but it might just be that they have up-to-date drivers. The report[1] suggests that all drivers >= 180 have this issue. [1] http://www.nvnews.net/vbulletin/showthread.php?t=132259 BUG= 16800 http://codereview.chromium.org/201055 ------------------------------------------------------------------------
Sep 8 2009
,
Thanks Willchan, that worked. I'm not sure why I had the /dev/shm line commented out of my /etc/fstab, but uncommenting it fixed it. It seems like I had to comment that line to get my system working a long time ago, so I hope that problem doesn't come back later.
Sep 9 2009
,
Issue 19995 has been merged into this issue.
Sep 9 2009
,
After upgrade nvidia-drivers to 195.25 everythig works good on Gentoo. No crashes, UTC offset is shown correctly. emerge --info Portage 2.2_rc40 (default/linux/x86/2008.0, gcc-4.3.2, glibc-2.10.1-r0, 2.6.27- gentoo-r7 i686) ================================================================= System uname: Linux-2.6.27-gentoo-r7-i686-Intel-R-_Core-TM-_Duo_CPU_T2250_@_1.73GHz- with-glibc2.1 Timestamp of tree: Tue, 08 Sep 2009 11:45:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.7 dev-lang/python: 2.4.4-r6, 2.5.4-r2 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.6.4 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.4.3-r3 sys-apps/sandbox: 2.1 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests ccache collision-protect distlocks fixpackages parallel- fetch preserve-libs protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://mirror.icis.pcz.pl/gentoo/ http://gentoo.mirror.pw.edu.pl http://gentoo.prz.edu.pl" LANG="pl_PL.UTF-8" LC_ALL="pl_PL.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="pl" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress -- force --whole-file --delete --stats --timeout=180 --exclude=/distfiles -- exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/berkano" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa amr berkdb bluetooth branding bzip2 cdr cli connectionstatus cracklib crypt cups dbus dri dvd dvdr encode ffmpeg fortran gadu gdbm gif google-gadgets gpm hal history ickoff iconv ieee1394 imagemagick isdnlog jabber java jingle jpeg kde laptop mad mmx mng mp3 mudflap ncurses networkmanager nls nptl nptlonly ogg opengl openmp pam pcre pdf perl png pppd python qt3support qt4 readline reflection sdl semantic-desktop session smp sox spell spl sse sse2 ssl sysfs tcpd theora tiff truetype unicode v4l vcd vidix vorbis wifi win32codecs wmf x86 xcomposite xine xorg xvid xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="pl" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Sep 9 2009
,
Cool. But I think you mean nvidia driver 190.25 not 195.25? I will give it a try. Thanks!
Sep 9 2009
,
Exactly: nvidia-drivers-190.25
Oct 6 2009
,
The following revision refers to this bug: http://src.chromium.org/viewvc/chrome?view=rev&revision=28062 ------------------------------------------------------------------------ r28062 | kbr@google.com | 2009-10-05 16:32:52 -0700 (Mon, 05 Oct 2009) | 10 lines Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/glew/README.chromium?r1=28062&r2=28061 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/glew/include/GL/glew.h?r1=28062&r2=28061 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/glew/src/glew.c?r1=28062&r2=28061 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/api/src/GraphicsContext3D.cpp?r1=28062&r2=28061 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/webkit.gyp?r1=28062&r2=28061 Ported Chrome's WebGL implementation to Linux. Required changes to GLEW's bootstrapping sequence on both X11 and Windows platforms to avoid linking against libGL.so.1 directly due to http://crbug.com/16800 . Made GLEW's inclusion of glu.h optional. Tested on Linux, Mac and Windows. BUG= http://crbug.com/21852 TEST=none (runs existing WebGL tests; more coming) Review URL: http://codereview.chromium.org/258024 ------------------------------------------------------------------------
Oct 8 2009
,
Issue 24351 has been merged into this issue.
Jan 11 2010
,
The following revision refers to this bug: http://src.chromium.org/viewvc/chrome?view=rev&revision=35863 ------------------------------------------------------------------------ r35863 | piman@chromium.org | 2010-01-08 18:45:56 -0800 (Fri, 08 Jan 2010) | 7 lines Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/service/x_utils.cc?r1=35863&r2=35862 M http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/service/x_utils.h?r1=35863&r2=35862 M http://src.chromium.org/viewvc/chrome/trunk/src/gpu/gpu.gyp?r1=35863&r2=35862 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/glew/include/GL/glxew.h?r1=35863&r2=35862 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/glew/src/glew.c?r1=35863&r2=35862 linux: dynamically load libGL.so.1, and use glew to dynamically resolve symbols This is to workaround NVIDIA's broken dlsym hook. BUG= 16800 Review URL: http://codereview.chromium.org/525109 ------------------------------------------------------------------------
Mar 9 2010
,
NVidia have fixed this in the 190.xx driver series according to the earlier nvnews thread.
Feb 22 2011
,
I'm reproducing that issue with chromium-browser 9.0.597.98 (r74359), from debian/sid, with shared libv8. In chromium-browser : (new Date()).getTimezoneOffset() returns 0 In chromium-browser --no-sandbox : (new Date()).getTimezoneOffset() returns -60 (the correct value in my zone).
Feb 22 2011
,
@64: You're out of date. Try the latest version -- it's up to 11 now iirc. Also, this bug is very old. If you determine that you're still getting the broken behavior in the latest version, file a new bug (new.crbug.com) and use the word "regression" in the subject line, such as: [Regression] Date.getTimezoneOffset returns 0 inside sandbox You should also reference this bug in the new one.
Oct 12 2012
,
This issue has been closed for some time. No one will pay attention to new comments. If you are seeing this bug or have new data, please click New Issue to start a new bug. |
||||||||
►
Sign in to add a comment |
Comment 1 by t.ma...@gmail.com
, Jul 15 2009