Chrome 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 ifpossible.

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.

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.

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.

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

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.

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?

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.

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

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.

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