Looks like I have used an incorrect template to file the bug.  I saw this behavior in 
Chrome for Linux.

Version (from dpkg -s google-chrome-unstable): 3.0.194.0-r20577
OS + version: Ubuntu Hardy
CPU architecture (32-bit / 64-bit): 32-bit, i386
window manager: KDE

Works for me with 3.0.195.0 (20600) (built from source).

It reports -120 for me and my timezone is gmt+2.

There's an interesting timezone related comment here btw.:
http://code.google.com/p/chromium/issues/detail?id=16815#c15
Maybe its the sandbox?

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?

Indeed, I believe it is.

Using corp gmail, I get the wrong date/time displayed for messages in my inbox. 
Build:3.0.194.0

Issue 16633 has been merged into this issue.

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.

------------------------------------------------------------------------

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.

Issue 17317 has been merged into this issue.

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.

criag.schlenter: we have an FC11 box here, and I cannot reproduce the issue there.

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.

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.

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.

CC'ing fta

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.

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?

eswierk: off the top of my head, i guess o3d won't work, and javascript will be slower

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.

Ok, filed issue 17997 about the shared library issue.

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

------------------------------------------------------------------------

Looks good, thanks!

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.

gdb.out 5.3 KB View Download

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.

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.

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?

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.

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.

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.

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?

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;
  }
}

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

Issue 20958 has been merged into this issue.

This is what I get with gentootestcase:

% ./gentootestcase 
dlsym working correctly

Issue 20280 has been merged into this issue.

the gentootestcase works correctly for me as well. I am thinking that perhaps it has
something to do with the sandboxing.

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.

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. 

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?

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.

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.

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().

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

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

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.)

@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.

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

------------------------------------------------------------------------

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.

Issue 19995 has been merged into this issue.

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

Cool. But I think you mean nvidia driver 190.25 not 195.25? I will give it a try. 
Thanks!

Exactly: nvidia-drivers-190.25

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
------------------------------------------------------------------------

Issue 24351 has been merged into this issue.

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
------------------------------------------------------------------------

NVidia have fixed this in the 190.xx driver series according to the earlier nvnews 
thread.

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).

@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.

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.